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

[Michael Clark <[e-mail]>]

On 25/12/14 9:57 am, Watson Ladd wrote:
> On Wed, Dec 24, 2014 at 8:01 PM, Michael Clark <[e-mail]> wrote:
>> Hi Peter,
>>
>> Someone pointed out RFC 7366 to me off list. I will read. I like the
>> idea of encrypt-then-MAC being a core requirement for TLSv1.3.
> 
> And we have already made AEAD modes a requirement in the TLS 1.3
> draft. I don't see the argument for adding RFC 7366 in addition to
> these.
>>
>> Before I've read through can we do this with it?
>>
>> AES-256-GCM + hmac_null   = 128 bits authentication
>> AES-256-CBC + hmac_sha128 = 128 bits authentication
>>
>> AES-256-GCM + hmac_sha128 = 256 bits authentication
>> AES-256-CBC + hmac_sha256 = 256 bits authentication
>>
>> AES-256-GCM + hmac_sha256 = 384 bits authentication
>> AES-256-CBC + hmac_sha384 = 384 bits authentication
>>
>> I like the idea of >= 256 bits authentication, and the idea of the
>> combination of a cipher based MAC and PRF based MAC for AES-GCM, given
>> the properties of the AES-GCM CTR mode 'variant' and GHASH GF(2^128).
> 
> I don't agree with this analysis.
> 
> For starters, GCM is not a PRF based authenticator. The security of
> GCM authentication decreases with the length of the message, while the
> security of HMAC authentication does not, while the numbers above
> don't recognize this.

This is kind of my point. There is broken MAC-then-encrypt for non AEAD
ciphers and AEAD ciphers with 128-bit tags where the authentication
decreases with the length of the messages (non PRF based MACs based on
finite fields).

> Secondly, attacks on authentication have to be online, and a failed
> guess results in connection teardown. An attacker with a 2^{-64}
> probability of forgery on any given connection would take decades to
> inject data into a TLS connection, even if the connection restarted 1
> million times a second.  By contrast, recovering data from a key 64
> bits in length is a rather easy computation today, and will be easier
> tomorrow.

Sorry I don't have numbers, however if you are attacking a target where
you know the message length of a oft repeated transaction and have a
128-bit GCM auth tag (theoretically ~64-bits strength if you have
captured texts) then there is a possibility you could forge auth tags.
DHTs are fast and disks are cheap. There may be some facilities that
have 100 million threads and more drives (if you knew Intel's order
book). I say dictionary lookup would be feasible within the next few
years which has to be the time domain that is considered. sha1 is being
deprecated elsewhere. Sure people have more time to attack CA certs.

> Thirdly, the weak keys of GCM are a red herring. Using the logic of
> those papers, every GCM key is weak, as there is a known difference
> between messages that will lead to a forgery if a given key is used.
> One could make the same argument against CBC-MAC: if an attacker knows
> the key, they can produce forgeries.
> 
> Fourthly, this ignores performance. Recent Intel chips have a
> significant amount of acceleration for AES-GCM that cannot be used for
> other modes. The parallelism of CTR mode permits hiding the latency of
> the AES instructions, while the carryless multiply can't accelerate
> HMAC. It also ignores implementation complexity: making two passes
> over the data, with different algorithms, is more complex than one.

I understand. I've read the code. I am aware of the properties of
GF(2^128) finite fields. There are all arguments for performance and
scary when it comes to the potential to forge tags for larger messages.
There is huge parallelism potential in AES-GCM. I know software
implementations with AES-NI are doing 4 blocks but the potential is not
limited to 4 blocks.

> In short, there are no real security gains from this proposal. But
> there are large losses in simplicity and performance, as now the
> existing record layer transformations have to be redesigned and
> stacked in ways they aren't currently. One can't say "such and such an
> algorithm has more bits, therefore it is more secure". You have to
> look at the exact claims, and see how they apply to the way the
> algorithms are used.

I see it a different way. hmac_null plus AEAD_AES_GCM allows for the
current level of integrity. The addition of a PRF based MAC provides
more message integrity. No doubt. I can't see a good argument against an
option for more integrity if a user wants it. I'm always worried by
people who trust the level of integrity in algorithms that have
deliberately sacrificed security for performance (32-bits less entropy
in IV, not following CTR IV method, along with GCM's parallel GHASH and
the properties of GF(2^128). This is all for speed. Good for a
SSL-everywhere plain text replacement. Fine for Facebook and Google
search. I'm sure the banks wouldn't trust it. Anyway, they have external
factors to mitigate flaws in TLS.

Consider it like insurance. The 'option' of adding authentication bits
with a PRF gives you *added* integrity that does not decrease based on
message length. It's up to a server whether it is used or not. I'm not
making any argument about what are good defaults, just an option for
more integrity.

We will have to agree to disagree. I don't trust AES_GCM given my read
of the spec. I noticed a shift towards better properties of prime sized
fields GF(P) and GF(2^p); where p is prime. It's a fallacy to trust the
security of AES_GCM when there are known weaknesses. We don't have to do
any math to know that adding integrity with a PRF based MAC would
mitigate future flaws in AES_GCM. i.e. reserve.