Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis

[Russ Housley <[e-mail]>]

The folks doing the DTLS profile for low-end devices have chosen AES-CCM because they have hardware support for it.  I think we should include it to promote interoperability.

Russ


On Dec 20, 2014, at 7:19 PM, Michael Clark wrote:

> On 21/12/14 2:21 am, Tapio Sokura wrote:
>> Hello,
>> 
>> On 20.12.2014 10:52, Michael Clark wrote:
>>>      CipherSuite TLS_DHE_DSS_WITH_AES_128_EAX_SHA256
>>>      CipherSuite TLS_DHE_DSS_WITH_AES_256_EAX_SHA384
>>>      CipherSuite TLS_ECDHE_DSS_WITH_AES_128_EAX_SHA256
>>>      CipherSuite TLS_ECDHE_DSS_WITH_AES_256_EAX_SHA384
>>>      CipherSuite TLS_DHE_DSS_WITH_AES_128_CCM_SHA256
>>>      CipherSuite TLS_DHE_DSS_WITH_AES_256_CCM_SHA384
>>>      CipherSuite TLS_ECDHE_DSS_WITH_AES_128_CCM_SHA256
>>>      CipherSuite TLS_ECDHE_DSS_WITH_AES_256_CCM_SHA384
>> A bit off-topic on the actual question, but: Is DSS used anymore? Should
>> these be ECDSA instead?
> 
> Thanks. Yes. I did mean ECDSA, the eliptic curve variant of DSA (DSS).
> It was a mistake on my part.
> 
> Someone mentioned off list mentioned the AEAD ChaCha20-Poly1305 draft,
> however I note the authenticator is still 16 bytes (128 bits). I had
> seen the draft but wasn't sure if it was going to be included in TLSv1.3.
> 
> It occurred to me that a (perhaps not fair) comparison would be with
> using MD5 which is 128 bits. MD5 has collisions. GHASH finite field and
> the cipher based MACS (including Poly1305) should be safe in this regard
> due to their construction. My understanding is that cipher based MACS
> are vulnerable to attacks that reverse rounds of the cipher after a
> certain number of texts have been seen (birthday attack). The fact that
> the nonce has a short lifetime probably makes this intractible however I
> began wondering about the 'designed in' lower entropy in GCM (IV suffix
> on first block 32-bits starting at 0x00000001 versus incrementing the
> whole IV and preserving entropy). Both this; and properties of the
> parallelizability GHASH construction. The IV construction effectively
> means only 96 bits need to be brute forced to forge an authenticator
> (unless in practice a random initial counter was used) as we know the
> counter for each block. It seems to be a designed in weakness along with
> excellent parallelizability. CCM and EAX are not exploitable in this manner.
> 
> The main point was besides eavesdropping potential, was the ability of
> an attacker to inject random bit errors by finding authenticator
> collisions; i.e. message integrity; and also the parallelizability of
> GCM. Parallelizability lowering the barrier to anyone with sufficient
> resources. AES-GCM and AES-CCM are the only two implemented AEAD
> ciphers. The later is not present in openssl, boringssl, libressl (last
> time I looked).
> 
> The thought that occurred to me was the idea of having a 256-bit
> authenticator with a 256-bit cipher. In practice we use 256-bit and
> 384-bit MACs. It's whether we consider the AEAD MAC as an "error
> correction code" or a "cryptographic MAC". People are widely deploying
> 256-bit and 384-bit MACs in areas where a "cryptographic MAC" is
> required. I guess it is also dependent on the time window (which in TLS
> is short) however someone with acres/hectares of computers could make a
> DHT (Distributed Hash Table). Drives are cheap and DHTs are fast for
> vast amounts of data. Reasoning is 32 bits lost entropy, n bits in
> storage, m bits computed online (from looking at table based GHASH).
> 
> OMAC1/CMAC is limited to the block size of the underlying cipher which
> is 128 bits even with AES-256. EAX just seems simpler than CCM.
> 
> Just thought I would question the convention and established thought...
> 
> Cheers,
> Michael.
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls