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

From: Leonard den Ottolander <[email-masked]>
Date: Sat, 14 Jan 2017 20:08:01 +0100

L.S.,

Seeing how AES-192 seems to hold up well against related key attacks (at
least the (theoretical) one described in
http://eprint.iacr.org/2009/317) I am rather surprised no AES-192
ciphers have been defined for TLS
(http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4). I feel the cipher is being treated rather stepmotherly.

I do understand that the number of slots for ciphers in the above list
is somewhat limited and additions should be considered carefully.

However, seeing that there are over 60 TLS_DH_* ciphers in that list and
well over 60 CAMMELIAs - to be clear, I am not arguing against the
latter algorithm - the argument not to include AES-192 ciphers in that
list seems somewhat arbitrary.

Also there still seems to be plenty of space available (slots 0x01-55,*
and 0x56,0x01-0xC0,0x00) until this "definition by permutation" approach
can be replaced by a cheaper "definition by slot" where the slots are
chained, i.e. using identifiers for key exchanges, asymmetrical ciphers,
symmetrical ciphers and block modes separately.

Even though I have an interest in mathematics and number theory I do not
claim to have anything more than a rudimentary understanding of the
mathematics involved so please correct me where my insights are wrong.

On superficial reading of http://eprint.iacr.org/2009/317 I grasp that
the higher resistance of AES-192 vs. AES-256 is caused by the fact that
"the key schedule of AES-192 has better diffusion".

What is causing this better diffusion? Is it the fact that the key size
of AES-192 is not, and the block size is a power of 2? I seem to
remember reading somewhere about DES that the odd key size vs the block
size was considered a strength.

Have the same analyses been done for AES-128? How is AES-128 holding up
against these attacks?

Seeing that we live in "a world of 2^50 keys" and the fact that AES-192
seems to be more robust against related key attacks than AES-256 is I
would like to suggest the inclusion of a few AES-192 ciphers in TLS,
lets say all equivalents of AES-256, possibly reduced by the ciphers
that use hashes weaker than SHA256. Not sure if "DH" and "DH_anon" are
different approaches, but those could be excluded as well, resulting in
something like this list:

TLS_RSA_WITH_AES_192_CBC_SHA256
TLS_DHE_DSS_WITH_AES_192_CBC_SHA256
TLS_DHE_RSA_WITH_AES_192_CBC_SHA256
TLS_RSA_WITH_AES_192_GCM_SHA384
TLS_DHE_RSA_WITH_AES_192_GCM_SHA384
TLS_DHE_DSS_WITH_AES_192_GCM_SHA384
TLS_PSK_WITH_AES_192_GCM_SHA384
TLS_DHE_PSK_WITH_AES_192_GCM_SHA384
TLS_RSA_PSK_WITH_AES_192_GCM_SHA384
TLS_PSK_WITH_AES_192_CBC_SHA384
TLS_DHE_PSK_WITH_AES_192_CBC_SHA384
TLS_RSA_PSK_WITH_AES_192_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_192_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_192_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_192_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_192_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_192_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_192_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_192_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_192_GCM_SHA384
TLS_ECDHE_PSK_WITH_AES_192_CBC_SHA384
TLS_RSA_WITH_AES_192_CCM
TLS_DHE_RSA_WITH_AES_192_CCM
TLS_RSA_WITH_AES_192_CCM_8
TLS_DHE_RSA_WITH_AES_192_CCM_8
TLS_PSK_WITH_AES_192_CCM
TLS_DHE_PSK_WITH_AES_192_CCM
TLS_PSK_WITH_AES_192_CCM_8
TLS_PSK_DHE_WITH_AES_192_CCM_8
TLS_ECDHE_ECDSA_WITH_AES_192_CCM
TLS_ECDHE_ECDSA_WITH_AES_192_CCM_8

Thank you for considering this request.

Regards,
Leonard den Ottolander.

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

---

From: Taylor R Campbell <[email-masked]>
Date: Sat, 14 Jan 2017 19:50:26 +0000

Date: Sat, 14 Jan 2017 20:08:01 +0100
   From: Leonard den Ottolander <[email-masked]>

I would be surprised if TLS relied in any way on resistance to
related-key attacks.  The only advantage for TLS's sake would be in
situations requiring greater performance than AES-256 can attain,
where a security level below 2^96 against future quantum cryptanalysis
or multi-target attacks are acceptable.

That said, proposals for TLS are probably better heard at the IETF
working group for TLS.

It turns out that handing inexpert users a dizzying array of
cryptographic acronym soups and seasonings to combine securely does
not tend to yield very good results.  The enormous enumeration of
precombined cipher suites is bad enough; asking users to make sensible
choices to combine their parts is worse.

---

From: Leonard den Ottolander <[email-masked]>
Date: Sun, 15 Jan 2017 17:57:07 +0100

Hello Taylor,

On Sat, 2017-01-14 at 19:50 +0000, Taylor R Campbell wrote: 
>    (http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4).
>    I feel the cipher is being treated rather stepmotherly.
> 
> related-key attacks.

I would say any encryption scheme worth its salt relies on resistance
against any kind of attack. With its constant key regeneration TLS seems
amongst the first use cases where related key attacks could be a
concern. More so than in f.e. disk encryption.

> The only advantage for TLS's sake would be in

Well, assuming Shor and/or Grover half the effective strength of
symmetric ciphers and these related key attacks were to be practical the
effectiveness of AES-256 would fall below 2^50 against ~ 2^89 for
AES-192. Your consideration would disqualify AES-256 in that scenario as
well.

Although both attacks might improve the fact that the research states
"the key schedule of AES-192 has better diffusion" seems to imply it is
fundamentally more resistant against related key attacks. If this is
true and related key attacks are a concern AES-192 might be favourable
over AES-256. Not for its greater performance but because it is actually
more resistant against related key attacks than AES-256.

> choices to combine their parts is worse.

Cipher choices are mostly made by system administrators and software
implementers, not so much by inexpert users. Has your browser or SSH
client ever asked you which cipher you would want to use for your
connection?

Also, the amount of choices is not significantly increased (seeing that
most possible iterations are already listed), only the way they are
represented. So I am not sure the splitting into slots makes the array
as a whole more dizzying. Whether the slots are separate or concatenated
does not fundamentally change the choices the sysadmin has to make.

But we are drifting slightly of topic here. My reason for sending an
email is to establish whether or not AES-192 is indeed inherently more
secure against related key attacks than AES-256, and thus more resilient
against f.e. manipulation of the generated keys. And perhaps some
insights whether this is related to the "skewed" cipher vs. block size.

Regards,
Leonard.

P.S. Please reply to list only.

---

From: Taylor R Campbell <[email-masked]>
Date: Sun, 15 Jan 2017 20:59:31 +0000

Date: Sun, 15 Jan 2017 17:57:07 +0100
   From: Leonard den Ottolander <[email-masked]>

Only very unusual protocols ever use related keys.  In sensible
protocols, every key is drawn independently uniformly at random.

---

From: Leonard den Ottolander <[email-masked]>
Date: Mon, 16 Jan 2017 15:43:38 +0100

> protocols, every key is drawn independently uniformly at random.

Protocols that are designed to use related keys? I hope not!

Compare http://eprint.iacr.org/2009/317 4.1 Related-key attack model:

"Compared to other cryptanalytic attacks in which the attacker can manipu-
late only the plaintexts and/or the ciphertexts the choice of the relation between
secret keys gives additional degree of freedom to the attacker. The downside of
this freedom is that such attacks might be harder to mount in practice. Still,
designers usually try to build "ideal" primitives which can be automatically used
without further analysis in the widest possible set of applications, protocols, or
modes of operation. Thus resistance to such attacks is an important design goal
for block ciphers, and in fact it was one of the stated design goals of the Rijndael
algorithm, which was selected as the Advanced Encryption Standard."

So the question remains if indeed AES-192 is inherently more resistant
to this kind of attack (more of an "ideal primitive" in this respect)
than AES-256 or do I read too much in the remark "the key schedule of
AES-192 has better diffusion" in 6 Attack on AES-192?

Regards,
Leonard.

---

From: John Mattsson <[email-masked]>
Date: Mon, 16 Jan 2017 15:59:13 +0000

Note that there are trivial generic related-key attacks on AES-192 with #K
= D = T = M = 2^96

http://dx.doi.org/10.1080/0161-118791861749

Regards,
John

On 2017-01-16, 15:43, "Cfrg on behalf of Leonard den Ottolander"
<[email-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>Cfrg mailing list
>[email-masked]
>https://www.irtf.org/mailman/listinfo/cfrg

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Jan 2017 08:27:12 -0800

Generally, I think the sense of the WG is to try to minimize the number of
ciphers/suits.

Speaking personally, what would make me be in favor of adding AES-192 would
be
some statement from CFRG that they thought that it was significantly
stronger than
AES-256. Absent that, I think it would be better to leave it out of TLS.

-Ekr

---

From: "Paterson, Kenny" <[email-masked]>
Date: Mon, 16 Jan 2017 17:37:25 +0000

Hi,

On 16/01/2017 16:27, "Cfrg on behalf of Eric Rescorla"
<[email-masked] on behalf of [email-masked]> wrote:

>Generally, I think the sense of the WG is to try to minimize the number
>of ciphers/suits.
>
>
>Speaking personally, what would make me be in favor of adding AES-192
>would be

Speaking without my co-chair's hat on...

I don't think related-key attacks are a particular concern for TLS. So I
don't think there's a strong argument for supporting AES-192 in the TLS
1.3 protocol specification.

Anyone else from CFRG have an opinion on this?

Cheers

Kenny 

>
>
>-Ekr
>
>
>
>
>On Mon, Jan 16, 2017 at 7:59 AM, John Mattsson
><[email-masked]> wrote:
>
>>Compare 
>http://eprint.iacr.org/2009/317 <http://eprint.iacr.org/2009/317> 4.1
>Related-key attack model:
>>

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Mon, 16 Jan 2017 21:09:01 +0300

‎Dear colleagues,

Thank you for this discussion!

To be honest, I cannot imagine an adversary model (with any relation to practice) for TLS, for which AES-192 would be useful - I agree with Kenny about related-key attacks here.

So I don't see any strong points to add AES-192 to 1.3 too. 

Best regards,
Stanislav Smyshlyaev

‎
  Исходное сообщение  
От: Paterson, Kenny
Отправлено: понедельник, 16 января 2017 г., 20:37
Кому: Eric Rescorla; John Mattsson
Копия: [email-masked]; Leonard den Ottolander
Тема: Re: [Cfrg] A little room for AES-192 in TLS?

Hi,

Cheers

Kenny

---

From: Tony Arcieri <[email-masked]>
Date: Mon, 16 Jan 2017 10:09:33 -0800

> Anyone else from CFRG have an opinion on this?

I would rate the chances of a related key attack against TLS as
"vanishingly small". The use of key derivation functions ensures keys will
not be related.

In practice, AES-192 is generally not used: AES-128 and AES-256 are used
almost exclusively. I think the general trend is to switch to AES-256 in
new systems.

Adding AES-192 ciphersuites sounds like an awful lot of additional
complexity both for specifiers and implementers for something I suspect no
one will ever use. Personally I would rather see that energy go into e.g.
post-quantum ciphersuites.

-- 
Tony Arcieri

---

From: Leonard den Ottolander <[email-masked]>
Date: Mon, 16 Jan 2017 20:07:31 +0100

Hello Tony,

> "vanishingly small". The use of key derivation functions ensures keys will

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?

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?

> almost exclusively. I think the general trend is to switch to AES-256 in

This is a circular argument. AES-192 is not generally used because it is
not in the specifications. Using that as an argument not to put it in
the specs is well, circular.

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

He even goes so far as to state "And for new applications I suggest that
people don't use AES-256."

> one will ever use.

A software like f.e. OpenSSL has an AES implementation that does support
AES-192. I'm not sure if the GCM code needs modifications for it to work
with AES-192, but for the rest all that is required is to add the
references to the new ciphers in the source code. I don't see how one
can qualify the addition of a few references to a list as "complex".

> Personally I would rather see that energy go into e.g.

I thought symmetric ciphers are considered somewhat quantum resistant so
I'm not sure the PQ argument is very valid here. Also, if AES-192 is
inherently more secure than AES-256 that would probably also be the case
in a PQ world.

By the way, I'm all for the implementation and specification of post
quantum symmetric ciphers. I could imagine something along the lines of
triple AES (GCM3 with mask 1 and 2 concatenated and XORed in the middle
with either mask 1 or 2 again.) Or perhaps an extension of Rijndael to
use a block of 256 bits and a key of 480 :) .

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.

Regards,
Leonard.

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 16 Jan 2017 21:14:16 +0200

> subtle bugs "under the radar". Would AES-192 hold up better in such a

The key derivations are interop-critical, so compromises like that would
be found real quick (since essentially nothing would work anymore).

And there is at least one place in TLS 1.2 that can be undetectably
compromised by a server in a way that lets adversary passively decrypt
most connections.

-Ilari

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 16 Jan 2017 19:18:32 +0000

> 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)?

