Add CCM AEAD - Githubissues

briansmith commented 9 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 7 years ago

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

briansmith commented 6 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 11 months ago

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 commented 11 months ago

@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 commented 11 months ago

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.

briansmith / ring

Add CCM AEAD #25