Re: [Cfrg] Interest in an "Ed25519-HD" standard?
Phillip Hallam-Baker <phill@hallambaker.com> Wed, 22 March 2017 04:00 UTC
Return-Path: <hallam@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 E374512944B for <cfrg@ietfa.amsl.com>; Tue, 21 Mar 2017 21:00:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.701
X-Spam-Level:
X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 AUmhTiCLsjW1 for <cfrg@ietfa.amsl.com>; Tue, 21 Mar 2017 21:00:44 -0700 (PDT)
Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (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 BA599129677 for <cfrg@irtf.org>; Tue, 21 Mar 2017 21:00:44 -0700 (PDT)
Received: by mail-ot0-x229.google.com with SMTP id a12so93949314ota.0 for <cfrg@irtf.org>; Tue, 21 Mar 2017 21:00:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ixM4I9uDVABxvr/ON042Q9mkoa10Sr6jNvLHTeI71o4=; b=W/Xzn3qtL612GBt7DQFEL9TM8tF2mv8la3TDpk8YzeMlo9mbJaOwi3/QyqdimkV3RF dFr9Z1u8VmmuWsuGzNpGtuEcU9WFxltBRpUjwfTMBXXYE3Gd2kGuCUJje159TlMgeiFN L8937+uEBMiJOiDltzL+8dJG0eORPJE8xcC20r46BVdJBHSpS1kryaKVnfhX7GXWHBBb xqq7PHHvE9rXau7nwwrxKIiwlDM9JE/wOj6rB3Bm94Vv4hmZSIhlcDAuswJfkzJRzM21 hlNkzCtJrwnQD60sJCJbNa66GkWmy05QJ0hrJev0TFtguWdBAetP5Ulj1Hq8G5vg395e hJmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ixM4I9uDVABxvr/ON042Q9mkoa10Sr6jNvLHTeI71o4=; b=irvCy/4q6+ni9STMtNw5S97UtVCfF31+pe7pSI42prhS8ug4Ae5yNoJ3Yc2tnclgCo d1LPByAMopPgwyutiRhHmetNU37BcU69Qmwu9ORT9CNlwRxTQiyHWQAqAmwI8zzzTxz7 DGR15z6zGe1Kr3clWCU576+F/PDXPb1rtwqtiw1KMbU0+5hp8bpdEAqQ19FIXGCfgIG+ O8KPAubsm9LsXPesTcByjy+8iSoUDT/wsXnvax4Uind6i2U4Uaw1dk3yPNtk9pHblHPZ ABxdaLv+2wG4PjRpV75rh1zepHcQOqJXp8OfcbKoOmKilO2Sc+QQ7ywBtd/HQFFd3Jgc IQuA==
X-Gm-Message-State: AFeK/H1h8FcU1D0sdm1aQ5Gruf7YQpq8baKuJve0CFLyiQDoC9heGJd5Z+JVEiQow83OqxoSnAyMHaKns2sgUw==
X-Received: by 10.157.15.38 with SMTP id 35mr21894773ott.49.1490155244104; Tue, 21 Mar 2017 21:00:44 -0700 (PDT)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.157.14.123 with HTTP; Tue, 21 Mar 2017 21:00:43 -0700 (PDT)
In-Reply-To: <CAMm+Lwgm8XzTBarZ1eFePTZGORorBJAeF7brDkhWGQKQVT0LPQ@mail.gmail.com>
References: <CAHOTMVKHA-yJR1oCyPtUp4-aJVc3dTdyxQHNo4xqnJt0hU6jVQ@mail.gmail.com> <CAMm+Lwgm8XzTBarZ1eFePTZGORorBJAeF7brDkhWGQKQVT0LPQ@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Wed, 22 Mar 2017 00:00:43 -0400
X-Google-Sender-Auth: NyMLrLnkOsyTYpYd9doECVRjBBY
Message-ID: <CAMm+LwggT_AVv=KjzM1r=6UnkeK+g8zkticXFBDQ0cUXs_PP0A@mail.gmail.com>
To: Tony Arcieri <bascule@gmail.com>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="94eb2c045e26fc325b054b49cd8f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/on3MXgklr0nw82LvM9P85v5XOEU>
Subject: Re: [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: Wed, 22 Mar 2017 04:00:47 -0000
You can do hierarchical key derivation in Montgomery without the need for an add. Say your master key is x. To generate a key for site 'example.com' we take xs = (x + H('example.com')) mod q Where q is the sub group order. In fact that isn't really using any EC relevant operation at all. Perhaps I am not understanding the full requirements for the scheme. I don't follow the argument about small subgroups in the referenced post. With Curve25519 and Ed25519 we have chosen the curve cofactor and the generator point. So there is only one group that our point can possibly be in regardless of whether our private key is (x mod q) or (x mod q + nq). We are going to arrive at the same set of points regardless. I do very much prefer the Edwards curves though because we can combine two keypairs by simply adding the corresponding public and private keys. That allows us to do the co-generation trick I showed a while back. We can also split the key, give one part to a recryption service and encrypt the other half under the public key of the recipient. This allows us to support group messaging through proxy re-encryption. Some applications of that are encumbered (possibly) under a soon to expire patent. On Tue, Mar 21, 2017 at 8:34 PM, Phillip Hallam-Baker <phill@hallambaker.com > wrote: > I have just implemented Proxy Re-Encryption under Ed-25519 and Ed448. I > think EdCurve Crypto is a good plan. > > Or we could do it on the Montgomery Curves and give the algorithm for > point addition. > > On Tue, Mar 21, 2017 at 3:42 PM, Tony Arcieri <bascule@gmail.com> wrote: > >> 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-Sep >> tember/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 >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >> >> >
- [Cfrg] Interest in an "Ed25519-HD" standard? Tony Arcieri
- Re: [Cfrg] Interest in an "Ed25519-HD" standard? Aaron Zauner
- Re: [Cfrg] Interest in an "Ed25519-HD" standard? Phillip Hallam-Baker
- Re: [Cfrg] Interest in an "Ed25519-HD" standard? Phillip Hallam-Baker
- Re: [Cfrg] Interest in an "Ed25519-HD" standard? Dmitry Khovratovich
- Re: [Cfrg] Interest in an "Ed25519-HD" standard? Phillip Hallam-Baker
- Re: [Cfrg] Interest in an "Ed25519-HD" standard? Tony Arcieri
- Re: [Cfrg] Interest in an "Ed25519-HD" standard? Nadim Kobeissi
- Re: [Cfrg] Interest in an "Ed25519-HD" standard? Tony Arcieri
- Re: [Cfrg] Interest in an "Ed25519-HD" standard? Phillip Hallam-Baker
- Re: [Cfrg] Interest in an "Ed25519-HD" standard? Tony Arcieri
- Re: [Cfrg] Interest in an "Ed25519-HD" standard? Taylor R Campbell
- Re: [Cfrg] Interest in an "Ed25519-HD" standard? Phillip Hallam-Baker
- Re: [Cfrg] Interest in an "Ed25519-HD" standard? Tony Arcieri
- [Cfrg] A note on how to (pre-)compute a ladder Francisco Rodriguez- Henriquez
- Re: [Cfrg] A note on how to (pre-)compute a ladder Peter Dettman
- Re: [Cfrg] A note on how to (pre-)compute a ladder Peter Dettman
- Re: [Cfrg] A note on how to (pre-)compute a ladder Francisco Rodriguez- Henriquez
- Re: [Cfrg] A note on how to (pre-)compute a ladder Francisco Rodriguez- Henriquez
- [Cfrg] How to (pre-)compute a ladder [revised ver… Francisco Rodriguez- Henriquez
- Re: [Cfrg] How to (pre-)compute a ladder [revised… Mike Hamburg
- Re: [Cfrg] How to (pre-)compute a ladder [revised… Peter Dettman
- Re: [Cfrg] How to (pre-)compute a ladder [revised… Antonio Sanso
- Re: [Cfrg] How to (pre-)compute a ladder [full C … Francisco Rodriguez- Henriquez
- Re: [Cfrg] How to (pre-)compute a ladder [revised… Francisco Rodriguez- Henriquez
- Re: [Cfrg] How to (pre-)compute a ladder [revised… Francisco Rodriguez- Henriquez