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

["Paterson, Kenny" <[e-mail]>]

Hi Leonard,

On 18/01/2017 17:12, "Cfrg on behalf of Leonard den Ottolander"
<[e-mail] on behalf of [e-mail]> wrote:

>Hello Joan,
>
>On Tue, 2017-01-17 at 19:28 +0100, Joan Daemen wrote:
>> the related-key attacks against AES were interesting from an academic
>> point of view as they broke the security claim we made for Rijndael.
>
>https://books.google.nl/books?id=weETxBt-VAMC&pg=PA316&lpg=PA316&dq=aes
>+256+key+schedule
>+strength&source=bl&ots=GTfhsVdh7E&sig=y0ZE9_3OBCRbbpLHvq0PAAZqRmg&hl=en&s
>a=X&redir_esc=y#v=onepage&q=aes%20256%20key%20schedule%20strength&f=false
>
>A better link to the above research is
>https://eprint.iacr.org/2009/374 .
>
>This research is rather condemning even though the authors do not claim
>these attacks are entirely practical yet they do state:
>
>"While neither AES-128 nor AES-256 can be directly broken by these
>attacks, the fact that their
>hybrid  (which  combines  the  smaller  number  of  rounds  from  AES-128
> along  with  the  larger  key
>size from AES-256) can be broken with such a low complexity raises
>serious concern about the
>remaining safety margin offered by the AES family of cryptosystems."

What this extract from the abstract does not mention is a critical phrase,
in the context of the current discussion about the use of AES in TLS,
namely: "in the related-key attack model".

>This criticism is valid for all AES versions. However:
>
>"The key schedules of AES-128 and AES-192 are slightly different, since
>they have to apply more
>mixing operations to the shorter key in order to produce the slightly
>smaller number of subkeys for the
>various rounds. This small difference in the key schedules plays a major
>role in making AES-256 more
>vulnerable to our attacks, in spite of its longer key and supposedly
>higher security."
>
>AES-256 appears to be more vulnerable than AES-192 (or AES-128) to these
>attacks.

Yes, for related-key attacks. But as has been explained several times
already in this thread, they are not relevant in the TLS context.

>I pointed out the example (http://eprint.iacr.org/2009/317) because the
>remarks it makes about the AES-256 key schedule seemed to indicate
>structural weaknesses. Because Richard insisted I dug a bit deeper I
>came up with the above which seems to confirm the "hunch" I was having
>that the weak key schedule in AES-256 is a problem in itself.
>
>> However, the attacks require very sophisticated manipulations of the
>> secret key by the attacker.
>
>Please don't use arguments that might be valid for one report to
>disqualify another. (This is a request made in general, Richard seems to
>be doing this in his last post also.) The argument related key attacks
>are mostly hypothetical applies to http://eprint.iacr.org/2009/317 but
>not so much to https://eprint.iacr.org/2009/374 .
>
>I quote:
>"The attacks are particularly well suited to counter modes
>of operation (AES-CTR), since the attacker can get all the chosen
>plaintexts he needs by starting from
>just two chosen initial values and running the counter mode in a natural
>way."
>
>This kind of manipulation seems not to be that far fetched...

Unfortunately, this quote is not relevant to the point that Joan was
making. Note first that the attacks in eprint 2009/374 are still in the
related-key attack setting. The quote you give refers to the format of the
*plaintexts* needed in the attack, not the relations between *keys* needed
for the attack. The latter requirements will not be met in the TLS context
because of the way in which key derivations are performed in that
protocol. In short, related-key attacks are not a concern for the use of
AES in the TLS setting.

>> As for including AES-192 in TLS, I don't see any benefits.
>
>AES-192 has been specified as a valid cipher just as much as AES-128 and
>AES-256. The exclusion from TLS was entirely arbitrary. The motivation
>for its exclusion is unclear. The wording in RFC-3268 is vague at best:
>
>"The AES supports key lengths of 128, 192 and 256 bits. However, this
>document only defines ciphersuites for 128- and 256-bit keys. This
>is to avoid unnecessary proliferation of ciphersuites."
>
>The fact that AES-256 appears to be not quite as strong as AES-192 might
>render the "proliferation of AES-192" much less unnecessary.

Again, in the related-key attack setting, which is not relevant for TLS.

>Though AES-192 is not a 256 bit cipher it seems still to be
>significantly stronger than AES-128 and does not share the weaknesses of
>AES-256. This I believe is a strong argument to include it in TLS.

It's not, because the related-key attack setting is not relevant for TLS.

>I do not see how the fact that we now have ChaCha20 is an argument not
>to include AES-192. AES-192 has been specified just as much as its
>siblings so it's exclusion from TLS is nothing but arbitrary. Why should
>we only have one algorithm to choose from? (Again, like I wasn't arguing
>against Camellia or AES-128 earlier so am I not arguing against ChaCha20
>here. But until we are all chachaing, salsaing and elliptic curving I
>would like access to decent crypto that is well established, well
>scrutinized and readily available.)
>
>Implementations are available in many cases (eg. openssl) and need only
>to be "unlocked" by making entries available in the spec. From the
>research I put forward AES-256 seems to have major flaws in the key
>schedule that AES-192 does not suffer from.

Only in the related-key attack setting, which is not relevant for TLS.


>On the one hand people argue against inclusion of AES-192 because it is
>not PQ-resitant, on the other hand people argue I should use AES-128. It
>all seems, again that word, rather arbitrary. And in general, the PQ
>argument does not hold for the current situation: We need decent crypto
>not just PQ but now as well.
>
>To sum up:
>
>- AES-192 was excluded from TLS for arbitrary reasons.
>- AES-256 has known weaknesses in its key schedule that some researcher
>consider severe.

Only in the related-key attack setting, which is not relevant for TLS.


>- AES-192 offers better security than AES-128. There is serious doubt
>AES-256 can offer the same level of security. This makes AES-192 a valid
>alternative.

Only in the related-key attack setting, which is not relevant for TLS.


Regards,

Kenny

>- Implementations of AES-192 are readily available.
>
>Regards,
>Leonard.
>
>-- 
>mount -t life -o ro /dev/dna /genetic/research
>
>
>_______________________________________________
>Cfrg mailing list
>[e-mail]
>https://www.irtf.org/mailman/listinfo/cfrg