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

Leonard den Ottolander <> Sun, 15 January 2017 16:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E4611294F1 for <>; Sun, 15 Jan 2017 08:57:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.2
X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j8HYQ7yZPkhP for <>; Sun, 15 Jan 2017 08:57:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3702F129604 for <>; Sun, 15 Jan 2017 08:57:12 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 633E543 for <>; Sun, 15 Jan 2017 17:57:10 +0100 (CET)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with LMTP id Vh6ilijIh2C5 for <>; Sun, 15 Jan 2017 17:57:08 +0100 (CET)
Received: from [] (leonard-home []) by (Postfix) with ESMTPSA id C7DAE42 for <>; Sun, 15 Jan 2017 17:57:08 +0100 (CET)
From: Leonard den Ottolander <>
In-Reply-To: <>
References: <>
Content-Type: text/plain; charset="UTF-8"
Date: Sun, 15 Jan 2017 17:57:07 +0100
Message-ID: <1484499428.5117.20.camel@quad>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.3 (2.32.3-36.1.lj.el6)
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Cfrg] A little room for AES-192 in TLS?
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 15 Jan 2017 16:57:14 -0000

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 <>
>    Seeing how AES-192 seems to hold up well against related key attacks (at
>    least the (theoretical) one described in
> I am rather surprised no AES-192
>    ciphers have been defined for TLS
>    (
>    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

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

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.


P.S. Please reply to list only.

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