To the best of my knowledge, partial compromise of software is not something that has been in the IETF threat model.  "All or nothing" if you will.

> http://eprint.iacr.org/2009/317 to use them as an indication of possible

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

It's been nine years.  Surely *something* must have happened that you can find?

---

From: John Mattsson <[email-masked]>
Date: Mon, 16 Jan 2017 20:05:25 +0000

>for AES-256, but > 2^179 for AES-192 might speak for it.

AES-192 is not stronger then AES-256 against related-key attacks except in
the special case were #keys is very small. And even if it was, I do not
think that alone makes a case for AES-192 in TLS. If HKDF is secure, then
there are no related AES keys. And if HKDF is not secure, then TLS should
replace HDKF rather than AES.

John

---

From: Tony Arcieri <[email-masked]>
Date: Mon, 16 Jan 2017 13:50:32 -0800

> subtle bugs "under the radar". Would AES-192 hold up better in such a

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

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

> 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

---

From: Leonard den Ottolander <[email-masked]>
Date: Tue, 17 Jan 2017 15:07:59 +0100

On Mon, 2017-01-16 at 19:18 +0000, Salz, Rich wrote:
> 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."

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

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

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 17 Jan 2017 14:48:02 +0000

> Are you suggesting that because this research is 8 years old its findings are
> not valid?

