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

[Michael Clark <[e-mail]>]

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.