BIP 340 improvements #893
BIP 340 improvements #893
Conversation
…79 shouldn't be used
bip-0340.mediawiki
Outdated
|
|
||
| When an RNG is available at signing time, up to 32 bytes of its output should be included in ''a''. The result is then called a ''synthetic nonce''. Doing so may improve protection against [https://moderncrypto.org/mail-archive/curves/2017/000925.html fault injection attacks and side-channel attacks]. Therefore, '''synthetic nonces are recommended in settings where these attacks are a concern''' - in particular on offline signing devices. Adding more than 32 bytes serves no security purpose. Note that while this means the resulting nonce is not deterministic, its normal security properties do not depend on the quality of the RNG, and in fact using a completely broken RNG is still secure. | ||
| The auxiliary random data should be set to fresh randomness generated at signing time, resulting in what is called a ''synthetic nonce''. If no randomness is available, a simple counter can be used as well, or even nothing at all. Using any non-repeating value increases protection against [https://moderncrypto.org/mail-archive/curves/2017/000925.html fault injection attacks]. Using unpredictable randomness additionally increases protection against other side-channel attacks, and is '''recommended whenever available'''. Note that while this means the resulting nonce is not deterministic, the randomness is only supplemental to security. The normal security properties (excluding side-channel attacks) do not depend on the quality of the signing-time RNG. |
There was a problem hiding this comment.
Perhaps s/should be set to fresh randomness/should be set to 32 bytes of fresh randomness/ to provide a clear recommendation.
|
With this PR the test vectors would be out of sync. Would be better to include the updates from sipa#196 (still WIP at the moment). |
* Recommend a byte length for aux random data * Clarify that with signature verification by default at the end of the signing algorithm, using public keys from untrusted sources is not an issue. * A few editorial nits
|
I'm marking this as WIP until those things are resolved, but leaving this open for exposure. |
| As an alternative to generating keys randomly, it is also possible and safe to repurpose existing key generation algorithms for ECDSA in a compatible way. The secret keys constructed by such an algorithm can be used as ''sk'' directly. The public keys constructed by such an algorithm (assuming they use the 33-byte compressed encoding) need to be converted by dropping the first byte. Specifically, [[bip-0032.mediawiki|BIP32]] and schemes built on top of it remain usable. | ||
|
|
||
| ==== Default Signing ==== | ||
|
|
||
| Input: | ||
| * The secret key ''sk'': a 32-byte array | ||
| * The message ''m'': a 32-byte array | ||
| * Auxiliary random data ''a'': a byte array of length 0 to 32 (inclusive) | ||
|
|
||
| The algorithm ''Sign(sk, m)'' is defined as: |
bip-0340.mediawiki
Outdated
| As an alternative to generating keys randomly, it is also possible and safe to repurpose existing key generation algorithms for ECDSA in a compatible way. The secret keys constructed by such an algorithm can be used as ''sk'' directly. The public keys constructed by such an algorithm (assuming they use the 33-byte compressed encoding) need to be converted by dropping the first byte. Specifically, [[bip-0032.mediawiki|BIP32]] and schemes built on top of it remain usable. | ||
|
|
||
| ==== Default Signing ==== | ||
|
|
||
| Input: | ||
| * The secret key ''sk'': a 32-byte array | ||
| * The message ''m'': a 32-byte array | ||
| * Auxiliary random data ''a'': a byte array of length 0 to 32 (inclusive) |
There was a problem hiding this comment.
How about we fix a to be 32 bytes (or alternatively 0 or 32 bytes). This would make the test vectors much simpler because otherwise we will want to have a test vector with an a that is in between. Making the libsecp compatible with variable len a is unnecessarily complicated as the caller would need to provide a byte array for a that also encodes the length. So either we make a (0 or 32 bytes) or we need to design the test vectors such that only one of them has an in-between a and skip that one it in libsecp.
- use evenness as tiebreaker - using different tags for nonce- and challenge hashing - add pubkey to nonce function.
Fix a few minor issues
Update reference code and test vectors
BIP-0341: Avoid decompressing the output public key in script spends
and make reference code and pseudocode more consistent with each other
This is better for playing around with the code. Now these these exceptions can really be raised when the verification during signing fails.
Add debug print for intermediate values
BIP-0341: Replace notion of is_negated with parity bit
Passes mypy's strict-mode with mypy 0.770.
Typing annotations for BIP-0340
|
@luke-jr This is ready for merge. |
There was a problem hiding this comment.
Didn't we promise on the mailing list to provide better rationale for aux_rand (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-March/017711.html) and expanding on how to make up for losing the ability to spot check (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-March/017667.html)? Should we do this here or in a separate PR @sipa?
|
@jonasnick Sure, but I think those can be done independently. I mostly want to get the even/odd tiebreaker stuff into the published BIP. |
|
This PR has an un-squashed "fixup!" commit, as well as a bunch of merges from PRs against sipa's tree... Seems a bit clunky? Otherwise, ACK cf2937c |
This makes a number of changes to BIP 340:
This is rebased on top of #892 to avoid conflicts.