Closed bipreview closed 4 years ago
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.
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.
For the nonce generation step of the signing algorithm, I see:
Wouldn't the proper primitive to use be a PRF such as HMAC-SHA-256?
Also, shortly after in the
Synthetic nonces
section,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."