Re: [Cfrg] On why point and APIs formats matter (Re: Submission of curve25519 to NIST from CFRG -> was RE: On "non-NIST")
Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 12 March 2015 06:17 UTC
Return-Path: <ietf-dane@dukhovni.org>
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 AB1DE1A8A89 for <cfrg@ietfa.amsl.com>; Wed, 11 Mar 2015 23:17:04 -0700 (PDT)
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 NMFpc-cCitXf for <cfrg@ietfa.amsl.com>; Wed, 11 Mar 2015 23:17:03 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 284C51A8A87 for <cfrg@irtf.org>; Wed, 11 Mar 2015 23:17:03 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 21404282FCC; Thu, 12 Mar 2015 06:17:02 +0000 (UTC)
Date: Thu, 12 Mar 2015 06:17:02 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: cfrg@irtf.org
Message-ID: <20150312061701.GA18819@mournblade.imrryr.org>
References: <CACsn0cnGci_fHMkJiHzXmdvnSbvm08AbV+VLdObw-+n7x7sdHw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CACsn0cnGci_fHMkJiHzXmdvnSbvm08AbV+VLdObw-+n7x7sdHw@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/Z0kA-qk7EfHRHi8JsXBkLOV20Lk>
Subject: Re: [Cfrg] On why point and APIs formats matter (Re: Submission of curve25519 to NIST from CFRG -> was RE: On "non-NIST")
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: cfrg@irtf.org
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, 12 Mar 2015 06:17:04 -0000
On Tue, Mar 10, 2015 at 07:20:31PM -0700, Watson Ladd wrote: > > Your concerns about endianness are a trivial in comparison to the > > > > overall industry change to new public key algorithms. Please have some > > focus > > > > and do not add noise to the topic. > > No, they aren't: they are actually much more important than the > question of which curve to use. Though I still retain enough graduate school mathematics to understand the fundamentals of EC crypto, I am not a mathematician or cryptographer. Rather, these days I am an implementor of applications that employ crypto, most notably Postfix where I maintain the SMTP TLS feature-set, and I have plans to contribute DANE support to one or more TLS libraries. So with my implementor hat on (the only hat that fits here), I'd like very much to second Watson's remarks. In the DANE space with 24 different combinations of the TLSA (usage, selector, mtype) parameters not only do essentially all the other implementations I've tried to read offer incomplete support for some corner cases, they are also insecure for a subset of the parameters! On top of that, users get confused and publish incorrect records. Yes, the analogy is rather imperfect, but I believe that the key observations Watson makes are relevant. (In)security will depend a lot more on how easy it is to implement the design incorrectly than on how easy it will be to perform a cryptanalytic attack. The curves considered here are sufficiently strong to make implementation considerations be a key differentiator. So if we can agree that 25519 with a fixed length little-endian octet-string encoding (not variable length big-endian int) is more robust in the hands of mortal implementors, that should be given due consideration. -- Viktor.
- [Cfrg] On why point and APIs formats matter (Re: … Watson Ladd
- Re: [Cfrg] On why point and APIs formats matter (… Nico Williams
- Re: [Cfrg] On why point and APIs formats matter (… Viktor Dukhovni
- Re: [Cfrg] On why point and APIs formats matter (… Dan Brown
- Re: [Cfrg] On why point and APIs formats matter (… James Cloos
- Re: [Cfrg] On why point and APIs formats matter (… Nico Williams
- Re: [Cfrg] On why point and APIs formats matter (… Nico Williams
- Re: [Cfrg] On why point and APIs formats matter (… Salz, Rich
- Re: [Cfrg] On why point and APIs formats matter (… Watson Ladd