[Top][All Lists]

[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 19:03:27 +0900
User-agent: Evolution 3.38.1 (3.38.1-1.fc33)

On Wed, 2020-12-23 at 09:25 +0100, Jeff Burdges wrote:
> > On 23 Dec 2020, at 05:00, Martin Schanzenbach <
> >> wrote:
> > thanks for the input!
> > I am pretty much out of my depth but what I stumbeld over is in
> > section
> > 1.2 where the authors say that they specifically solve the problem
> > for
> > hot/cold wallets where the problem is that you need to be able to
> > rerandomize a new sk''/pk'' from a previously generated sk'/pk'
> > which
> > at some point in the past was derived from the now "cold" master
> > sk/pk.
> I read 1.2 as saying they’re doing the usual Schnorr thing, but the
> word rerandomize seemingly explains their confusion.  I’ve no looked
> into this part really.
> > This property is actually (currently) not really important for GNS
> > as
> > we do not need to rerandomize keys and we do not have "cold" keys.
> > (Although this feature would be good to have I guess).
> These soft derivations never address key compromise because sk_rho =
> H(rho) sk, but here one worried that publishing many pk_rho and using
> many sk_rho reveals information about sk somehow.  I’ve largely
> forgotten GNS but I think an adversarial zone would try many of their
> own public keys until they found one that deformed your public key in
> a way they could expect to reveal more.

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.)

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.

> 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.


> Jeff

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

reply via email to

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