Re: [Cfrg] A little room for AES-192 in TLS?

[Tony Arcieri <[e-mail]>]

On Mon, Jan 16, 2017 at 11:07 AM, Leonard den Ottolander <
[e-mail]> wrote:

> How about a scenario where an adversary is able to compromise the
> software in such a way that related keys are being generated
> occasionally and possibly even used for encryption of known plain text
> (protocol headers come to mind)? This scenario is assuming the adversary
> is not fully in control of the source code but is capable to inject
> subtle bugs "under the radar". Would AES-192 hold up better in such a
> scenario than AES-256?
>

Even in the event an attacker was able to pull off some sort of fault
attack and create related keys, as others have already noted the other side
will notice these keys are wrong and snap shut before the attacker can pull
off the rest of the attack. The next time you connect it will rekey. I
personally cannot think of any way to make TLS behave in such a way related
key attacks are even possible, even giving an attacker such a powerful tool
as precision fault attacks (and with such a powerful tool, they could
likely change the client's preferred ciphersuites as well).

This is a circular argument. AES-192 is not generally used because it is
> not in the specifications.


This argument holds not just for TLS, but pretty much any protocols that
use AES. In practice, nobody uses AES-192, because there is little reason
to choose it over either of the other options.


> Bruce Schneier wrote about this in 2009:
> https://www.schneier.com/blog/archives/2009/07/another_new_aes.html &
> https://www.schneier.com/academic/paperfiles/paper-rijndael.pdf
>
> In the blog he states "The attack exploits the fact that the key
> schedule for 256-bit version is pretty lousy -- something we pointed out
> in our 2000 paper -- but doesn't extend to AES with a 128-bit key."
>

Sounds like you just made an argument for AES-128.

-- 
Tony Arcieri