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

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

Hello Taylor,

On Sat, 2017-01-14 at 19:50 +0000, Taylor R Campbell wrote: 
> Date: Sat, 14 Jan 2017 20:08:01 +0100
>    From: Leonard den Ottolander <[e-mail]>
> 
>    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 would be surprised if TLS relied in any way on resistance to
> 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
> 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.

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.

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

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

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.

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