Yes, kinda.  If the sky really was falling eight years ago, then where are the other papers?

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

Well, luckily, that is not the case with TLS.  The particular attack about keys, as has been explained, isn't relevant to AES-in-TLS.  Your compromise, while not only outside the typical IETF scope, has been shown to fail as the other side will abort the connection.

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

Luckily we use AES128.

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

Yes.

> I
> acknowledge adding ciphers is not a zero effort, but to describe it as complex
> is inaccurate.

We disagree.

You can write up an individual RFC that defines AES192 ciphers for use in TLS, and ask IANA to register them, and then "let the market decide."  I suggest you focus on a couple, and not try for full parity by defining a couple of dozen, as the registrar is likely to reject it.

Or you can keep posting here (and as previously pointed out, more appropriately the TLS list) and see if you can convince anyone.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 17 Jan 2017 17:51:01 +0200

> Or you can keep posting here (and as previously pointed out, more appropriately the TLS list) and see if you can convince anyone.

An individual RFC (or even an RFC from the TLS WG) is no substitute for convincing people.  There are over 8000 RFCs. None of us implement all of them.

So an AES-192 RFC won’t cause universal support for these ciphersuites any more that RFC 6209 caused universal support for ARIA.

He can even donate code to OpenSSL (AES-192 already exists, but you need the ciphersuites) but he still need to convince people (you?) to (i) accept it and (ii) make it part of the default or “strong” or whatever the recommended configuration is called these days.

