Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bip-340: reduce size of randomizers to 128 bit and provide argument #222

Open
wants to merge 1 commit into
base: bip-taproot
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion bip-0340.mediawiki
Original file line number Diff line number Diff line change
Expand Up @@ -201,7 +201,7 @@ Input:
* The signatures ''sig<sub>1..u</sub>'': ''u'' 64-byte arrays

The algorithm ''BatchVerify(pk<sub>1..u</sub>, m<sub>1..u</sub>, sig<sub>1..u</sub>)'' is defined as:
* Generate ''u-1'' random integers ''a<sub>2...u</sub>'' in the range ''1...n-1''. They are generated deterministically using a [https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator CSPRNG] seeded by a cryptographic hash of all inputs of the algorithm, i.e. ''seed = seed_hash(pk<sub>1</sub>..pk<sub>u</sub> || m<sub>1</sub>..m<sub>u</sub> || sig<sub>1</sub>..sig<sub>u</sub> )''. A safe choice is to instantiate ''seed_hash'' with SHA256 and use [https://tools.ietf.org/html/rfc8439 ChaCha20] with key ''seed'' as a CSPRNG to generate 256-bit integers, skipping integers not in the range ''1...n-1''.
* Generate ''u-1'' uniformly random integers ''a<sub>2...u</sub>'' in the range ''0..n-1'' or alternatively in the range ''0...2<sup>128</sup>-1''.<ref>Integers are not required to be larger than 128 bits to achieve the desired security level of 128 bits (see [[bip-0340/batch-randomizers.mediawiki|lemma]]). Shorter integers can speed up computations in optimized implementations.</ref> It is recommended to generate them deterministically using a [https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator CSPRNG] seeded by a cryptographic hash of all inputs of the algorithm, i.e. ''seed = seed_hash(pk<sub>1</sub>..pk<sub>u</sub> || m<sub>1</sub>..m<sub>u</sub> || sig<sub>1</sub>..sig<sub>u</sub> )''. A safe choice is to instantiate ''seed_hash'' with SHA256 and use [https://tools.ietf.org/html/rfc8439 ChaCha20] with key ''seed'' as a CSPRNG.
* For ''i = 1 .. u'':
** Let ''P<sub>i</sub> = lift_x(int(pk<sub>i</sub>))''; fail if it fails.
** Let ''r<sub>i</sub> = int(sig<sub>i</sub>[0:32])''; fail if ''r<sub>i</sub> &ge; p''.
Expand Down
16 changes: 16 additions & 0 deletions bip-0340/batch-randomizers.mediawiki
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
= Size of Randomizers in BIP-340 Batch Verification =

'''Lemma:''' For public keys ''pk<sub>1..u</sub>'', messages ''m<sub>1..u</sub>'', signatures ''sig<sub>1..u</sub>'', the probability that ''BatchVerify(pk<sub>1..u</sub>, m<sub>1..u</sub>, sig<sub>1..u</sub>)'' with uniform 128-bit randomizers succeeds and there exists ''i'' in range ''1..u'' such that ''Verify(pk<sub>i</sub>, m<sub>i</sub>, sig<sub>i</sub>)'' fails is not more than 2<sup>-128</sup>.

''Proof:'' For ''i = 1 .. u'', let
* ''P<sub>i</sub> := lift_x(int(pk<sub>i</sub>))'',
* ''r<sub>i</sub> := int(sig[0:32])'',
* ''R<sub>i</sub> := lift_x(r<sub>i</sub>)'',
* ''s<sub>i</sub> := int(sig[32:64])''.

If there exists an ''i'' such that ''lift_x'' for ''P<sub>i</sub>'' or ''R<sub>i</sub>'' fails or ''r<sub>i</sub> &ge; p'' or ''s<sub>i</sub> &ge; n'', then both ''Verify(pk<sub>i</sub>, m<sub>i</sub>, sig<sub>i</sub>)'' and ''BatchVerify(pk<sub>1..u</sub>, m<sub>1..u</sub>, sig<sub>1..u</sub>)'' fail.

Otherwise ''Verify(pk<sub>i</sub>, m<sub>i</sub>, sig<sub>i</sub>)'' fails if and only if ''C<sub>i</sub> := s<sub>i</sub>⋅G - R<sub>i</sub> - e<sub>i</sub>⋅P<sub>i</sub> &ne; 0''.
We let ''c<sub>i</sub>'' be the discrete logarithm of ''C<sub>i</sub>'' with respect to a fixed group generator and define the polynomial ''f<sub>u</sub>(a<sub>2</sub>, ..., a<sub>u</sub>) = c<sub>1</sub> + a<sub>2</sub>c<sub>2</sub> + .... + a<sub>u</sub>c<sub>u</sub>''.
''BatchVerify'' succeeds if and only if ''f<sub>u</sub>'' evaluated on uniform randomizers ''a<sub>2</sub>, ..., a<sub>u</sub>'' is 0.
Assume there exists ''i'' in range ''1..u'' such that ''Verify(pk<sub>i</sub>, m<sub>i</sub>, sig<sub>i</sub>)'' fails. Then ''f<sub>u</sub>'' is not the zero polynomial and by the [https://en.wikipedia.org/wiki/Schwartz%E2%80%93Zippel_lemma Schwartz–Zippel lemma], we have ''f<sub>u</sub>(a<sub>2</sub>, ..., a<sub>u</sub>) &le; 2<sup>-128</sup>''. QED.