diff --git a/bip-0340.mediawiki b/bip-0340.mediawiki
index 917ca24d..883ef3aa 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 ====