summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTim Ruffing <crypto@timruffing.de>2020-02-28 18:25:31 +0100
committerTim Ruffing <crypto@timruffing.de>2020-02-29 11:21:24 +0100
commitcd19095fb039ee74dbb33225af21e83846e5a083 (patch)
treefa619d0e431af3f922d687a4382ff51bdb4faea8
parent4f482a6748a97887d54c9c70682085aad7febefd (diff)
downloadbips-cd19095fb039ee74dbb33225af21e83846e5a083.tar.xz
Switch to only 32 bytes aux
-rw-r--r--bip-0340.mediawiki4
1 files changed, 2 insertions, 2 deletions
diff --git a/bip-0340.mediawiki b/bip-0340.mediawiki
index 917ca24..883ef3a 100644
--- a/bip-0340.mediawiki
+++ b/bip-0340.mediawiki
@@ -151,7 +151,7 @@ As an alternative to generating keys randomly, it is also possible and safe to r
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)
+* Auxiliary random data ''a'': a 32-byte array
The algorithm ''Sign(sk, m)'' is defined as:
* Let ''d' = int(sk)''
@@ -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''. 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.
+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. If obtaining randomness is expensive, 16 random bytes can be padded with 16 null bytes to obtain a 32-byte array. If randomness is not available at all at signing time, a simple counter wide enough to not repeat in practice (e.g., 64 bits or wider) and padded with null bytes to a 32 byte-array can be used, or even the constant array with 32 null bytes. 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.
==== Alternative Signing ====