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

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

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

> On Wed, Mar 22, 2017 at 2:53 PM, Phillip Hallam-Baker <
> [e-mail]> wrote:
>
>> 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?
>>
>
> xG can be recovered if you know (x+z)G and the "example.com" string,
> which is the problem.
>
> xG cannot be recovered if you know (x*z)G and the "example.com" string,
> which is the desirable unlinkability property.
>
> You could also do:
>>
>> ​xs = ( H(x + 'example.com')) mod q
>>
>
> This requires knowledge of the parent scalar to derive child keys. One of
> the goals of a scheme like this is to allow a holder of a master public key
> to derive child public keys without any knowledge of secret scalars.
>
>
​Ah, yes, you would want MAC ('example.com', k)

However, g​oing back to

xs = x + ( MAC('example.com', k)) mod q

You could play some interesting games with this. You could have quasi
linkability so that the identifiers are unlikable unless you choose to
claim them be revealing the difference between two of the keys.

I have no idea what you would want to use it for but you could do it.