Add my mail about the PRNG attack on blinding
I imagine this will develop further shortly
This commit is contained in:
parent
32bb3b14bf
commit
8dc035b237
53
doc/paper/blinding_prng.txt
Normal file
53
doc/paper/blinding_prng.txt
Normal file
@ -0,0 +1,53 @@
|
|||||||
|
|
||||||
|
We should try to be rigorous about this, which seemingly shows an
|
||||||
|
issue.
|
||||||
|
|
||||||
|
|
||||||
|
There is a call to GNUNET_CRYPTO_kdf in
|
||||||
|
bkey = rsa_blinding_key_derive (len, bks);
|
||||||
|
that gives exactly len bits where
|
||||||
|
len = GNUNET_CRYPTO_rsa_public_key_len (pkey);
|
||||||
|
|
||||||
|
Now r = 2^(len-1)/pkey.n is the probability that a set high bit being
|
||||||
|
okay, meaning bkey < pkey.n. It follows that (1-r)/2 of the time bkey >
|
||||||
|
pkey.n making the effective bkey be
|
||||||
|
bkey mod pkey.n = bkey - pkey.n
|
||||||
|
so the effective bkey has its high bit set with probability r/2.
|
||||||
|
|
||||||
|
We expect r to be close to 1/2 if the exchange is honest, but the
|
||||||
|
exchange can choose r otherwise.
|
||||||
|
|
||||||
|
In blind signing, the exchange sees
|
||||||
|
B = bkey * S mod pkey.n
|
||||||
|
On deposit, the exchange sees S so they can compute bkey' = B/S mod
|
||||||
|
pkey.n for all B they recorded to see if bkey' has it's high bit set.
|
||||||
|
Also, note the exchange can compute 1/S efficiently since they know the
|
||||||
|
factors of pkey.n.
|
||||||
|
|
||||||
|
I suppose that happens with probability r/(1+r) if its the wrong B, not
|
||||||
|
completely sure. If otoh we've the right B, then we've the probability
|
||||||
|
r/2 of a set high bit in the effective bkey.
|
||||||
|
|
||||||
|
Interestingly, r^2-r has a maximum at the default r=1/2 anyways, giving
|
||||||
|
the wrong and right probabilities 1/3 and 1/4, respectively.
|
||||||
|
|
||||||
|
|
||||||
|
I fear this gives the exchange a meaningful fraction of a bit of
|
||||||
|
information per coin involved in the transaction. It sounds damaging if
|
||||||
|
numerous coins were involved. And it could run across transactions in
|
||||||
|
some scenarios.
|
||||||
|
|
||||||
|
|
||||||
|
I suspect we need a more uniform deterministic pseudo-random number
|
||||||
|
generator for blinding factors. Just fyi, our old call to
|
||||||
|
gcry_mpi_randomize had this same problem.
|
||||||
|
|
||||||
|
As I said before, I do not believe this to be a problem for the full
|
||||||
|
domain hash, but maybe my setting that second to high bit makes it worse
|
||||||
|
or something, not sure.
|
||||||
|
|
||||||
|
|
||||||
|
It's late, maybe I've worked out some probabilities wrong, but looks
|
||||||
|
right.
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue
Block a user