Re: [Cfrg] Questions regarding BIP32-Ed25519 (was: Interest in an "Ed25519-HD" standard?)

Oleg Andreev <oleganza@gmail.com> Wed, 05 April 2017 21:20 UTC

Return-Path: <oleganza@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 7AB25128B88 for <cfrg@ietfa.amsl.com>; Wed, 5 Apr 2017 14:20:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.999 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 V6pjtG0DQhRT for <cfrg@ietfa.amsl.com>; Wed, 5 Apr 2017 14:20:31 -0700 (PDT)
Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 700131294AB for <cfrg@irtf.org>; Wed, 5 Apr 2017 14:20:27 -0700 (PDT)
Received: by mail-pg0-x22f.google.com with SMTP id g2so15731883pge.3 for <cfrg@irtf.org>; Wed, 05 Apr 2017 14:20:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Kqnl+hwOJjrZq9oqiIaV51MbODLIasYwN177795XYP0=; b=DoTVDZga7Aa8Eg9E7QozEMCWm3dqm1nAU4HwPsiV1RLr7ObOh1j1y9DVwmkdimiW98 9DpoeYCbKu9YQfAnvU+qpeAPL6n1W6ai1g4F9hMfJUiE7g7UfOm4UhZBDmQ9ZAsLTQG8 TOD7iAMmZXvBhkP/dZ8Q2d9JrDzGZ6L0mHG0NhZ05nBbAN4R8TDm52SathMMylHUh1rM 9H0Vpc+isK0u2IG5W01h5MyX+Gco6EAivll/BRSVkmtOQj3hw9qPsQyehSk3qgndFVlo aROOIs00hi2eyaQM0Pf+rcyn5JL2OyeYJKne3IbTUZc9scsj1YgU4f7KucTEnl9/r8Wt MaIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Kqnl+hwOJjrZq9oqiIaV51MbODLIasYwN177795XYP0=; b=FNfIbubB4krLS+OAi0c4OQcndQby6LQ5mndtlX2fqNRfDozGRPis8d5mGt5UsHRxZp klir0y4WR472Tw0xwd9ZMXmImxh4JBN2Lti8dbe7rdr3VIou+AhZQMtSqV8sQfA7VE3O QInCTJirFjUT1oix43LNtqazxpygT66JBRAcdMWtNGd5RxB1uVa3+rO0pHPT4YK82T2n cLIJZ6xjx6JhYvfnJ/sYMw3PVHujnXc7HBgut5N9NJA3E5i5/lLXy7A7NBbnqiS32GZl BSZM70vrG1vK7UQ0HitGJPUQeWdKF5TM8Pn+M0dIBMG9fqqOfnx19Wh/eFbQsoffIvXy 3KTg==
X-Gm-Message-State: AFeK/H2yw2VKkTWDeevfdKeEP8TPdzaO19A52TQfNo7lVLoMLz9zXVVnMklRjN1xPlATOw==
X-Received: by 10.84.163.75 with SMTP id n11mr38206858plg.186.1491427226677; Wed, 05 Apr 2017 14:20:26 -0700 (PDT)
Received: from [192.168.1.126] ([52.119.113.96]) by smtp.gmail.com with ESMTPSA id d1sm39194661pfk.20.2017.04.05.14.20.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 14:20:26 -0700 (PDT)
From: Oleg Andreev <oleganza@gmail.com>
Message-Id: <1D27C89D-2196-44F6-B3DD-67C961B35442@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_10420D0E-E717-49E3-B0E4-CE5E7251C242"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 5 Apr 2017 14:20:24 -0700
In-Reply-To: <CALW8-7LZGbw2UcRpFVBnX-C5au81zxb-8+o91ROoXQTtRh62kQ@mail.gmail.com>
Cc: cfrg@irtf.org
To: Dmitry Khovratovich <khovratovich@gmail.com>
References: <83CC086B-5B89-41CA-8A20-D7D688DD00AC@gmail.com> <CALW8-7LZGbw2UcRpFVBnX-C5au81zxb-8+o91ROoXQTtRh62kQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/Dxkvcp3TFURU7GqIY069VZ9MsFg>
Subject: Re: [Cfrg] Questions regarding BIP32-Ed25519 (was: 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, 05 Apr 2017 21:20:35 -0000

A quick follow-up: I have simplified our spec a little to pack additional bits on entropy to the private key part (instead of borrowing one byte from the chain code), and renamed "salt" / "chain code" to a "derivation key" because it enables derivation and proofs of linkage. I've also clarified what EdDSA public and private keys are in the glossary. Curious if that's more easy to follow now.

https://github.com/chain/chain/blob/chainkd-dh/docs/protocol/specifications/chainkd.md

> On 4 Apr 2017, at 02:40, Dmitry Khovratovich <khovratovich@gmail.com> wrote:
> 
> Hi Oleg,
> 
> thank you for the questions!
> 
> On Fri, Mar 31, 2017 at 8:06 PM, Oleg Andreev <oleganza@gmail.com <mailto:oleganza@gmail.com>> wrote:
> Dmitry,
> 
> Thanks for your with Jason paper on adopting BIP32 to Ed25519 and critique of ChainKD, very appreciated. I have a few questions about it:
> 
> 1. Why do you impose requirements on the master secret to yield 3rd high bit to be zero, while you can simply set it to zero along with other 5 bits. In two places you mention that you reject non-compliant master secret, but in Security section (F) you say "we set 6 bits", which is what seems to be the intention all along.
> 
> Our idea was to reject as few master secrets as possible, so we decided to clear only one extra bit, thus rejecting half of master keys. By setting 6 bits I mean that we set three highest and three lowest bits.
>  
> 
> 2. You choose 2^20 as a max depth level therefore leaving 2^230 bits for the derived key. In your paper you round this down to whole number of bytes (28 bytes -> 2^224) while it's actually possible to slightly increase collision-resistance by taking 29 bytes instead and clearing top 2 bits. Have you considered that, and if yes, is there any issues with that?
> 
> Apart from clearing one more bit, the idea to take 28 bytes instead of 29 is to cut a 32-bit word, which could simplify some implementations. I agree it is a minor issue.
>  
> 
> 3. What was the rationale for 2^20 as a depth limit? I myself don't have a good framework to decide which limit is the best, so I'm wondering if you have? :)
> 
> The use cases we have seen did not require hierarchy deeper than a few dozen levels. I think 2^20 is a safe bound as long as every new level has some real-world meaning (extra wallet, extra connection, etc.), and thus it seems unlikely that this set will be ever exhausted by any user.
>  
> 
> 4. You effectively make xprv to be 96-byte string (32 bytes for the scalar, 32 bytes for the "prefix" used in nonce generation and 32 byte chain code), and use two HMAC calls to derive new chain code separately from the privkey. Have you considered expanding the 64-byte privkey (as defined by NaCl library) from the scalar itself? In my recent tweak to ChainKD scheme [1] I'm doing that and to stay fully compatible with EdDSA requirement that prefix originally has 256 bits of entropy, add only one secret byte ("pepper") that eats 8 bits from the chain code (which we call "salt"). This allows us to keep both xprv and xpub 64 bytes long and avoid double-HMAC when deriving public keys - single hash call produces a key component and another salt value.
> 
> We just tried to mimic the original BIP32 key derivation as much as possible. I am not sure I entirely understands the rationale behind your manipulation with bytes of private key after you add up the hash output. Also, could you elaborate on the notions of EdDSA public and private keys, which seem to complement public and private keys you derive in the scheme?
> 
> Best regards,
> Dmitry
> 
>  
> 
> Thank you!
> 
> [1] Updated ChainKD: https://github.com/chain/chain/blob/chainkd-dh/docs/protocol/specifications/chainkd.md <https://github.com/chain/chain/blob/chainkd-dh/docs/protocol/specifications/chainkd.md>
> 
> 
> 
> > Being a co-author of [5], I am ready to contribute to such a document. I
> > will present our own proposal at
> > http://prosecco.gforge.inria.fr/ieee-blockchain2016/ <http://prosecco.gforge.inria.fr/ieee-blockchain2016/> in Paris  just before
> > the CFRG meeting at the same place next day. It would be great if we come
> > up with some proposal to discuss it already there.
> >
> > The most recent version is
> > https://drive.google.com/open?id=0ByMtMw2hul0EMFJuNnZORDR2NDA <https://drive.google.com/open?id=0ByMtMw2hul0EMFJuNnZORDR2NDA> It has some
> > critique of [6], hopefully not too offensive:)
> >
> > Our motivation in [5] was to generate private keys satisfying the
> > Curve25519 requirements too so that the code can be reused, even if in the
> > signature setting some attacks would not apply. But it would be great to
> > have comments from the community as well.
> >
> > Best regards,
> > Dmitry
> >
> > On Wed, Mar 22, 2017 at 5:00 AM, Phillip Hallam-Baker <phill@hallambaker.com <mailto:phill@hallambaker.com>
> > > wrote:
> >
> > > 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 <http://example.com/>' we
> > > take
> > >
> > > xs = (x + H('example.com <http://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 <mailto: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 <mailto: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 <http://moderncrypto.org/>
> > >>> curves list:
> > >>>
> > >>> https://moderncrypto.org/mail-archive/curves/2017/000858.html <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 <https://lists.torproject.org/pipermail/tor-dev/2012-Sep>
> > >>> tember/004026.html
> > >>> [2]: https://www-users.cs.umn.edu/~hopper/basic-proof.pdf <https://www-users.cs.umn.edu/~hopper/basic-proof.pdf>
> > >>> [3]: https://gitweb.torproject.org/torspec.git/tree/proposal <https://gitweb.torproject.org/torspec.git/tree/proposal>
> > >>> s/224-rend-spec-ng.txt#n1979
> > >>> [4]: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki <https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki>
> > >>> [5]: https://github.com/WebOfTrustInfo/rebooting-the-web-of- <https://github.com/WebOfTrustInfo/rebooting-the-web-of->
> > >>> trust-fall2016/blob/master/topics-and-advance-readings/HDKey
> > >>> s-Ed25519.pdf
> > >>> [6]: https://chain.com/docs/protocol/specifications/chainkd <https://chain.com/docs/protocol/specifications/chainkd>
> > >>>
> > >>> --
> > >>> Tony Arcieri
> > >>>
> > >>> _______________________________________________
> > >>> Cfrg mailing list
> > >>> Cfrg@irtf.org <mailto:Cfrg@irtf.org>
> > >>> https://www.irtf.org/mailman/listinfo/cfrg <https://www.irtf.org/mailman/listinfo/cfrg>
> > >>>
> > >>>
> > >>
> > >
> > > _______________________________________________
> > > Cfrg mailing list
> > > Cfrg@irtf.org <mailto:Cfrg@irtf.org>
> > > https://www.irtf.org/mailman/listinfo/cfrg <https://www.irtf.org/mailman/listinfo/cfrg>
> > >
> > >
> >
> >
> > --
> > Best regards,
> > Dmitry Khovratovich
> 
> 
> 
> -- 
> Best regards,
> Dmitry Khovratovich