diff options
author | Jeff Burdges <burdges@gnunet.org> | 2016-05-30 16:08:03 +0000 |
---|---|---|
committer | Jeff Burdges <burdges@gnunet.org> | 2016-05-30 16:08:03 +0000 |
commit | 0c9e498f3d07a285e1a3db51a1c6f1049f022362 (patch) | |
tree | 2fd81392ee91b25b92ee73a1c59e2c597ce640be /src/util/crypto_rsa.c | |
parent | afb40a6d7a49d2608b709d6e8863675a6a301c99 (diff) | |
download | gnunet-0c9e498f3d07a285e1a3db51a1c6f1049f022362.tar.gz gnunet-0c9e498f3d07a285e1a3db51a1c6f1049f022362.zip |
Testcases for KDF mod n
Currently just that the result is smaller than n, maybe should do more.
Diffstat (limited to 'src/util/crypto_rsa.c')
-rw-r--r-- | src/util/crypto_rsa.c | 43 |
1 files changed, 43 insertions, 0 deletions
diff --git a/src/util/crypto_rsa.c b/src/util/crypto_rsa.c index 4415f20f6..ae96a99ad 100644 --- a/src/util/crypto_rsa.c +++ b/src/util/crypto_rsa.c | |||
@@ -422,6 +422,49 @@ rsa_blinding_key_derive (const struct GNUNET_CRYPTO_RsaPublicKey *pkey, | |||
422 | } | 422 | } |
423 | 423 | ||
424 | 424 | ||
425 | /* | ||
426 | We originally added GNUNET_CRYPTO_kdf_mod_mpi for the benifit of the | ||
427 | previous routine. | ||
428 | |||
429 | There was previously a call to GNUNET_CRYPTO_kdf in | ||
430 | bkey = rsa_blinding_key_derive (len, bks); | ||
431 | that gives exactly len bits where | ||
432 | len = GNUNET_CRYPTO_rsa_public_key_len (pkey); | ||
433 | |||
434 | Now r = 2^(len-1)/pkey.n is the probability that a set high bit being | ||
435 | okay, meaning bkey < pkey.n. It follows that (1-r)/2 of the time bkey > | ||
436 | pkey.n making the effective bkey be | ||
437 | bkey mod pkey.n = bkey - pkey.n | ||
438 | so the effective bkey has its high bit set with probability r/2. | ||
439 | |||
440 | We expect r to be close to 1/2 if the exchange is honest, but the | ||
441 | exchange can choose r otherwise. | ||
442 | |||
443 | In blind signing, the exchange sees | ||
444 | B = bkey * S mod pkey.n | ||
445 | On deposit, the exchange sees S so they can compute bkey' = B/S mod | ||
446 | pkey.n for all B they recorded to see if bkey' has it's high bit set. | ||
447 | Also, note the exchange can compute 1/S efficiently since they know the | ||
448 | factors of pkey.n. | ||
449 | |||
450 | I suppose that happens with probability r/(1+r) if its the wrong B, not | ||
451 | completely sure. If otoh we've the right B, then we've the probability | ||
452 | r/2 of a set high bit in the effective bkey. | ||
453 | |||
454 | Interestingly, r^2-r has a maximum at the default r=1/2 anyways, giving | ||
455 | the wrong and right probabilities 1/3 and 1/4, respectively. | ||
456 | |||
457 | I feared this gives the exchange a meaningful fraction of a bit of | ||
458 | information per coin involved in the transaction. It sounds damaging if | ||
459 | numerous coins were involved. And it could run across transactions in | ||
460 | some scenarios. | ||
461 | |||
462 | We fixed this by using a more uniform deterministic pseudo-random number | ||
463 | generator for blinding factors. I do not believe this to be a problem | ||
464 | for the rsa_full_domain_hash routine, but better safe than sorry. | ||
465 | */ | ||
466 | |||
467 | |||
425 | /** | 468 | /** |
426 | * Compare the values of two signatures. | 469 | * Compare the values of two signatures. |
427 | * | 470 | * |