[Cfrg] Interest in an "Ed25519-HD" standard?

Tony Arcieri <bascule@gmail.com> Tue, 21 March 2017 19:42 UTC

Return-Path: <bascule@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF92912894A for <cfrg@ietfa.amsl.com>; Tue, 21 Mar 2017 12:42:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 dI9k5_kpya8M for <cfrg@ietfa.amsl.com>; Tue, 21 Mar 2017 12:42:31 -0700 (PDT)
Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC113127286 for <cfrg@irtf.org>; Tue, 21 Mar 2017 12:42:31 -0700 (PDT)
Received: by mail-pg0-x22d.google.com with SMTP id n190so98253512pga.0 for <cfrg@irtf.org>; Tue, 21 Mar 2017 12:42:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=bjn9i+eu0XjhwC3hxmfMNBHF99Ku8Pez/ZrPzAMkHR4=; b=DaG/ntAd48mtYK4s74FO79xlRMjHAu4NhmVaFhSpT8iQ0tNz04x6ll1nG04LIAgfE+ 4l5CPqY/QXYlxCNdQkXCaIXe9Ve1VZfQatLOIDb3Ck/S3fQobLn8j0AVv9D70j0NCql3 y5htit8tZr3x2ul0QQuEP3AoUEa/mHXwn4qgrXHsEdccZyaT2RBBzHA9RUg+6341BoiZ +tLKWXLrnCfPHIVm1WhJ82yCdkiA86TcBxCQke0Fk55p6RHBgBm8KUN8BlmdrZGU4D9L qVKXsx+wdK5e+IxCYOny07MvGadnRBMdJ+ZG6JwPLIv5l4eSMSN+589xpDrkSc2zQZ4G wnGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=bjn9i+eu0XjhwC3hxmfMNBHF99Ku8Pez/ZrPzAMkHR4=; b=EEMaWUpoyDMh+CoCR/IAcqmaK2NogvXF6Emt0Dm7YYhHyNXNVP5c4lCTMqwPGPPMji rBJUxYNlNR2cy92lnqIJwSSAQEjimyrL9Hk4rXvesPZiV1xDYEuA6t5jQvy9/jGLyrS1 ZpDVMJRTm6IOU2L6ORaK09pqKKQIPl5qQUjze6ViCAi7j2xWgE/dZUc2lSljM4vubJjm rRN2sS9t2CEmfyDBinA0J7BOMa+FZEnVv3TV3M0ScugSvyZME97kzGdo7bY+e3GFBX4M QsIjUaEJweMrly5C6rKGSmwyAo9ZE6Rdx4Cc19s+aqFThBRrgScTGLuuBxCwg8h35fAO eF+A==
X-Gm-Message-State: AFeK/H3ELtCYCdU92JSDb96GaSAQLeZfMvWBAVbbIJms5e8Hm0X4WbGdPOv9SJvSn33X+jKbK47nWvyarz/5hg==
X-Received: by 10.84.178.195 with SMTP id z61mr50268999plb.139.1490125351181; Tue, 21 Mar 2017 12:42:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.178.234 with HTTP; Tue, 21 Mar 2017 12:42:10 -0700 (PDT)
From: Tony Arcieri <bascule@gmail.com>
Date: Tue, 21 Mar 2017 12:42:10 -0700
Message-ID: <CAHOTMVKHA-yJR1oCyPtUp4-aJVc3dTdyxQHNo4xqnJt0hU6jVQ@mail.gmail.com>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="94eb2c11a66c3a67a5054b42d86f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/lM1ix9R-0tVzhZorQhQlKvi4wpA>
Subject: [Cfrg] Interest in an "Ed25519-HD" standard?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Mar 2017 19:42:34 -0000

Hierarchical key derivation (also sometimes described as "semiprivate keys"
or "key blinding") is an increasingly popular technique for generating
unlinkable child keys from master public and private keys.

The Tor Project has been exploring such an approach as the basis for their
next-generation hidden services design for several years now[1], during
which time it has received security proofs[2]. Their latest design[3]
allegedly includes feedback from Dan Bernstein.

Application of hierarchical key derivation is perhaps most notable in the
cryptocurrency space, where Bitcoin's BIP32[4] provided a means for
unlinkable single-use signature keys for the secp256k1 elliptic curve.
There are several designs for applying the ideas from BIP32 to Ed25519,
including ones from Evernym[5] and Chain[6] (where I am an employee).

The designs in [3], [5], and [6] are all highly similar and accomplish the
same goals. Personally I would love to see a single standard design for
producing Ed25519 signatures from hierarchically derived keys, notably one
which produces signatures that can be verified by any off-the-shelf RFC
8032-compatible Ed25519 implementation.

There's already been some discussion of this on the moderncrypto.org curves
list:

https://moderncrypto.org/mail-archive/curves/2017/000858.html

I'd be curious to know if anyone else would be interested in collaborating
on a draft for such a standard, which can be a synthesis of the existing
work in this space.

[1]:
https://lists.torproject.org/pipermail/tor-dev/2012-September/004026.html
[2]: https://www-users.cs.umn.edu/~hopper/basic-proof.pdf
[3]:
https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n1979
[4]: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
[5]:
https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/topics-and-advance-readings/HDKeys-Ed25519.pdf
[6]: https://chain.com/docs/protocol/specifications/chainkd

-- 
Tony Arcieri