Re: [TLS] PKIX drafts on EdDSA/Ed25519 and Curve25519/Curve448

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Tue, 30 June 2015 08:20 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689821A1ADF for <tls@ietfa.amsl.com>; Tue, 30 Jun 2015 01:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level:
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 54_cUljvSpop for <tls@ietfa.amsl.com>; Tue, 30 Jun 2015 01:20:25 -0700 (PDT)
Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B1BB1A1A9E for <tls@ietf.org>; Tue, 30 Jun 2015 01:20:24 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 391EA1887A9; Tue, 30 Jun 2015 11:20:22 +0300 (EEST)
Date: Tue, 30 Jun 2015 11:20:22 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Simon Josefsson <simon@josefsson.org>
Message-ID: <20150630082022.GB6141@LK-Perkele-VII>
References: <87lhf29nr4.fsf@latte.josefsson.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <87lhf29nr4.fsf@latte.josefsson.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/3IbD0zb9Ydlxpe_nBSrY3Jr4G8c>
Cc: tls@ietf.org
Subject: Re: [TLS] PKIX drafts on EdDSA/Ed25519 and Curve25519/Curve448
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2015 08:20:26 -0000

On Tue, Jun 30, 2015 at 12:02:39AM +0200, Simon Josefsson wrote:
> 
> A couple of people suggested to define encodings for Curve25519/Curve448
> (the CFRG curves) public keys.  I didn't see that this necessarily had
> to be in the above document, so I put it in a separate document.  I'm
> not entirely sure how useful this is, or if I may have completely
> misunderstood what people had in mind. 

Well, EdDSA-like scheme (obtained by dropping constraints on curve
and hash[1] and generation of a and seed[2])  would be:

(a and seed generated from secret)
r = h(seed || M)
R = rB
A = aB
s = (r + h(encode_p(R) || encode_p(A) || M) * a) mod l
signature = encode_p(R) || encode_s(s)
public key = encode_p(A)

(Multiply equation for s to get verification equation:
sB = R + h(encode_p(R) || encode_p(A) || M) * A )

(One can obtain Ed25519 from this by substituting suitable a / seed
generation, B and functions h, encode_p and encode_a.)


And since encode_p(X) is inside hash, one must pin it down for the
scheme to work (interoperate between signers and verifiers), along
with the hash function h to use.

Edwards curves are always constant or quadric in x for in every
term of curve equation. Which means that x can be compressed to
a single LSB bit (Ed25519 paper is somewhat unclearly worded IMO,
but this is what it does for prime curves[3][4]).

There's also encode_s(x), but it is straightforward (can just use
little-endian base-256 integer encoding.


[1] Enabling it to work on curves other than very few ones, especially
with standard-issue hashes.

[2] Since hash function length is insufficient for the method used in
Ed25519 without using exotic hashes.

[3] There are other possibilities, but LSB bit (even/odd) seems to be
the easiest to extract and to compare.

[4] For Ed448 there is also encoding from Ed448-Goldilocks, which is
56 bytes (448 bits) instead of 57 bytes (449 bits). But it is fair
bit more complicated (slow) than straightforward point compression.


-Ilari