Re: [TLS] A la carte handshake negotiation

Peter Gutmann <> Wed, 22 July 2015 10:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E59CC1AD241 for <>; Wed, 22 Jul 2015 03:27:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 38ARP4kzSTyg for <>; Wed, 22 Jul 2015 03:27:28 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0C25E1AD16B for <>; Wed, 22 Jul 2015 03:27:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1437560848; x=1469096848; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sB3xcGlB3L2ctmun/t5ZrAZDs49BYKodOGixO33YiHA=; b=KEHCGhMLNwhpCrka5FkAbxUe+s8GGAq34D0dVFYDvu+FY02I0PsehVMF jPd256h4TohGXtWhXOxY7RCzkrb524iIAJAzBvi/W3dGkMQoSq3xS2Rt0 6llxQevZJLplePtW0RlIhlfxDQGhmIwXalw+j+W7yf5l7MqLxgtlKbh3x ycfq0HRVVfSMaRkgbQIfpO4wjmH3RxuP4E0MQN4jvLCvA04rQ9zSN4taB Voe0SylQHqVPQ55IkUSlFH4avIFrvnOupEnKi+PCSbJ/2+owxN6t1fo9g TEjEDRocLRX89WORiYxVslFn+FsNhtJPgVZwBThfcT/0uCRjsOYKsb5tt Q==;
X-IronPort-AV: E=Sophos;i="5.15,522,1432555200"; d="scan'208";a="29939116"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 22 Jul 2015 22:27:24 +1200
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Wed, 22 Jul 2015 22:27:23 +1200
From: Peter Gutmann <>
To: Ilari Liusvaara <>, Martin Thomson <>
Thread-Topic: [TLS] A la carte handshake negotiation
Date: Wed, 22 Jul 2015 10:27:23 +0000
Message-ID: <>
References: <> <> <> <> <> <>, <20150722093143.GA7186@LK-Perkele-VII>
In-Reply-To: <20150722093143.GA7186@LK-Perkele-VII>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "<>" <>
Subject: Re: [TLS] A la carte handshake negotiation
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Jul 2015 10:27:34 -0000

Ilari Liusvaara <> writes:

>Furthermore, comparing the strengths of kex, auth, ciphering and PRF seems
>like comparing apples, orangles, pears and kumquants.
>Even if the nominal strengths are the same, the scaling of strengths is going
>to be different (e.g. the quadric vs. linear sub-treshold scaling for ECDH vs.

+1.  It's just more numerology:

  (In case you're wondering why you shouldn't go straight to 2048 bits, this
  is another piece of cryptographic numerology that arises from the confusing
  idea of algorithm pairings, that every conventional encryption algorithm or
  key size has to be somehow matched up to a public-key algorithm key size.
  Since conventional encryption algorithms generally have the property that
  every single bit added to the key doubles the work factor needed to break it
  by brute force while public-key algorithms don't, this means that attempts
  to pair conventional-encryption with public-key sizes leads to insanely
  large public keys as the conventional-encryption key sizes get larger.

  Using any known technology it's unlikely that humans can ever get beyond
  about 2^^100 operations, which means that common key sizes of 112 bits
  (triple DES), 128 bits (AES), 192 bits (AES again), and 256 bits (yet more
  AES, because you can never have too many key sizes) are all equally
  unbreakable, and yet the desire for algorithm pairing means that we're
  supposed to go to public-key sizes of 2048, 3072, 7680, and 15,360 bits
  respectively for all of these equally-unbreakable conventional key sizes
  ["Recommendations for Key Management --- Part 1: General", Elaine Barker,
  William Barker, William Burr, William Polk and Miles Smid, NIST Special
  Publication 800-57, 9 July 2012].  This is a good example of the strange
  places that cryptographic numerology can lead you if you believe in it too

So really the table of key sizes should be:

  Conventional        RSA/DH
  ---------------     ------
  100 bits            1536 bits
  112 (ie. > 100)     1536 bits
  128 (ie. > 100)     1536 bits
  192 (ie. > 100)     1536 bits
  256 (ie. > 100)     1536 bits
  Anything > 100      1536 bits