Re: [Cfrg] Interest in an "Ed25519-HD" standard?

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Mar 22, 2017 at 4:47 PM, Tony Arcieri <[e-mail]> wrote:

> On Tue, Mar 21, 2017 at 9:00 PM, Phillip Hallam-Baker <
> [e-mail]> 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' 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.
>>
>
> One of the goals of the scheme is unlinkability: given a set of candidate
> keys, some of which are children of the same parent key, and others
> randomly generated, an attacker should not be able to do better than chance
> in determining which keys in the candidate set have the same parents.
>
> For example, Tor hidden services will be identified by constantly rotating
> "epoch keys". To find the "epoch key" for a given hidden service, a user in
> possession of the parent public key derives a child key offline from the
> parent key. However, it'd be undesirable for someone not in possession of
> the parent key to be able to link the child epoch keys together and
> enumerate hidden services without knowledge of their parent public keys.
>
> In your scheme, given z=H("example.com"), and a parent key xG, the
> derived child key would be (x+z)G. To recover the original parent public
> key, you can simply subtract out zG and recover xG. To prevent this from
> happening we need to use an operation which is not easily reversible, hence
> multiplication
>
>
That is the case if you disclose x.G. But why would you do that?

You could also do:

​xs = ( H(x + 'example.com')) mod q

Which is more robust.