aboutsummaryrefslogtreecommitdiff
path: root/src/include/gnunet_crypto_lib.h
diff options
context:
space:
mode:
authorJeff Burdges <burdges@gnunet.org>2016-05-30 15:54:56 +0000
committerJeff Burdges <burdges@gnunet.org>2016-05-30 15:54:56 +0000
commitafb40a6d7a49d2608b709d6e8863675a6a301c99 (patch)
tree26c97c0217311d2313ecac5daa853d428ecf9025 /src/include/gnunet_crypto_lib.h
parent295a7ab56564369098a12e2cc39fac0d5225c465 (diff)
downloadgnunet-afb40a6d7a49d2608b709d6e8863675a6a301c99.tar.gz
gnunet-afb40a6d7a49d2608b709d6e8863675a6a301c99.zip
Use a uniform random number mod an RSA composites for both
the blinding factor and the full domain hash. This resolves an attack against the blinding factor in Taler: There was 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. I do not believe this caused a problem for the full domain hash, but we can fix it easily enough anyways.
Diffstat (limited to 'src/include/gnunet_crypto_lib.h')
-rw-r--r--src/include/gnunet_crypto_lib.h21
1 files changed, 21 insertions, 0 deletions
diff --git a/src/include/gnunet_crypto_lib.h b/src/include/gnunet_crypto_lib.h
index bd95ad3c3..32503eaf8 100644
--- a/src/include/gnunet_crypto_lib.h
+++ b/src/include/gnunet_crypto_lib.h
@@ -27,6 +27,7 @@
27 * @author Gerd Knorr <kraxel@bytesex.org> 27 * @author Gerd Knorr <kraxel@bytesex.org>
28 * @author Ioana Patrascu 28 * @author Ioana Patrascu
29 * @author Tzvetan Horozov 29 * @author Tzvetan Horozov
30 * @author Jeffrey Burdges <burdges@gnunet.org>
30 * 31 *
31 * @defgroup crypto Crypto library: cryptographic operations 32 * @defgroup crypto Crypto library: cryptographic operations
32 * Provides cryptographic primitives. 33 * Provides cryptographic primitives.
@@ -1015,6 +1016,26 @@ GNUNET_CRYPTO_kdf_v (void *result,
1015 1016
1016 1017
1017/** 1018/**
1019 * Deterministically generate a pseudo-random number uniformly from the
1020 * integers modulo a libgcrypt mpi.
1021 *
1022 * @param[out] r MPI value set to the FDH
1023 * @param n MPI to work modulo
1024 * @param xts salt
1025 * @param xts_len length of @a xts
1026 * @param skm source key material
1027 * @param skm_len length of @a skm
1028 * @param ctx context string
1029 */
1030void
1031GNUNET_CRYPTO_kdf_mod_mpi (gcry_mpi_t *r,
1032 gcry_mpi_t n,
1033 const void *xts, size_t xts_len,
1034 const void *skm, size_t skm_len,
1035 const char *ctx);
1036
1037
1038/**
1018 * @ingroup hash 1039 * @ingroup hash
1019 * @brief Derive key 1040 * @brief Derive key
1020 * @param result buffer for the derived key, allocated by caller 1041 * @param result buffer for the derived key, allocated by caller