And he’ll need to convince browser maintainers to add it to the browsers. And then there’s the other dozens of implementations.

If you want a technology implemented and deployed, you still need to convince a lot of people. RFCs are (relatively) easy.

Yoav

---

From: William Whyte <[email-masked]>
Date: Tue, 17 Jan 2017 11:03:32 -0500

It seems like we need a better 256-bit algorithm than AES-256: the related
key attacks might not be a concern in TLS, but if use of AES-256 in TLS
causes its widespread use in other contexts, it will sooner or later be
used in a context where the related key attacks matter. I would support
deprecating AES-256 throughout IETF in favor of a better alternative.

It doesn't seem like AES-192 is the right choice for that alternative.
Among other things, it's not 256-bit :-).

What *should* CFRG be recommending as a 256-bit symmetric algorithm?

Cheers,

William

On Tue, Jan 17, 2017 at 9:48 AM, Salz, Rich <[email-masked]> wrote:

> findings are
> longer
> Well, luckily, that is not the case with TLS.  The particular attack about
> keys, as has been explained, isn't relevant to AES-in-TLS.  Your
> compromise, while not only outside the typical IETF scope, has been shown
> to fail as the other side will abort the connection.
>
> complex
> You can write up an individual RFC that defines AES192 ciphers for use in
> TLS, and ask IANA to register them, and then "let the market decide."  I
> suggest you focus on a couple, and not try for full parity by defining a
> couple of dozen, as the registrar is likely to reject it.
>
> Or you can keep posting here (and as previously pointed out, more
> appropriately the TLS list) and see if you can convince anyone.
>
>
>

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 17 Jan 2017 08:07:40 -0800

> What *should* CFRG be recommending as a 256-bit symmetric algorithm?

ChaCha20 uses a 256-bit key:

https://tools.ietf.org/html/rfc7539

-- 
Tony Arcieri

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 17 Jan 2017 11:17:36 -0500

Please no, just no.

