Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: crypto/tls: add support for AES-CCM #27484
Hi! I am working in a project that requires
Reducing that list from 5 to only 3 choices seems pretty unfair.
I've seen some working golang
I don't believe we need AES-CCM. Ideally, we would only support one or two ciphersuites at a time, and I intend to emulate BoringSSL in not exposing any choice of ciphersuite in TLS 1.3, selecting the fastest between AES-GCM and ChaCha20 based on hardware support (or the one preferred by the client based on PreferServerCipherSuites). As long as the default is fast and secure, the end user shouldn't have to make a decision on cipher block modes.
I don't think there's a fairness argument to the number of choices, as long as most users are served by the available options. If you believe I'm missing a concrete use case for AES-CCM that's not covered by the other supported ciphersuites, please do follow up.
I disagree @FiloSottile, most of the current battery-powered IoT devices doesn't have accelerated Galois mode of authentication which force us to use the software based ChaCha20-Poly1305.
That is a deal breaker for lots of devices already deployed where only hardware-accelerated AES is available. In our internal tests AES (HW), CCM (SW) is much more efficient (for a battery draining POV) than ChaCha20-Poly1305. Although there are already known flaws in AES-CCM combo I think it's worth implementing it.
Perhaps you can tell me why does IETF board included this cipher combo in TLS 1.3?
Can you reconsider this?
I'm reopening this to see how popular this request is and to look more into the AES-CCM mode (what "known flaws" are you referring to?), but 1) crypto/tls takes a minimalist approach, and 2) carrying a performant AES-CCM would probably cause us to carry extra assembly implementations, which is a deal-breaker at least for now.
referenced this issue
Sep 18, 2018
I'm also finding myself in need of an AES-CCM implementation to communicate with an IoT device (Custom protocol, not TLS, though). And again, AES-CCM is the cipher of choice due to having hardware-accelerated AES.
So +1 on this.
(Also, the attacks linked above are power analysis attacks against hardware implementations. They're not cryptanalytic attacks against the algorithm itself. I don't believe they are reasons to not include CCM)
What about an AES-CCM implementation without assembly optimizations? This will allow IoT devices with AES acceleration to connect to a server running golang code even if the server is not optimized. The bottleneck here will be probably the IoT device, not the server anyway.