On Dec 16, 9:35 pm, Atif <[email protected]> wrote: > Hey Alan, wanted to see if you had any luck tracking down the issue. So, you are going to love this (and please correct me if I am wrong)....
Note Well (N.B.): the cited paper clearly states (Section 5), "...therefore, our attack can be easily prevented if the relevant protocol variables are properly checked". GnuPG is apparently using Lim-Lee primes because libraries *don't* validate parameters. I'm not sure if that's the GnuPG library, other libraries, or a combination. Here, the traditional validation would include primality tests and safe-prime checks, and verifying q is of the subgroup's order with a modular exponentiation. The validation is required for a number of real life protocols, and [what appears to] include GnuPG's corner cases of ElGamal shared decryption and ElGamal shared verification. To validate the GnuPG ElGamal key, you need to validate at level one and then obtain the unique factorization of p (from Section 4 of the paper: p = q p_1 p_2 p_3 ... p_n). You then need to ensure each p_i is prime and |p_i| > l. l is approximately the size of q, and q is chosen due to Schnorr's subgroup attacks. To obtain the unique factorization, you can get it from the peer or factor it. The concern here is *not* the "good case," where a honest actor generates a Lim-Lee prime. The concerns are the "bad cases" when a dishonest player generates or influences a purported Lim-Lee prime and you can't easily validate the parameter. GnuPG made catching a dishonest player orders of magnitude more difficult. In the end, its probably easiest to reject GnuPG ElGamal keys and ask for a traditional key that you can validate with customary methods. The folks generating the keys should be happy to oblige since you are performing the validation. Jeff > On Thursday, May 17, 2012 11:25:00 AM UTC-4, Alan Rushforth wrote: > > > Hello, > > > I have generated a key pair using GnuPG and am trying to use Crypto++ to > > decrypt an Elgamal encrypted PGP message with the private key. I have > > extracted the p,g and x values from the private key and can use these to > > encrypt and decrypt arbitrary strings. However when ever I try to decrypt > > my encrypted PGP session key it fails. I get a DL_BadElement element > > exception. My problem is exactly the same as the one mentioned in the > > following post from 2003 but it doesn't look like he ever got an answer. > > >https://groups.google.com/d/topic/cryptopp-users/_NJoj8Dqtws/discussion > > > I am using Crypto++ 5.6.1. I have run crypttest and all the tests pass. I > > have also put the key and the message throughhttp://www.pgpdump.net/ > > (it was only a test key) and have compared all the values to ensure I am > > extracting them correctly. The bit that fails seems to be the jacobi test > > on the first half of my cipher text and the modulus. It complains that it > > is not a quadratic residue. As I understand it this means that it isnt a > > very good key. It seems unlikely (but not impossible) that GnuPG would > > select a poor key but even if this is the case why does it stop me > > decrypting it? > > > I have tried validating the keys and they pass up to level 1 but fail on 2 > > and 3 as it says my q value (p/2) is not prime. Again it would seem odd for > > GnuPG to have selected a bad key. Is there another way that I can verify > > the key? > > > Any help on this would be greatly appreciated as I have been banging my > > head against it for days now. > > > And just to prempt the inevitable; i do have to use Elgamal :) -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com.
