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

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

On Mon, 2017-01-16 at 19:18 +0000, Salz, Rich wrote:
> > And how can one extrapolate the attacks and analyses mentioned in
> > http://eprint.iacr.org/2009/317 to use them as an indication of possible
> > cryptanalytic advances?
> 
> One simple idea, which I have suggested in the TLS mailing list, is
> that you search to see if anyone has done anything in this area in the
> past eight years.

Are you suggesting that because this research is 8 years old its
findings are not valid? So far noone has really answered the question if
the aforementioned analysis indicates that AES-192 might be more
resistant to cryptanalysis than AES-256.

So although I don't think the fact that the research I reference is 8
years old invalidates it in any way I dug around a bit.

http://eprint.iacr.org/2010/248 improves the attack on AES-192 from
2^176 to 2^169. The original attack against AES-256 in
http://eprint.iacr.org/2009/317 had complexity of 2^119 which they
improved to 2^99.5 soon after original publication.

And there is

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

Advances in Cryptology - EUROCRYPT 2010: 29th Annual International
Conference...

This is only a partial paper, but I'll cite from the conclusions of Key
Recovery Attacks of Practical Complexity, 8 Conclusions (page 316):

"The main problem seems to be the key schedule of AES-256, which is "not
of industrial strength": It does not mix the initial key sufficiently,
it is too linear, and as a result it has unusually long key
differentials of probability 1. In addition the similarity between the
key schedule and the data encryption in AES makes it possible to
repeatedly cancel data differences with corresponding key differences
over many rounds. Ironically, the new attacks work best against AES-256
(which was supposed to be the strongest member of the AES family), and
do not currently seem to work against AES-128."

"The most disturbing aspect of the new attacks is that AES-256 can no
longer be considered as a safe black box construction, which can be
dropped into any security application with little thought about how it
is used."

> > > used almost exclusively. I think the general trend is to switch to
> > > AES-256 in new systems.
> > 
> > This is a circular argument.
> 
> Not quite.  It is an argument saying that we are using AES256 in spite of what one paper says.

I was responding to the first part of that paragraph: "In practice,
AES-192 is generally not used: AES-128 and AES-256 are used
almost exclusively." To that I say, AES-192 is not being used because
it's not in the specs. Then refusing to add it to the specs is what I
call a circular argument. And you cannot argue nobody wants to use it as
it is not available for use. If I wanted to I could not use AES-192
except in private use scenario's as noone is offering such ciphers, i.e.
there is noone to "talk AES-192 to". If such ciphers were available and
nobody would use them then you could draw the conclusion that "nobody
wants to use it".

> > I don't see how one can qualify the addition
> > of a few references to a list as "complex".
> 
> Have you done much software deployment, especially at Internet scale?
> This is about far more than just adding IANA entries.  Did you see my
> post in the  TLS group that talked to this?

I'm just not entirely convinced by your arguments. Have you seen any
breakage in middleboxes when the ARIA ciphers were added in 2011? I
acknowledge adding ciphers is not a zero effort, but to describe it as
complex is inaccurate.

As for software implementation, I already argued that if the cipher is
available in the software adding references so it can be used is
trivial. And implementers can always ignore the new ciphers in the list.
It's not like openssl broke because it ignores the ARIA ciphers
altogether.
 
> > So the question remains if AES-192 has certain characteristics that warrant
> > inclusion. The fact that "the key schedule for 256-bit version is pretty lousy"
> > and the mentioned attacks have complexity of < 2^100 for AES-256, but >
> > 2^179 for AES-192 might speak for it.
> 
> Has anyone but Bruce shared that viewpoint?

Well clearly the authors of Related-key Cryptanalysis of the Full
AES-192 and AES-256, Alex Biryukov and Dmitry Khovratovich agree with
him on the relatively poor quality of the key schedule of AES-256 even
though their wording is not quite as strong as his. Plus the authors of
the EuroCrypt article quoted above (the two previous authors and Orr
Dunkelman, Nathan Keller and Adi Shamir).

And there's references to that study in http://eprint.iacr.org/2011/710
and http://eprint.iacr.org/2016/025 so I guess you could count those
authors too.

Regards,
Leonard.

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