Fix a few minor issues #199
Conversation
real-or-random
commented
Feb 24, 2020
real-or-random
commented
- 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
* 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
|
ACK |
bip-0340.mediawiki
Outdated
| @@ -169,7 +169,7 @@ The algorithm ''Sign(sk, m)'' is defined as: | |||
| * If ''Verify(bytes(P), m, sig)'' (see below) returns failure, abort<ref>Verifying the signature before leaving the signer prevents random or attacker provoked computation errors. This prevents publishing invalid signatures which may leak information about the secret key. It is recommended, but can be omitted if the computation cost is prohibitive.</ref>. | |||
| * Return the signature ''sig''. | |||
|
|
|||
| 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. | |||
| The auxiliary random data should be set to fresh randomness generated at signing time, resulting in what is called a ''synthetic nonce''. Using 32 bytes of randomness is optimal but if obtaining randomness is expensive, fewer random bytes can be used. If randomness is not available, a simple counter can be used as well (optimally at least 64 bits wide), or even an empty byte array of length 0. 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.
To make sure the counter does not really overflow. I think a reasonable attacker can make enough signing requests to overflow a 32bit counter. I'm sure 64 bit is overkill but it's easy to reason about. Open to other suggestions of course.
There was a problem hiding this comment.
In that case I think it makes more sense to say that this is supposed to be a non-overflowing counter and not mention a specific bit length, because it's up to the implementation (or alternatively add the rationale that we consider 64 bit wide enough to not overflow).
|
I changed it to only 32 bytes aux data but I'm not really convinced because now we say a lot about padding byte arrays to 32 bytes. This seems like an artificial restriction now. I liked the other variant more, I think. |
real-or-random
force-pushed
the
patch-16
branch
from
a52442d
to
cd19095
Compare
|
Ok, then let's keep it. :) I forced-push to change "constant bytes" to "null bytes" as suggested elsewhere. (And didn't want to write "zero bytes" because I always read this as "0 bytes". :D) |
|
@sipa is this ready to merge? |
