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

Leonard den Ottolander <leonard-lists@den.ottolander.nl> Sat, 14 January 2017 19:08 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 AA32C129D06 for <cfrg@ietfa.amsl.com>; Sat, 14 Jan 2017 11:08:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.1
X-Spam-Level:
X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] 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 K70mRAsw5hgB for <cfrg@ietfa.amsl.com>; Sat, 14 Jan 2017 11:08:06 -0800 (PST)
Received: from mail.ottolander.nl (mail.ottolander.nl [176.9.136.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3557A129533 for <cfrg@irtf.org>; Sat, 14 Jan 2017 11:08:05 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.ottolander.nl (Postfix) with ESMTP id 7DA9643 for <cfrg@irtf.org>; Sat, 14 Jan 2017 20:08:04 +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 d07va9HnhjzK for <cfrg@irtf.org>; Sat, 14 Jan 2017 20:08:03 +0100 (CET)
Received: from [192.168.0.60] (leonard-home [87.212.131.169]) by mail.ottolander.nl (Postfix) with ESMTPSA id C2F0442 for <cfrg@irtf.org>; Sat, 14 Jan 2017 20:08:02 +0100 (CET)
From: Leonard den Ottolander <leonard-lists@den.ottolander.nl>
To: cfrg@irtf.org
Content-Type: text/plain; charset="UTF-8"
Date: Sat, 14 Jan 2017 20:08:01 +0100
Message-ID: <1484420882.13637.56.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/o0De4a4CEm4CCSwvKt77PDdzKco>
Subject: [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: Sat, 14 Jan 2017 19:08:08 -0000

L.S.,

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 do understand that the number of slots for ciphers in the above list
is somewhat limited and additions should be considered carefully.

However, seeing that there are over 60 TLS_DH_* ciphers in that list and
well over 60 CAMMELIAs - to be clear, I am not arguing against the
latter algorithm - the argument not to include AES-192 ciphers in that
list seems somewhat arbitrary.

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.

Even though I have an interest in mathematics and number theory I do not
claim to have anything more than a rudimentary understanding of the
mathematics involved so please correct me where my insights are wrong.

On superficial reading of http://eprint.iacr.org/2009/317 I grasp that
the higher resistance of AES-192 vs. AES-256 is caused by the fact that
"the key schedule of AES-192 has better diffusion".

What is causing this better diffusion? Is it the fact that the key size
of AES-192 is not, and the block size is a power of 2? I seem to
remember reading somewhere about DES that the odd key size vs the block
size was considered a strength.

Have the same analyses been done for AES-128? How is AES-128 holding up
against these attacks?

Seeing that we live in "a world of 2^50 keys" and the fact that AES-192
seems to be more robust against related key attacks than AES-256 is I
would like to suggest the inclusion of a few AES-192 ciphers in TLS,
lets say all equivalents of AES-256, possibly reduced by the ciphers
that use hashes weaker than SHA256. Not sure if "DH" and "DH_anon" are
different approaches, but those could be excluded as well, resulting in
something like this list:

TLS_RSA_WITH_AES_192_CBC_SHA256
TLS_DHE_DSS_WITH_AES_192_CBC_SHA256
TLS_DHE_RSA_WITH_AES_192_CBC_SHA256
TLS_RSA_WITH_AES_192_GCM_SHA384
TLS_DHE_RSA_WITH_AES_192_GCM_SHA384
TLS_DHE_DSS_WITH_AES_192_GCM_SHA384
TLS_PSK_WITH_AES_192_GCM_SHA384
TLS_DHE_PSK_WITH_AES_192_GCM_SHA384
TLS_RSA_PSK_WITH_AES_192_GCM_SHA384
TLS_PSK_WITH_AES_192_CBC_SHA384
TLS_DHE_PSK_WITH_AES_192_CBC_SHA384
TLS_RSA_PSK_WITH_AES_192_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_192_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_192_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_192_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_192_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_192_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_192_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_192_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_192_GCM_SHA384
TLS_ECDHE_PSK_WITH_AES_192_CBC_SHA384
TLS_RSA_WITH_AES_192_CCM
TLS_DHE_RSA_WITH_AES_192_CCM
TLS_RSA_WITH_AES_192_CCM_8
TLS_DHE_RSA_WITH_AES_192_CCM_8
TLS_PSK_WITH_AES_192_CCM
TLS_DHE_PSK_WITH_AES_192_CCM
TLS_PSK_WITH_AES_192_CCM_8
TLS_PSK_DHE_WITH_AES_192_CCM_8
TLS_ECDHE_ECDSA_WITH_AES_192_CCM
TLS_ECDHE_ECDSA_WITH_AES_192_CCM_8

Thank you for considering this request.

Regards,
Leonard den Ottolander.

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