Use 128 bit AES or 256 bits. Please do not create more options. The idea
that there is a need for a cipher between 10 and 14 rounds is just not
sensible. Either you are on the bleeding edge or you take a 40% performance
hit.

I am now of the opinion that all Key Agreement schemes should use a Key
Derivation function, RSA included. So even if your Key Agreement only
delivers 128 bits worth of work factor, you can still use a 256 bit cipher.

If you are doing a master key agreement plus an ephemeral, you should use
the master key agreement to salt the key derivation and so even with 128
bits of work factor on each you will have a total of 256 bits.

Rather than add pointless new cipher suites, I would like to see the key
derivation function fixed so that the ephemeral step cannot weaken the
strength of the agreed key.

---

From: Ted Krovetz <[email-masked]>
Date: Tue, 17 Jan 2017 08:20:39 -0800

> https://tools.ietf.org/html/rfc7539 

If you model Chacha's internal hash function as a 48-byte-to-64-byte PRF, then it is secure against related keys too.

Chacha works by supplying 48 byte (Key || Nonce || Counter) to Chacha's internal hash function repeatedly, each time with a counter increment. If Chacha's internal hash function is a PRF, then clearly *any* change in the key produces independent output.

---

From: Joan Daemen <[email-masked]>
Date: Tue, 17 Jan 2017 19:28:43 +0100

Dear all,

the related-key attacks against AES were interesting from an academic 
point of view as they broke the security claim we made for Rijndael.

However, the attacks require very sophisticated manipulations of the 
secret key by the attacker. For example, even a protocol that would 
allow an attacker to add (or XOR) a value of her choice to the key 
before being used in AES would not allow mounting the attack. If you are 
interested, you can read the paper Vincent and I wrote "On the 
related-key attacks against AES" available at e.g. 
http://jda.noekeon.org/

As for including AES-192 in TLS, I don't see any benefits.

Kind regards,

Joan Daemen

---

From: Leonard den Ottolander <[email-masked]>
Date: Wed, 18 Jan 2017 18:12:42 +0100

Hello Joan,

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

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Jan 2017 12:53:02 -0500

> - Implementations of AES-192 are readily available.
​AES 192 was excluded for the perfectly good reason that there is no
compelling argument for inclusion.

I would like to see the number of suites reduced because the strength of a
cryptographic system depends on the strength of the weakest cipher. Thus
adding ciphers to a system invariably weakens it.

The only way to improve security is to eliminate ciphers. AES 128 is
necessary, so is AES 256. ​I have never seen a point to 192.

If the AES key schedule is bjorked, time for a new cipher comp. At one
point there was the possibility of a really fun itinerary, but the
governments that might have sponsored a non-US cipher standard are not
exactly crypto friendly right now.

---

From: Leonard den Ottolander <[email-masked]>
Date: Wed, 18 Jan 2017 19:11:48 +0100

Hello Phillip,

> adding ciphers to a system invariably weakens it.

It appears AES-256 is a weaker link than AES-192 so your general
argument about more is less seems invalid in this case. AES-256 shows
weaknesses that are not so prominent in AES-192.

> necessary, so is AES 256. ​I have never seen a point to 192.

I'm trying to make exactly that point :-) . AES-192 does not suffer from
the same weaknesses as AES-256 so the former is probably a more robust
cipher choice than the latter.

> exactly crypto friendly right now.

The problems with the key schedule are with AES-256 specifically. Not
with AES in general.

I forgot to mention that AES-192 profits from the hardware support (CPU
AES instructions) that exist. This is not (yet) true for new ciphers.

Regards,
Leonard.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Jan 2017 13:15:58 -0500

On Wed, Jan 18, 2017 at 1:11 PM, Leonard den Ottolander <
[email-masked]> wrote:

> ​\
​
Oh really, the work fact of AES 256 is lower than that of AES 192? Please
show me the paper.

If AES 256 falls then AES goes completely. There is no middle ground.

​
> cipher choice than the latter.

​I see no evidence that the work factor of AES 256 is less than 2^192. ​

---

From: "Paterson, Kenny" <[email-masked]>
Date: Thu, 19 Jan 2017 16:02:49 +0000

Hi Leonard,

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

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

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

>AES-256 appears to be more vulnerable than AES-192 (or AES-128) to these

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

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

>render the "proliferation of AES-192" much less unnecessary.

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

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

>schedule that AES-192 does not suffer from.

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

>- AES-256 has known weaknesses in its key schedule that some researcher

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

>AES-256 can offer the same level of security. This makes AES-192 a valid

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

Regards,

Kenny