gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Post-quantum secure hierachical deterministic key derivation


From: Martin Schanzenbach
Subject: Re: Post-quantum secure hierachical deterministic key derivation
Date: Wed, 23 Dec 2020 20:30:58 +0900
User-agent: Evolution 3.38.1 (3.38.1-1.fc33)

On Wed, 2020-12-23 at 12:14 +0100, Jeff Burdges wrote:
> 
> > On 23 Dec 2020, at 11:03, Martin Schanzenbach <
> > mschanzenbach@posteo.de> wrote:
> > From what I understood this is not the problem they are concerned
> > with
> > specifically. They propose that there is initially a master secret
> > "msk" and master public key (mpk).
> > This master secret is used to derive a single "hot" sk (and pk)
> > once.
> > After that, the msk (and mpk) becomes "cold" and cannot be used to
> > futher deterministically derive wallets.
> > (See the third paragraph in 1.2.)
> 
> You can derive an unlimited number of secret keys from some
> randomness using a stream cipher, so no that’s not what’s happens.
> 
> You only need the commutative diagram of compatible public and
> private derivation paths if you give someone else the power to derive
> your new public key for you, and then you later derive its secret
> key.  This means the randomness cannot be trusted, well unless you
> use fancy zk proofs like MuSig-DN does.

But they do. See also 4.3 last paragraph for more details on how a
counter could be used for hot wallets.

BR

> 
> > So in my interpretation, the constraint is that every future
> > derivation
> > of a wallet key pair sk'/pk' is not done using the msk/mpk, but the
> > already derived sks (hence "rerandomization" without the "cold"
> > msk).
> > In GNS, however, we do not have this problem. We could always
> > derive
> > from msk unless we want to support cold storage of the zone keys.
> 
> The point is someone else controls the derivation in GNS too.
> 
> In tor, only the directory authority control this, but mostly they’re
> honest.
> 
> > > I think linkability is a concern for Tor, maybe not GNS not sure.
> > > Also enough blockchain folk believe in unlinkability that being
> > > linkable arguably makes things worse, not sure really though. 
> > > I’d
> > > expect linkability to be harder.
> > 
> > I think it could be a problem if you could determine that a derived
> > public key pk' which you do not know the root master key is
> > linkable to
> > another pk'' from which you do know the root master key.
> > The would compromise zone confidentiality (to some degree). Not
> > sure if
> > it would be a real problem, though as you still would not know HOW
> > it
> > was derived or what the record set contains.
> 
> It’s a problem for Tor.  It’s also problem for the false sense of
> security that crypto currency people attribute to derivation.
> 
> Jeff
> 
> 

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]