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
- [Cfrg] A little room for AES-192 in TLS? Leonard den Ottolander
- Re: [Cfrg] A little room for AES-192 in TLS? Taylor R Campbell
- Re: [Cfrg] A little room for AES-192 in TLS? Leonard den Ottolander
- Re: [Cfrg] A little room for AES-192 in TLS? Taylor R Campbell
- Re: [Cfrg] A little room for AES-192 in TLS? Leonard den Ottolander
- Re: [Cfrg] A little room for AES-192 in TLS? John Mattsson
- Re: [Cfrg] A little room for AES-192 in TLS? Eric Rescorla
- Re: [Cfrg] A little room for AES-192 in TLS? Paterson, Kenny
- Re: [Cfrg] A little room for AES-192 in TLS? Stanislav V. Smyshlyaev
- Re: [Cfrg] A little room for AES-192 in TLS? Tony Arcieri
- Re: [Cfrg] A little room for AES-192 in TLS? Leonard den Ottolander
- Re: [Cfrg] A little room for AES-192 in TLS? Ilari Liusvaara
- Re: [Cfrg] A little room for AES-192 in TLS? Salz, Rich
- Re: [Cfrg] A little room for AES-192 in TLS? John Mattsson
- Re: [Cfrg] A little room for AES-192 in TLS? Tony Arcieri
- Re: [Cfrg] A little room for AES-192 in TLS? Leonard den Ottolander
- Re: [Cfrg] A little room for AES-192 in TLS? Salz, Rich
- Re: [Cfrg] A little room for AES-192 in TLS? Yoav Nir
- Re: [Cfrg] A little room for AES-192 in TLS? William Whyte
- Re: [Cfrg] A little room for AES-192 in TLS? Tony Arcieri
- Re: [Cfrg] A little room for AES-192 in TLS? Phillip Hallam-Baker
- Re: [Cfrg] A little room for AES-192 in TLS? Ted Krovetz
- Re: [Cfrg] A little room for AES-192 in TLS? Joan Daemen
- Re: [Cfrg] A little room for AES-192 in TLS? Leonard den Ottolander
- Re: [Cfrg] A little room for AES-192 in TLS? Phillip Hallam-Baker
- Re: [Cfrg] A little room for AES-192 in TLS? Leonard den Ottolander
- Re: [Cfrg] A little room for AES-192 in TLS? Phillip Hallam-Baker
- Re: [Cfrg] A little room for AES-192 in TLS? Paterson, Kenny