Re: [Cfrg] Self-correction on mismatched security ... RE: Rerun: Elliptic Curves - preferred curves around 256bit work factor (ends on March 3rd)

Andy Lutomirski <> Thu, 26 February 2015 22:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 62D8E1A1B25 for <>; Thu, 26 Feb 2015 14:02:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ezJ3oRWB1WIM for <>; Thu, 26 Feb 2015 14:02:33 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 64E141A1ABF for <>; Thu, 26 Feb 2015 14:02:33 -0800 (PST)
Received: by labgd6 with SMTP id gd6so13875411lab.8 for <>; Thu, 26 Feb 2015 14:02:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Hh3JvSqW7y12mrKdI8d75GPjWJQ7MgKWqraPEFj69Ek=; b=mk3Fya24Q1ifMpr0RUoM6WhySfeSW3CAjsk2M3ZSANtRvdx4U8MMcVCJIcFZ7qU4vP z1TRaFqWk5XkJK7IIXKqXWtO1Z4IezcG1pROCwJu+HEBSG4g9PSM3CUwSPbLtGQESl2m VH5iMOD2UzbkEIUlbTY0JIXshEyLRdRRpO00Nt8sgIe24JQ8DTiRjbumwr+96Vo1rh3B VJgzYgbsQETb+kdUjX/VQ6huXmt0G1Ou+XI52Af7GqM9nWlJ4GV2WNdt4xu1vno6Q8Y2 k7+H/JdwvTGC7lXSnJTVdSf5NxKRGOaunXw8LjsKwT6LFCKKME7ib4Zjg9N289tTDa68 7/eA==
X-Gm-Message-State: ALoCoQl4f/gtrhCikKxBOMyO+Do5dPD1cBcvJoiRrTonzdrPVH/RjS8UMwoFQzsNUR8n6ZMnH/+G
X-Received: by with SMTP id z4mr9519943lal.111.1424988151649; Thu, 26 Feb 2015 14:02:31 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 26 Feb 2015 14:02:11 -0800 (PST)
In-Reply-To: <>
References: <>
From: Andy Lutomirski <>
Date: Thu, 26 Feb 2015 14:02:11 -0800
Message-ID: <>
To: Dan Brown <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>
Subject: Re: [Cfrg] Self-correction on mismatched security ... RE: Rerun: Elliptic Curves - preferred curves around 256bit work factor (ends on March 3rd)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Feb 2015 22:02:36 -0000

On Thu, Feb 26, 2015 at 1:55 PM, Dan Brown <> wrote:
>> -----Original Message-----
>> From: Dan Brown
>> Though I voted above on 448 and 480 as acceptable, just to be clear, we
>> should not label them as providing "256-bit security" and ___not use___ them with
>> AES-256, until we solidify accounting arguments such compatibility, such as:
> To correct and clarify myself on the ___underscored point above___ (thanks to an off-list reply):
> There's no major problem per se using these smaller curves with AES-256.  (Isn't Suite B even more extreme in that regard?)  It's mainly that one ought not to overstate that the combination as providing 256-bit security.  For example, TLS cipher suite names with AES only mention the AES key size, which may be just fine for the sake of specification, but this number is potentially subject to misunderstanding as describing the overall security level.  So, a mismatch generally risks being confusing or misleading.  If you believe that 256-bit security is excessive, then you may also think that such confusion is all moot, and matching higher security levels is just more excessiveness.  If you believe that 256-bit security adds value, whatever that is, then surely you would not want to mislead anybody about it, at least not in a way that could be checked in a couple minutes.

If, on the other hand, you believe that 256-bit AES is a good idea
because it provides substantially better resistance against batch
attacks, then you would be quite happy with a WF ~ 2^128 curve and

I might go so far as to argue that *no* new protocols should use
symmetric ciphers with keys shorter than 256 bits for encryption.