Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bip-schnorr: nonce uses hash instead of PRF #197

Closed
bipreview opened this issue Feb 5, 2020 · 2 comments
Closed

bip-schnorr: nonce uses hash instead of PRF #197

bipreview opened this issue Feb 5, 2020 · 2 comments

Comments

@bipreview
Copy link

For the nonce generation step of the signing algorithm, I see:

Let rand = hashBIPSchnorrDerive(bytes(d) || m).

Wouldn't the proper primitive to use be a PRF such as HMAC-SHA-256?

Also, shortly after in the Synthetic nonces section,

rand = hashBIPSchnorrDerive(bytes(d) || m || get_32_bytes_from_rng())

appears like it should be a PRF / HMAC-SHA-256 invocation with get_32_bytes_from_rng() as the key to the HMAC invocation.

The resource linked from the BIP, fault injection attacks and side-channel attacks, says: "With synthetic nonces, nonce derivation is a PRF keyed by the random input Z."

@real-or-random
Copy link

real-or-random commented Feb 5, 2020

The assumption here is that f(k, x) = SHA256(k || x) is a PRF for fixed-length x. There are many valid other choices, e.g., HMAC-SHA256, but the reason why rely on SHA256 is that it's anyway used in the signature scheme and we have never seen any concerns that the function as defined above is not a good PRF. If those concerns existed, then HMAC-SHA256 would probably be a bad choice too.

You could also rely on a function which is designed primarily as PRF, e.g. AES or ChaCha20 but this simply needs more code on the signer side. Moreover, these functions are permutations, which means we need to make sure that the input has the same length as the output (or play tricks). That's also annoying with the discussion in #195 in mind.

edit: I think your misunderstanding here is that you assume that a hash function cannot be a PRF. And this is true syntactically (hash has one input, PRF has two inputs) but given a "good" hash function such as SHA256, we can also use it as PRF if we add the key to the hashed data.

@bipreview
Copy link
Author

Thanks for the explanation.

Correct, my concern was that the construct wasn't a PRF. My thinking was that while the SHA256(k || x) output might seem suitable for this use, a PRF would have output that is theoretically provably pseudorandom.

Since the assumption is that in practice this construct is actually a PRF under the specified restrictions, then I don't have a further specific concern about it right now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants