On Dec 18, 9:35 pm, Jeffrey Walton <[email protected]> wrote: > 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. The wiki has been updated with the information, so future information hunters can find it at http://www.cryptopp.com/wiki/Keys_and_Formats#Validating_Keys.
Jeff > > On Thursday, May 17, 2012 11:25:00 AM UTC-4, Alan Rushforth wrote: > > > > 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.
