add a key expansion function

[marten-seemann]

See libp2p/go-libp2p-quic-transport#122 (comment).

[Kubuxu]

IDK if using raw bytes of arbitrary asymmetric encryption private key is the right thing to do.

[Stebalien]

I'd actually like to add this to the private key interface so keys can choose how to implement this.

[Kubuxu]

Yeah, it makes sense. For example DH keys could implement it via DH with static, well-known key.

[marten-seemann]

I'd actually like to add this to the private key interface so keys can choose how to implement this.

Isn't the whole point of using a HKDF here to guarantee a secure key derivation, which doesn't depend on the source and the structure of the randomness used as an input (as long as this random data has high enough entropy, which is basically the definition of what a private key is)?

[Kubuxu]

Alright, after sleeping on it, it is non-blocker to use raw bytes of private key for HKDF, only issue might be consequences of it, as all implementations would have to implement the same raw encoding of these keys for the key to be portable.

AFAIK key being portable is not a requirement for QUIC but it might be useful for something else.

[Stebalien]

So, what I'd like to do is both:

1. Provide a helper function for deriving a key from bytes.
2. Add a function to the private key interfaces for deriving keys.

Most implementations will just call the helper function. However, implementations may choose to do something different based on the key type. For example, ed25519 keys are already uniformly random, as far as I know, so they can skip the first step.

[Kubuxu]

you shouldn't skip the HKDF even when using ed25519 as it is important step in protecting the key itself.

[Stebalien]

There are two steps: Extract and Expand. See: https://tools.ietf.org/html/rfc5869#section-3.3.

[marten-seemann]

So, what I'd like to do is both:

1. Provide a helper function for deriving a key from bytes.
2. Add a function to the private key interfaces for deriving keys.

We need to think about interoperability here. While it doesn't matter for the stateless reset case that triggered this issue, if we ever want to use this for deriving a symmetric encryption key between two peers (I was considering a design like that for the QUIC protector), we need to specify how keys are derived.

Alright, after sleeping on it, it is non-blocker to use raw bytes of private key for HKDF, only issue might be consequences of it, as all implementations would have to implement the same raw encoding of these keys for the key to be portable.

Can we, instead of using the raw bytes of the private key, use the key to encrypt a constant message (e.g. 32 zero-bytes), and use that as the pseudorandom input for the HKDF?