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

Dan Brown <dbrown@certicom.com> Thu, 26 February 2015 21:55 UTC

Return-Path: <dbrown@certicom.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DAD1A07BE for <cfrg@ietfa.amsl.com>; Thu, 26 Feb 2015 13:55:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 tnjKMyuG98EO for <cfrg@ietfa.amsl.com>; Thu, 26 Feb 2015 13:55:41 -0800 (PST)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 308511A00AE for <cfrg@irtf.org>; Thu, 26 Feb 2015 13:55:40 -0800 (PST)
Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 26 Feb 2015 16:55:36 -0500
Received: from XCT104CNC.rim.net (10.65.161.204) by XCT102CNC.rim.net (10.65.161.202) with Microsoft SMTP Server (TLS) id 14.3.210.2; Thu, 26 Feb 2015 16:55:35 -0500
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT104CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Thu, 26 Feb 2015 16:55:35 -0500
From: Dan Brown <dbrown@certicom.com>
To: Dan Brown <dbrown@certicom.com>, "'alexey.melnikov@isode.com'" <alexey.melnikov@isode.com>, "'cfrg@irtf.org'" <cfrg@irtf.org>
Thread-Topic: Self-correction on mismatched security ... RE: [Cfrg] Rerun: Elliptic Curves - preferred curves around 256bit work factor (ends on March 3rd)
Thread-Index: AdBSDsrc3fjS9aqGQs6c/IYmTfPcMw==
Date: Thu, 26 Feb 2015 21:55:34 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF5D6D005@XMB116CNC.rim.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.252]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/57aShoessBqD7zuxX9tUUfp6ku4>
Subject: [Cfrg] Self-correction on mismatched security ... RE: Rerun: Elliptic Curves - preferred curves around 256bit work factor (ends on March 3rd)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Feb 2015 21:55:42 -0000

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

There's a generic minor problem with mismatched strength primitives: the wasted extra computation (if any) of using the stronger than necessary primitive.  (I naively expect that AES-256 would be 14/12 times slower than AES-192.  I recall that SHA-512 is as fast as SHA-384, but do not recall much about other symmetric-key primitives.)  Just to avoid confusion, we could use (or re-label?) AES-224 with ECC-448 (i.e. if it's too much trouble to explain how ECC:AES is smaller than 2:1.)  Also, maybe Suite B is already a good match, though I haven't crunched the numbers.