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

Taylor R Campbell <> Sat, 14 January 2017 19:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF6F3129D64 for <>; Sat, 14 Jan 2017 11:50:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iyEOabteqDSJ for <>; Sat, 14 Jan 2017 11:50:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E97051293DC for <>; Sat, 14 Jan 2017 11:50:27 -0800 (PST)
Received: by (Postfix, from userid 1014) id 749D960358; Sat, 14 Jan 2017 19:50:22 +0000 (UTC)
From: Taylor R Campbell <>
To: Leonard den Ottolander <>
In-reply-to: <1484420882.13637.56.camel@quad> (
Date: Sat, 14 Jan 2017 19:50:26 +0000
Sender: Taylor R Campbell <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
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: Sat, 14 Jan 2017 19:50:30 -0000

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

   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.