Add CCM AEAD

[briansmith]

crypto/cmac is being removed because it depends on the non-AEAD cipher.h encryption interface, which is being removed. In order to implement the CCM AEAD, we need a new CTR + CBC-MAC (CCM) implementation. The new CCM implementation can assume that AES is the only cipher that it will be used with, and that it will only be exposed by the ring::aead interface, which should simplify the new implementation. [Edit: Say "CTR + CBC-MAC" instead of "CMAC".]

[a-dma]

Hi, quick question:

do you actually mean CMAC or did you instead mean CBC-MAC (which is used by AES-CCM) ?

If you did mean CBC-MAC, any plan to add CMAC? Should I open another issue for that?

[briansmith]

do you actually mean CMAC or did you instead mean CBC-MAC (which is used by AES-CCM) ?

I meant CTR + CBC-MAC, so we can eventually implement https://tools.ietf.org/html/rfc6655 and maybe eventually CCMP for 802.11 support.

If you did mean CBC-MAC, any plan to add CMAC? Should I open another issue for that?

Let's discuss CMAC in another issue, along with a clear description of use cases motivation.

[briansmith]

To add this to ring, I think we'd need to:

• Implement the CCM AEADs in src/aead/aes_ccm.rs using the same API style as AES-GCM and ChaCha20-Poly1305.
• Add the NIST test vectors from http://csrc.nist.gov/groups/STM/cavp/block-cipher-modes.html#test-vectors.
• Add any IETF test vectors.
• Add any additional tests.
• Verify that the maximum amount of data per key restrictions that are implemented in ring::aead are suitable for CCM. The code should include a link to the documentation of this maximum from NIST at least.

[briansmith]

This will be easier to do after #240 is done.

[briansmith]

Now that we can use #[repr(align)] (we're already using it as of today, for ChacCha20-Poly1305), this seems a lot more practical. I cleaned up some of the C/asm code to simplify this work in case somebody wants to take this on.

[jadamcrain]

@briansmith I'm interested in implementing this if a quality PR with test vectors, etc, would be reviewed. Is this still something that you're interested in supporting?

[jadamcrain]

There's a PR here for this.

I couldn't find official test vectors for Tag ==16 bytes, Nonce = 12 bytes so I generated some using Rust Crypto's generic CCM implementation.

If anyone else knows of additional test vectors for this configuration of CCM, please point me towards them and I can add them.

My interest in CCM is seeing AES_128_CCM_8 bulk modes get added to rustls TLS 1.2/1.3 so I can implement an IEEE standard that requires them.

[ethanndickson]

There's a PR here for this.
My interest in CCM is seeing AES_128_CCM_8 bulk modes get added to rustls TLS 1.2/1.3 so I can implement an IEEE standard that requires them.

I'm also implementing an IEEE standard that requires AES_128_CCM_8, though I'm unsure as to what else is needed for #1501 - is there any way I can assist in getting this merged?

[jadamcrain]

@ethanndickson. As I recall, the PR is pass at AES_128_CCM_16 with test vectors. I was unsure how to implement the truncation within rings API.

[briansmith]

I would be happy to add CCM support to ring and I think PR #1501 by @jadamcrain is a good starting point for that. @jadamcrain , thank you very much for your PR. I had a look at it and in general I think it looks good. I will review it in more detail soon.

@jadamcrain At https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/cavp-testing-block-cipher-modes you can find NIST's CCM test vectors. Also check BoringSSL for test vectors.

Now I am refactoring ring's internals as part of an urgent (for me) project. PR #1864 is a draft of the main refactoring that would significantly affect the CCM implementation. Basically, PR #1864 adds an InOut type that will eventually abstract away the difference between in-place and out-of-place seal/open operations. I still need to improve PR #1864 to DRY some logic around multi-part encryption operations, and more thoroughly test it, and document the new (internal) API, but the general idea is present.

It seems like we shouldn't try to shoehorn CCM into rings existing AEAD API with its nonce and tag requirements. I think we should implement the API we want to have for CCM specifically, and then figure out if/how to abstract across the presently-supported AEADs and CCM. I am also open to refactoring the public ring::aead API to be more flexible, but I think we may want to postpone that refactoring until we we see what the ideal standalone CCM API would be.