[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 13:00:54 +0900
User-agent: Evolution 3.38.1 (3.38.1-1.fc33)


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.

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).
So maybe there is a simpler scheme in the literature where the
problematic assumptions are not required... need to backtrack their
citations for that.

Regarding the "honestly randomized keys" I am not sure if that would
apply to GNS. I guess if one would naively replace the random "p" with
the record label this assumption may be a problem.


On Tue, 2020-12-22 at 19:15 +0100, Jeff Burdges wrote:
> > On 21 Dec 2020, at 06:49, Martin Schanzenbach
> > <> wrote:
> > this looks promising for PQ-secure GNS key blinding:
> >
> It’s cool that lattice-based schemes can do so many nifty things like
> this, and tor might want the same functionality, but a priori one
> expects such tricks weaken lattice-based schemes.
> There is a claim in the second paragraph in section 5.1 page 24 that
> this weakening does not occur here, assuming the randomization is
> honest.  I have not explored this claim under their honest randomness
> assumption, but it'd clearly requires proof even there.  In fact, I
> doubt this randomization can be considered honest in the blockchain
> or GNS threat models, so I think the authors do not really understand
> for what their protocol expects to be used.
> In tor’s case, one might consider directory authorities honest. 
> There exist few directory authorities though regardless, so if tor
> made directory authorities propose randomness using a VRF implemented
> with a hash-based signature, then you could bound the adversaries
> influence over the randomness by the number of signing directory
> authorities since an honest directory authority signed.  This is
> almost surely useful.
> Assuming section 5.1 fails then one might still use the protocol,
> but..  There is strictly more room for debate over the parameter
> choices here than for a lattice-based signature without this
> functionality.  Indeed, I seriously doubt you'd deploy this using
> exactly the same parameters a lattice-based signature without this
> functionality, given the similar threats, lifetime, etc.  And folks
> do not yet agree about even the regular parameter!
> I also think the protocol requires further exploration of linkability
> between keys, which maybe matters under some blockchain usages of
> HDKD like zcash, definitely matters for Tor, and maybe matters for
> GNS.  It appears the paper does not explore this.
> It’s kinda a problem with our brave new lattice based post-quantium
> future that niche crypto becomes more of a second class citizen than
> with elliptic curves, but if security levels become established then
> at least parameterizing the niche stuff becomes more realistic.
> Jeff

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

reply via email to

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