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

Leonard den Ottolander <leonard-lists@den.ottolander.nl> Mon, 16 January 2017 19:07 UTC

Return-Path: <leonard-lists@den.ottolander.nl>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E26E129485 for <cfrg@ietfa.amsl.com>; Mon, 16 Jan 2017 11:07:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.377
X-Spam-Level:
X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_SBL=1.623, URIBL_SBL_A=0.1] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8ax6RG-myaG for <cfrg@ietfa.amsl.com>; Mon, 16 Jan 2017 11:07:35 -0800 (PST)
Received: from mail.ottolander.nl (mail.ottolander.nl [176.9.136.165]) by ietfa.amsl.com (Postfix) with ESMTP id 70801129486 for <cfrg@irtf.org>; Mon, 16 Jan 2017 11:07:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.ottolander.nl (Postfix) with ESMTP id 4414143 for <cfrg@irtf.org>; Mon, 16 Jan 2017 20:07:34 +0100 (CET)
X-Virus-Scanned: amavisd-new at ottolander.nl
Received: from mail.ottolander.nl ([127.0.0.1]) by localhost (mail.ottolander.nl [127.0.0.1]) (amavisd-new, port 10026) with LMTP id ucUktmUYvdTK for <cfrg@irtf.org>; Mon, 16 Jan 2017 20:07:32 +0100 (CET)
Received: from [192.168.0.60] (leonard-home [87.212.131.169]) by mail.ottolander.nl (Postfix) with ESMTPSA id 0E51B42 for <cfrg@irtf.org>; Mon, 16 Jan 2017 20:07:32 +0100 (CET)
From: Leonard den Ottolander <leonard-lists@den.ottolander.nl>
To: "cfrg@irtf.org" <cfrg@irtf.org>
In-Reply-To: <CAHOTMVJrHBn4AR7PCJ14xKYCVjdxF7SiswiOABX_g6A5gsQGDg@mail.gmail.com>
References: <20170115205926.853FB60A6D@jupiter.mumble.net> <1484577818.5104.1.camel@quad> <D4A2A7CE.57FDF%john.mattsson@ericsson.com> <CABcZeBPGxT=9iiChy4PxD_zMHWcHU=AhCLoe7wEHHtryw2rfwg@mail.gmail.com> <D4A2B50D.7E040%kenny.paterson@rhul.ac.uk> <CAHOTMVJrHBn4AR7PCJ14xKYCVjdxF7SiswiOABX_g6A5gsQGDg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 16 Jan 2017 20:07:31 +0100
Message-ID: <1484593651.5104.49.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: <https://mailarchive.ietf.org/arch/msg/cfrg/cHKf-b-1AJVQDs9G0wd-Z8ePwcE>
Subject: Re: [Cfrg] A little room for AES-192 in TLS?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Jan 2017 19:07:38 -0000

Hello Tony,

On Mon, 2017-01-16 at 10:09 -0800, Tony Arcieri wrote:
> 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.

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?

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

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

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

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.
> post-quantum ciphersuites.

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.

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