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

[Leonard den Ottolander <[e-mail]>]

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&sa=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."

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.

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...

> 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.

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.

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.

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.
- 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.
- Implementations of AES-192 are readily available.

Regards,
Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research