aboutsummaryrefslogtreecommitdiff
path: root/src/util/crypto_rsa.c
Commit message (Collapse)AuthorAge
* src: for every AGPL3.0 file, add SPDX identifier.ng02019-01-14
|
* benchmark: count rsa_blind properlyFlorian Dold2018-08-19
|
* benchmark collection awk scriptsFlorian Dold2018-08-18
|
* paragraph for gnunet devs that don't know how to use the webpsyc://loupsycedyglgamf.onion/~lynX2018-06-07
|
* glitch in the license text detected by hyazinthe, thank you!psyc://loupsycedyglgamf.onion/~lynX2018-06-07
|
* second batch complete. WE ARE AFFERO AGPL NOW!psyc://loupsycedyglgamf.onion/~lynX2018-06-06
|
* style fixChristian Grothoff2018-05-30
|
* add missing constChristian Grothoff2017-10-31
|
* util: add component name to LOG macros; util/client: log incoming message ↵tg(x)2017-02-24
| | | | type/size/source for gnunet-logread
* Restore Lenstra protection for gcrypt < 1.6.4David Barksdale2016-08-23
|
* -remove dead codeChristian Grothoff2016-08-23
|
* Removed duplicate protection agaisnt LenstraJeff Burdges2016-08-22
| | | | | | | | | | Now libgcrypt 1.6.4, released 8 Sep 2015 , has its own protection against Lenstra's attack, added wtih commit c17f84bd02d7ee93845e92e20f6ddba814961588 dated 31 Aug 2015. Do not run GNUNet with an earlier libgcrypt now.
* Rework the error handling for gcd(r,n) != 1 so the Taler wallet can see errors.Jeff Burdges2016-06-08
|
* Abstract out previous GCD(m,n)=1 commit into a single functionJeff Burdges2016-06-07
| | | | | | This should make it easier to report properly in the wallet.
* Verify that GCD(m,n) != 1 when n is an RSA modulusJeff Burdges2016-06-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Much thanks to CodesInChaos <codesinchaos@gmail.com> from the cryptography@metzdowd.com list for observing this flaw! On Tue, 2016-06-07 at 13:39 +0200, CodesInChaos wrote: > How do you handle the case where GCD(m, n) != 1 where m is the message > (i.e. the full domain hash) and n the modulus? Do you reject that > message and generate a new one? If I understand the attack you have in mind, it goes roughly : First, an evil exchange creates a 2048 bit RSA key pq, but issues n = p q r_1 r_2 ... r_k as say a 4096 bit RSA key where r_i is a smallish but preferably not so obvious primes, like not 2, 3, or 5. Next, our evil exchange detects and records when the various r_i appear during blinding and spending. As m is 4096 bits, then some always do since we took the r_i smallish. Each appearing r_i factor leaks I think several bits about the customer's identity. If enough coins are involved in a transaction, especially say through repeated transactions, then the customer will quickly be deanonymized. I could've fixed this in crypto_kdf.c but I descided it was specific to RSA, so I did it when calling the KDF. It should be abstracted into a common routine probably. Also fixes a pair of memory leaks.
* Testcases for KDF mod nJeff Burdges2016-05-30
| | | | | | Currently just that the result is smaller than n, maybe should do more.
* Use a uniform random number mod an RSA composites for bothJeff Burdges2016-05-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* sketch envisioned APIChristian Grothoff2016-05-26
|
* fixing #4483: optimize blinding key storage/transmissionChristian Grothoff2016-05-24
|
* rename.sh GNUNET_CRYPTO_rsa_BlindingKey to GNUNET_CRYPTO_RsaBlindingKey ↵Christian Grothoff2016-05-19
| | | | following naming conventions
* Fix cut & paste errorJeff Burdges2016-03-21
|
* Copyright yearsJeff Burdges2016-03-21
|
* Authors, (C), and C++ commentsJeff Burdges2016-03-21
|
* Clarify a few paramaters and namesJeff Burdges2016-03-21
|
* Avoid exporting mpi_print helper functionJeff Burdges2016-03-21
| | | | | | | I still need to check on the importance of unsigned variant of this function
* Release outside of helper functionJeff Burdges2016-03-21
|
* fixing symbol naming and coding convention issuesChristian Grothoff2016-03-21
|
* Implement a Full Domain Hash (FDH) for RSA signatures and blind signaturesJeff Burdges2016-03-20
| | | | | | | | | | | | | | | | | This gives a measure of provable security to the Taler exchange/mint against hypothetical one-more forgery attacks. See: https://eprint.iacr.org/2001/002.pdf http://www.di.ens.fr/~pointche/Documents/Papers/2001_fcA.pdf We seed the FDH with the denomination keys as as a homage to RSA-PSS. This may slightly improves the exchanges's resistance to a violation of RSA-KTI and against insiders who can influence the choice of RSA keys but cannot actually exfiltrate them. Adopting FDH fixes a bug when using 512 bit RSA keys as well.
* -fix (C) noticesChristian Grothoff2016-01-19
|
* -add benchmark for RSA cryptoChristian Grothoff2015-09-03
|
* -indentChristian Grothoff2015-08-06
|
* -more correct logicChristian Grothoff2015-08-06
|
* -fix leakChristian Grothoff2015-08-06
|
* DEFAULTSERVICES is dead, remove remainsChristian Grothoff2015-07-08
|
* patch from Nicolas Fournier to add some _dup and _cmp functions for RSA ↵Christian Grothoff2015-06-30
| | | | signatures and private keys
* make libextractor actually optional, both for GNUnet and GNUnet-taler buildsChristian Grothoff2015-05-30
|
* Introduce function to duplicate RSA public keysSree Harsha Totakura2015-05-28
|
* validate the parsed RSA private keySree Harsha Totakura2015-05-27
|
* -adding cmp functions for RSA public keys and sigsChristian Grothoff2015-05-15
|
* -doxygen, build system fixes, minor API extensionChristian Grothoff2015-04-13
|
* add GNUNET_CRYPTO_rsa_public_key_hashChristian Grothoff2015-03-09
|
* -bringing copyright tags up to FSF standardChristian Grothoff2015-02-07
|
* - fix memleakSree Harsha Totakura2015-01-26
|
* - fix docuSree Harsha Totakura2015-01-26
|
* -fix docSree Harsha Totakura2015-01-26
|
* -fix assertion checking the encoded s-expressionsSree Harsha Totakura2015-01-24
|
* adding support for blind signatures (modernized version of Taler logic, with ↵Christian Grothoff2015-01-09
| | | | variable key length)
* -removing last bits of RSA support, as this code is now deadChristian Grothoff2013-07-18
|
* -deadChristian Grothoff2013-03-04
|
* Be able to only-read-not-create RSA keysLRN2013-03-03
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-01 06:43:25 +0000