Re: Quantum computing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I'm going to talk about Grover's algorithm and Shor's algorithm, plus a good bit on computational complexity theory. The two algorithms are completely different and tackle completely different problems. When I talk about computational complexity theory I'll tie the two algorithms together to show how and when each one is used. Please bear with me. This is going to be long. > So I take your word for it, that 256 bit keyspace searches are > infeasible, even in the quantum-computer world. I assume that advances > in factorization are comparably insignificant...? As mentioned, Grover's is the best we can do for quantum speedups to brute-forcing. Grover's algorithm is a technique for using quantum mechanics to search through a database of N entries in time proportional to the square root of N, using an amount of storage proportional to the logarithm of N. This is important because brute-forcing a key can be thought of as searching through an unsorted database trying to find the right entry. In math we'd say these two problems are isomorphic to each other. "Isomorphic", for the purposes of this email, just means that we can convert one problem into a different problem with some trivial transformation. As with most things in math the real definition is a little more involved, but this one will work for our purposes. For instance, multiplication and division are isomorphic to each other. To divide by 3, just multiply by 1/3. To multiply by 3, just divide by 1/3. Etcetera. That's isomorphism in a nutshell. Please remember what isomorphism means; you're going to see it again later in this email. Searching through an unsorted database and brute-forcing a key are isomorphic to each other. So we do a trivial transformation on the brute-forcing math problem to convert it into a database search problem, and then we sic Grover's on it. Now, that said, Grover's has limits. Its first constraint is that it doesn't make problems trivial. It just increases our ability to deal with them. Brute-forcing a 128-bit cipher using a traditional computer is a ridiculous proposition, but using Grover's, it becomes as hard as brute-forcing a 64-bit cipher... hard, but possible. So the best way to defend against exhaustive key search in a quantum world is to either (a) trust that quantum computing is going to remain "in just a couple of years" for the next few decades (which may very well be true), or (b) multiply your key sizes by a factor of 2. The principal reason why AES supports a 256-bit key is because of the possibility of quantum computing and Grover's algorithm. Brute- forcing a 256-bit cipher with Grover's is as hard as brute-forcing a 128-bit cipher with a conventional computer... absolutely ridiculous. :) > Then... It would seem that quantum computers poses no threat to > traditional cryptography -- helped by increases in key sizes...? Quantum computing poses no threat to symmetric cryptography. Asymmetric cryptography, however, gets a little funky. Shor's algorithm uses quantum mechanics to solve the integer factorization problem (and, I believe, the discrete logarithm problem) in extraordinary short time. The downside of Shor's is it requires an insane amount of memory--you need two qubits for each and every bit of the number you're trying to factor. So if you're trying to factor a 2048-bit RSA key, you need over four _thousand_ qubits. Our current largest quantum computer is about fifteen qubits. When this monstrously huge quantum computer was demonstrated by IBM, it created a huge hue and cry in the press. Most cryptographers dismissed this as much ado over nothing. Schneier is apocryphally quoted as saying "yeah, any RSA modulus with fewer than eight bits is now truly fucked." But wait, the good news doesn't stop there. Not only is quantum computing a long way off from being able to tackle RSA and/or El Gamal, but Shor's algorithm is _only_ applicable against asymmetric systems built on the integer factorization problem and/or the discrete logarithm problem. For instance, Lamport signatures are a perfectly valid asymmetric signature scheme that are secure even against quantum computing. If and when quantum computing develops to the point where a research lab gets a couple of hundred qubits together, the OpenPGP working group will almost certainly add asymmetric algorithms that are highly resistant to quantum computing. Now for the real head-bending things. Why is it there's such an efficient way to solve the integer factorization problem and the discrete logarithm problem, but such an inefficient way to brute- force a key? Computational theory is the branch of mathematics that's concerned with the fundamental limits of what computers can do. In computational theory, we have several different classifications of proble
Re: GPG signature verification problem?
Blumenthal, Uri wrote: > Interestingly, with GPGol both signatures verified correctly! > > While attempts to use GPG4Win directly (open the email piece and > run GPG4Win on the Current Window) fail with "BAD signature". > > And GPG4Win crashes at the attempt to retrieve a key from the > remote keyserver (from behind HTTP proxy). You're getting Bad signature because gpg can't find the key. And it can't find it because the keyserver helper program is being blocked at your proxy server. In addition to auto-key-retrieve, try specifying http-proxy[=value] as part of the keyserver-options line in gpg.conf. From the gpg man page: http-proxy[=value] For HTTP-like keyserver schemes that (such as HKP and HTTP itself), try to access the keyserver over a proxy. If a value is specified, use this as the HTTP proxy. If no value is specified, the value of the environment variable "http_proxy", if any, will be used. If that doesn't work, you may either a) ask the Net-gods to open the keyserver port, 11371. Or, b) try to locate a keyserver operation on port 80. -- John P. Clizbe Inet: John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. PGP/GPG KeyID: 0x608D2A10/0x18BB373A "what's the key to success?"/ "two words: good decisions." "what's the key to good decisions?" / "one word: experience." "how do i get experience?" / "two words: bad decisions." "Just how do the residents of Haiku, Hawai'i hold conversations?" signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG signature verification problem?
Blumenthal, Uri wrote the following on 4/18/07 8:14 PM: >> I have verified the e-mail (sent by Robert), twice: in the >> original message from Robert, and in Robert's quoted message >> in Uri's e-mail. Good signature. > > That's a convincing proof. > >>> The base 64 encoding of the signature is broken. >> Uri: do you get blank spaces in Robert's signature? > > Not that I can see... Every line except for the > very last one is full, and seems to have no weird > characters (nor blanks) in it... The signature text is displayed in lines of 64 ASCII characters. Blank spaces are not ASCII characters, they would have broken the base 64 of the signature. The last line of a signature is composed of five ASCII characters. The line before that last one can have less than 64 ASCII characters. > On the other hand > in your signature encoding, before the last short > line the supposedly-long line appears truncated. Could you verify my signature? > > Here's Robert's sig again: > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.7 (Darwin) > > iQEcBAEBCgAGBQJGJiWiAAoJELcA9IL+r4EJCTcH/RUOxI6RNuuu2WaCpAeJLfHs > 0u+KzJ6MALtonHQOkAbhDTw8zTC+OTHEuN/t2+dwli6E8r7F61RIMpLyPiZpfS0y > rQjHMqJPMdr7Xerhn1haGdov2MzbvtloqHBEP9T65fstTEYBXoYMDSNhYVRV1Fpz > g+is39fVr6D3LZ5W50VQhtTwmcpGM7ZKl4XSgqtv2UwwPM7dYjMQ+Qgz+5MnPLe3 > wZlD06/bvrbY5InFRQFMaFhNtVAC6v42G6W8AOv8WD0kXJCopUGOwYelQ40qhdug > DvXWxpApv7jgmStms63AlG3TjQemwF3rkreFsk9IClAZ5T3EpTafqVd3HC4oYBc= > =OqFT > -END PGP SIGNATURE- Seems fine. > > > > Here's your sig: > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.3 (Darwin) > Comment: GnuPG for Privacy > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQEVAwUBRiZKPc3GMi2FW4PvAQheawf/SDxB8cfw8chNrPDWXyY6Hat7NZtcitzR > /fjqWbEXQ5tM7fEmGNtbEWVLwGwBLrO1Cnf12YVNI2tV5HeeE7e9XQcdq826A4/C > W2hSH1jhevAD+A9EVfOneAMKVOZwCOYTGVWVpBqUyHp9E1Of9QAS+HwCOibIdIKK > QzoemFH4PR0pBEoycRJsIpfN8Wbpf2mOYiTi9XLCiRadcZeAbFWqVMOYFBQHZ8cY > NATwN4NHPgFE6wMVodJuBYcMupn1T5AatvlLLgB1YwJLjyKhT7ASwzp4Jlg40ho5 > EMqCQHEEcEn7bUnz1+0tUEWR60CaPd1ZDB3gocuQd6tIvwReH5kctA== > =8BZI > -END PGP SIGNATURE- Could you verify my signature? Charly ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: GPG signature verification problem?
Interestingly, with GPGol both signatures verified correctly! While attempts to use GPG4Win directly (open the email piece and run GPG4Win on the Current Window) fail with "BAD signature". And GPG4Win crashes at the attempt to retrieve a key from the remote keyserver (from behind HTTP proxy). Thank you! -- Regards, Uri Blumenthal -Original Message- From: Charly Avital [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 18, 2007 4:56 PM To: gnupg-users@gnupg.org Subject: Re: GPG signature verification problem? Blumenthal, Uri wrote the following on 4/18/07 8:14 PM: >> I have verified the e-mail (sent by Robert), twice: in the >> original message from Robert, and in Robert's quoted message >> in Uri's e-mail. Good signature. > > That's a convincing proof. > >>> The base 64 encoding of the signature is broken. >> Uri: do you get blank spaces in Robert's signature? > > Not that I can see... Every line except for the > very last one is full, and seems to have no weird > characters (nor blanks) in it... The signature text is displayed in lines of 64 ASCII characters. Blank spaces are not ASCII characters, they would have broken the base 64 of the signature. The last line of a signature is composed of five ASCII characters. The line before that last one can have less than 64 ASCII characters. > On the other hand > in your signature encoding, before the last short > line the supposedly-long line appears truncated. Could you verify my signature? > > Here's Robert's sig again: > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.7 (Darwin) > > iQEcBAEBCgAGBQJGJiWiAAoJELcA9IL+r4EJCTcH/RUOxI6RNuuu2WaCpAeJLfHs > 0u+KzJ6MALtonHQOkAbhDTw8zTC+OTHEuN/t2+dwli6E8r7F61RIMpLyPiZpfS0y > rQjHMqJPMdr7Xerhn1haGdov2MzbvtloqHBEP9T65fstTEYBXoYMDSNhYVRV1Fpz > g+is39fVr6D3LZ5W50VQhtTwmcpGM7ZKl4XSgqtv2UwwPM7dYjMQ+Qgz+5MnPLe3 > wZlD06/bvrbY5InFRQFMaFhNtVAC6v42G6W8AOv8WD0kXJCopUGOwYelQ40qhdug > DvXWxpApv7jgmStms63AlG3TjQemwF3rkreFsk9IClAZ5T3EpTafqVd3HC4oYBc= > =OqFT > -END PGP SIGNATURE- Seems fine. > > > > Here's your sig: > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.3 (Darwin) > Comment: GnuPG for Privacy > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQEVAwUBRiZKPc3GMi2FW4PvAQheawf/SDxB8cfw8chNrPDWXyY6Hat7NZtcitzR > /fjqWbEXQ5tM7fEmGNtbEWVLwGwBLrO1Cnf12YVNI2tV5HeeE7e9XQcdq826A4/C > W2hSH1jhevAD+A9EVfOneAMKVOZwCOYTGVWVpBqUyHp9E1Of9QAS+HwCOibIdIKK > QzoemFH4PR0pBEoycRJsIpfN8Wbpf2mOYiTi9XLCiRadcZeAbFWqVMOYFBQHZ8cY > NATwN4NHPgFE6wMVodJuBYcMupn1T5AatvlLLgB1YwJLjyKhT7ASwzp4Jlg40ho5 > EMqCQHEEcEn7bUnz1+0tUEWR60CaPd1ZDB3gocuQd6tIvwReH5kctA== > =8BZI > -END PGP SIGNATURE- Could you verify my signature? Charly *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG signature verification problem?
Blumenthal, Uri wrote the following on 4/18/07 11:59 PM: > Interestingly, with GPGol both signatures verified correctly! > > While attempts to use GPG4Win directly (open the email piece and > run GPG4Win on the Current Window) fail with "BAD signature". > > And GPG4Win crashes at the attempt to retrieve a key from the > remote keyserver (from behind HTTP proxy). > > Thank you! > -- > Regards, > Uri Blumenthal [...] I am not at all familiar with GPGol or GPG4Win. Charly ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG signature verification problem?
Blumenthal, Uri wrote the following on 4/18/07 8:14 PM: >> I have verified the e-mail (sent by Robert), twice: in the >> original message from Robert, and in Robert's quoted message >> in Uri's e-mail. Good signature. > > That's a convincing proof. > >>> The base 64 encoding of the signature is broken. >> Uri: do you get blank spaces in Robert's signature? > > Not that I can see... Every line except for the > very last one is full, and seems to have no weird > characters (nor blanks) in it... The signature text is displayed in lines of 64 ASCII characters. Blank spaces are not ASCII characters, they would have broken the base 64 of the signature. The last line of a signature is composed of five ASCII characters. The line before that last one can have less than 64 ASCII characters. > On the other hand > in your signature encoding, before the last short > line the supposedly-long line appears truncated. Could you verify my signature? > > Here's Robert's sig again: > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.7 (Darwin) > > iQEcBAEBCgAGBQJGJiWiAAoJELcA9IL+r4EJCTcH/RUOxI6RNuuu2WaCpAeJLfHs > 0u+KzJ6MALtonHQOkAbhDTw8zTC+OTHEuN/t2+dwli6E8r7F61RIMpLyPiZpfS0y > rQjHMqJPMdr7Xerhn1haGdov2MzbvtloqHBEP9T65fstTEYBXoYMDSNhYVRV1Fpz > g+is39fVr6D3LZ5W50VQhtTwmcpGM7ZKl4XSgqtv2UwwPM7dYjMQ+Qgz+5MnPLe3 > wZlD06/bvrbY5InFRQFMaFhNtVAC6v42G6W8AOv8WD0kXJCopUGOwYelQ40qhdug > DvXWxpApv7jgmStms63AlG3TjQemwF3rkreFsk9IClAZ5T3EpTafqVd3HC4oYBc= > =OqFT > -END PGP SIGNATURE- Seems fine. > > > > Here's your sig: > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.3 (Darwin) > Comment: GnuPG for Privacy > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQEVAwUBRiZKPc3GMi2FW4PvAQheawf/SDxB8cfw8chNrPDWXyY6Hat7NZtcitzR > /fjqWbEXQ5tM7fEmGNtbEWVLwGwBLrO1Cnf12YVNI2tV5HeeE7e9XQcdq826A4/C > W2hSH1jhevAD+A9EVfOneAMKVOZwCOYTGVWVpBqUyHp9E1Of9QAS+HwCOibIdIKK > QzoemFH4PR0pBEoycRJsIpfN8Wbpf2mOYiTi9XLCiRadcZeAbFWqVMOYFBQHZ8cY > NATwN4NHPgFE6wMVodJuBYcMupn1T5AatvlLLgB1YwJLjyKhT7ASwzp4Jlg40ho5 > EMqCQHEEcEn7bUnz1+0tUEWR60CaPd1ZDB3gocuQd6tIvwReH5kctA== > =8BZI > -END PGP SIGNATURE- Could you verify my signature? Charly ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GnuPG return codes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, gpg v1.4.5 Where can I find a list of the program return codes? The man page describes 0 (success), 1 (bad signature), and "other error codes for fatal errors." What are the "other" return codes? - -- jimoe (at) sohnen-moe (dot) com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (OS/2) iD8DBQFGJl28zTcr8Prq0ZMRAhngAKCMpzCCtDyQtWK4jT22eZmQVGr+twCggZWP EgVyqOiosn6HP3mLM+HW+3s= =JjOk -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keyserver-options auto-key-retrieve
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 16 Apr 2007 18:56:32 +0200GMT (16-4-2007, 18:56 +0200, where I live), Henk M. de Bruijn wrote: > keyserver-options auto-key-retrieve > I have this in my gpg.conf and it worked like a charm but it suddenly > stops??? I only emptied my windows/temp and it is working again :-) - -- Henk M. de Bruijn __ The Bat! Natural E-Mail System version 3.98.14 Pro on Windows XP SP2 Request-PGP: http://www.biglumber.com/x/web?qs=0x6C9F6CE78C32408B Gossamer Spider Web of Trust http://www.gswot.org A progressive and innovative Web of Trust -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8-svn4485HMdB (Cygwin/MingW32) iQEVAwUBRiZeOhHuy+60ZN0PAQhfgQgAlszspcfaboPcxHlI6WylRH+GOfIPKrkj kwEtDxuq14E2YEHnzPGUs5hRRgwNmlIUk6qBgkrcoasZWpiTDEzBlZfD1P1Qc39n njEjqadyST6HbwqH/OyPIysZTHlqHwr0StTxpwE+rLe75/aZCswmrPDmFu+r7cvx N50/tJOvD90puE7Jx53W8etdp52GEnyACRd63K6mcSUNjfQ4PdzzP9E0MPaiz/L4 u7qu1ns3E35RBcJRip+aRAVV6IWO6nEbuc7qBbZJvi5ljcBB9H5RyMGf6OWuGTvw TsSLqPhXPzuVlCbM8SFY90KNd5VFkPen2+HewkDWwUf5sYGvGA+qPA== =c/g8 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: GPG signature verification problem?
> I have verified the e-mail (sent by Robert), twice: in the > original message from Robert, and in Robert's quoted message > in Uri's e-mail. Good signature. That's a convincing proof. >> The base 64 encoding of the signature is broken. > Uri: do you get blank spaces in Robert's signature? Not that I can see... Every line except for the very last one is full, and seems to have no weird characters (nor blanks) in it... On the other hand in your signature encoding, before the last short line the supposedly-long line appears truncated. Here's Robert's sig again: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEcBAEBCgAGBQJGJiWiAAoJELcA9IL+r4EJCTcH/RUOxI6RNuuu2WaCpAeJLfHs 0u+KzJ6MALtonHQOkAbhDTw8zTC+OTHEuN/t2+dwli6E8r7F61RIMpLyPiZpfS0y rQjHMqJPMdr7Xerhn1haGdov2MzbvtloqHBEP9T65fstTEYBXoYMDSNhYVRV1Fpz g+is39fVr6D3LZ5W50VQhtTwmcpGM7ZKl4XSgqtv2UwwPM7dYjMQ+Qgz+5MnPLe3 wZlD06/bvrbY5InFRQFMaFhNtVAC6v42G6W8AOv8WD0kXJCopUGOwYelQ40qhdug DvXWxpApv7jgmStms63AlG3TjQemwF3rkreFsk9IClAZ5T3EpTafqVd3HC4oYBc= =OqFT -END PGP SIGNATURE- Here's your sig: -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (Darwin) Comment: GnuPG for Privacy Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRiZKPc3GMi2FW4PvAQheawf/SDxB8cfw8chNrPDWXyY6Hat7NZtcitzR /fjqWbEXQ5tM7fEmGNtbEWVLwGwBLrO1Cnf12YVNI2tV5HeeE7e9XQcdq826A4/C W2hSH1jhevAD+A9EVfOneAMKVOZwCOYTGVWVpBqUyHp9E1Of9QAS+HwCOibIdIKK QzoemFH4PR0pBEoycRJsIpfN8Wbpf2mOYiTi9XLCiRadcZeAbFWqVMOYFBQHZ8cY NATwN4NHPgFE6wMVodJuBYcMupn1T5AatvlLLgB1YwJLjyKhT7ASwzp4Jlg40ho5 EMqCQHEEcEn7bUnz1+0tUEWR60CaPd1ZDB3gocuQd6tIvwReH5kctA== =8BZI -END PGP SIGNATURE- *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG signature verification problem?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Werner Koch wrote the following on 4/18/07 6:50 PM: > On Wed, 18 Apr 2007 17:20, [EMAIL PROTECTED] said: > >> Verification fails, with the following error message. I'm using >> GPG-v.1.4.7, and Thunderbird/Enigmail. > > That seems to be TB problem. I have no problems to verify the mail. Not a TB problem here (TB 2.0.0.0, Enigmail 0.95.0, gpg 2.0.3 Macintosh): I have verified the e-mail (sent by Robert), twice: in the original message from Robert, and in Robert's quoted message in Uri's e-mail. Good signature. >> --charset utf8 --batch --no-tty --status-fd 2 -d,gpg: invalid radix64 >> character 3A skipped,gpg: invalid radix64 character 2E skipped,gpg: >> invalid radix64 character 2E skipped,gpg: invalid radix64 character 28 > > The base 64 encoding of the signature is broken. Uri: do you get blank spaces in Robert's signature? Charly -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (Darwin) Comment: GnuPG for Privacy Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRiZKPc3GMi2FW4PvAQheawf/SDxB8cfw8chNrPDWXyY6Hat7NZtcitzR /fjqWbEXQ5tM7fEmGNtbEWVLwGwBLrO1Cnf12YVNI2tV5HeeE7e9XQcdq826A4/C W2hSH1jhevAD+A9EVfOneAMKVOZwCOYTGVWVpBqUyHp9E1Of9QAS+HwCOibIdIKK QzoemFH4PR0pBEoycRJsIpfN8Wbpf2mOYiTi9XLCiRadcZeAbFWqVMOYFBQHZ8cY NATwN4NHPgFE6wMVodJuBYcMupn1T5AatvlLLgB1YwJLjyKhT7ASwzp4Jlg40ho5 EMqCQHEEcEn7bUnz1+0tUEWR60CaPd1ZDB3gocuQd6tIvwReH5kctA== =8BZI -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
gpgme_set_passphrase_cb() not working
Hi, I've written a small keyring utility(*) to store passwords and such. It is using gpgme to interface with gnupg and works wonderfully on Gentoo and Fedora. However, on OpenSUSE 10.2 it doesn't. The problem is that gpgme_set_passphrase_cb() doesn't have any effect on that platform. I'm seeing pinentry-gtk-2 prompting me for a passphrase no matter what I do. This naturally leads to my keyring not working as the gpgme framework can't get the correct passphrase. Is there anything I can do to force gpgme to use the callback that I provides in gpgme_set_passphrase_cb() or is this something that has been hard coded into gnupg on OpenSUSE? Thanks a lot in advance, jules (*) Full source is here: http://www.omesc.com/content/downloads/dist/testing/brutus-snapshot.tar.bz2 Look in for the keyring source. A small test program is in <../keyring-test/>. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG signature verification problem?
On Wed, 18 Apr 2007 17:20, [EMAIL PROTECTED] said: > Verification fails, with the following error message. I'm using > GPG-v.1.4.7, and Thunderbird/Enigmail. That seems to be TB problem. I have no problems to verify the mail. > --charset utf8 --batch --no-tty --status-fd 2 -d,gpg: invalid radix64 > character 3A skipped,gpg: invalid radix64 character 2E skipped,gpg: > invalid radix64 character 2E skipped,gpg: invalid radix64 character 28 The base 64 encoding of the signature is broken. Salam-Shalom, Werner ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm --import of CA certificate: Bad signature?
Werner Koch <[EMAIL PROTECTED]> writes: > On Wed, 18 Apr 2007 14:11, [EMAIL PROTECTED] said: > >> It is possible to avoid a DER/BER decoder if you generate two >> structures, one with NULL parameters and one with absent parameters, >> and compare both against what's in the decrypted signatures. > > There is a plan tomove pkcs#1 decoding into libgcrypt. This would allow > us to do a second compare without too much changes. I'll put it onto my > todo list but don't expect it to happen anytime soon. Doing PKCS#1 in libgcrypt would be useful for GnuTLS too. I'd like to remove that code in the long run... OTOH, it seems likely that GnuTLS will use some assuan-like protocol and an agent to do private key signing operations, so maybe this concern will be moot. >> GnuTLS accepts both variants, so I made the change. I'll release an >> updated stable version to help get it out as soon as possible. > > Would it be sufficient to do that just for SHA-1? In that case a hack > in cipher/rsa.c would do the trick without too much fear of regression. I don't know. If you do it for SHA-1, that will cover many practical situations and that may be enough. /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Lost passphrase
On Tue, Apr 17, 2007 at 11:59:01PM -0500, Robert J. Hansen wrote: > > I have read what everybody has said on the subject and one > > thing needs to be said again. THE DEFAULT EXPIRE FOR A NEW > > KEY NEEDS TO BE FOR TWO YEARS FROM DATE OF KEY CREATION! > > That's making some really big assumptions about the security policy > of the person making the key. > > There are also a lot of perfectly good alternatives which should > perhaps be excluded first. A good point. But it applies equally to any other lifetime, including the current default. What this suggests to me is that the end user drops out of the equation, because from the POV of the abstract "typical user" no value that the developers choose is any more supportable than any other. This frees the developers to ask another question: "what value would be good for the product's reputation?" A moderate one (1-2 years) seems like a reasonable answer, since it provides some protection to the user who has no policy or omits to apply it, but isn't tremendously burdensome. Still, some thought and discussion would be good. Is there any science to support certain ranges of values in certain applications? -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Typically when a software vendor says that a product is "intuitive" he means the exact opposite. pgpaaIOjnTZNd.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GPG signature verification problem?
I've tried to verify signature of the email that arrived from gnupg mailing list (sent by Ryan). Verification fails, with the following error message. I'm using GPG-v.1.4.7, and Thunderbird/Enigmail. Could somebody with a clue explain me what's wrong, and whether it's a problem with my config (and if so - what I should look at), or whether it's a bug in GPG? gpg command line and output:,C:\\Program Files\\GNU\\GnuPG\\gpg.exe --charset utf8 --batch --no-tty --status-fd 2 -d,gpg: invalid radix64 character 3A skipped,gpg: invalid radix64 character 2E skipped,gpg: invalid radix64 character 2E skipped,gpg: invalid radix64 character 28 skipped,gpg: invalid radix64 character 29 skipped,gpg: CRC error; B76AE6 - 431CA8,gpg: [don't know]: invalid packet (ctb=55) Thank you! -- Regards, Uri Blumenthal -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert J. Hansen Sent: Wednesday, April 18, 2007 10:14 AM To: Ryan Malayter Cc: gnupg-users@gnupg.org Subject: Re: Quantum computing -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 > Note that breaking Diffie-Hellman and other discrete logarithm based > algorithms is thought to be nearly equivalent to factoring, but has > not been proven to be so. Going off the top of my head, the DLP is known to be greater than or equal to the difficulty of the IFP. You can make strong arguments that they're equal difficulty in a computational-theoretic sense, and you can make strong arguments that in real silicon DLP will be stronger due to our current lack of understanding of how to efficiently use the general number field sieve for the DLP. The current state of the art in the GNFS requires a large amount of storage overhead for the DLP, while the storage overhead for the IFP is comparatively minimal. As a word of warning, comparing DLP to IFP is a spectacularly black art. There are so many nuances to it that just expressing some of the ideas in English is difficult. As further warning: it's 9:10am, I haven't yet had my morning cup of coffee, and I'm working without my references. This being the internet, there's also a nonzero chance that I'm barking mad. Confirm this information before relying on it. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEcBAEBCgAGBQJGJierAAoJELcA9IL+r4EJSgoH/jz2SyN/4ZfAsnoJossJn6cp /b/CND53iaqPnIv6vKcjDNfseBYdp2ZRHTZPw1ZVhd9+zdUwKr8IfVmFh8+XA/Ra ayEnbf/OzfVw+VK9nSJfvroHBZnW/UQYFkwFsCpwYpXLDSab1JjNPV1Ys67lqx3e gnM2w0fjDoXwE0hI+InCceL+bptOIpZL+xQN3AgYRovsUGG5rwngjOPk31+5SCFV iMe1msmNhOV8KWcIkOFHeRZQxHKMtDVoZfSnv7BLYh4Ufh/moNDpIF9RI1/JuwJI 5eSXPEAzNAOXSxqyyrd5YC9ykMxMss69/BD7I6yfBQxHCcskUBjDsynxjLg+2NQ= =Qxyo -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Quantum computing
On Wed, Apr 18, 2007 at 09:10:17AM +0200, Anders Breindahl wrote: > On 200704172359, Robert J. Hansen wrote: > > 1. We are unlikely to ever be able to brute-force a 256-bit > > keyspace. Ever. Not until computers are made of something other > > than matter, occupy something other than space, run on something > > other than energy, according to rules other than physics. > > I was under the impression that quantum computers were about to provide > a break in factorization. From quick grep on Wikipedia, I find that: Robert was commenting on a symmetric cipher (like AES), not asymmetric (like RSA). Factoring a 256-bit RSA key is trivial and can be done on regular home PCs in fairly short order. However, factoring is not an attack against symmetric ciphers. My favorite comment (from Jon Callas at PGP, Inc) about brute forcing keys is one I think I've posted here before, but still: Modern cryptographic systems are essentially unbreakable, particularly if an adversary is restricted to intercepts. We have argued for, designed, and built systems with 128 bits of security precisely because they are essentially unbreakable. It is very easy to underestimate the power of exponentials. 2^128 is a very big number. Burt Kaliski first came up with this characterization, and if he had a nickel for every time I tell it, he could buy a latte or three. Imagine a computer that is the size of a grain of sand that can test keys against some encrypted data. Also imagine that it can test a key in the amount of time it takes light to cross it. Then consider a cluster of these computers, so many that if you covered the earth with them, they would cover the whole planet to the height of 1 meter. The cluster of computers would crack a 128-bit key on average in 1,000 years. If you want to brute-force a key, it literally takes a planet-ful of computers. And of course, there are always 256-bit keys, if you worry about the possibility that government has a spare planet that they want to devote to key-cracking. Note that he's talking about brute-forcing keys here. If someone finds a weakness in AES (or whatever), then this math may change radically. Pure brute-forcing without such a weakness is just not viable. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm --import of CA certificate: Bad signature?
On Wed, 18 Apr 2007 14:11, [EMAIL PROTECTED] said: > It is possible to avoid a DER/BER decoder if you generate two > structures, one with NULL parameters and one with absent parameters, > and compare both against what's in the decrypted signatures. There is a plan tomove pkcs#1 decoding into libgcrypt. This would allow us to do a second compare without too much changes. I'll put it onto my todo list but don't expect it to happen anytime soon. > GnuTLS accepts both variants, so I made the change. I'll release an > updated stable version to help get it out as soon as possible. Would it be sufficient to do that just for SHA-1? In that case a hack in cipher/rsa.c would do the trick without too much fear of regression. Salam-Shalom, Werner ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Quantum computing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 > Note that breaking Diffie-Hellman and other discrete logarithm based > algorithms is thought to be nearly equivalent to factoring, but has > not been proven to be so. Going off the top of my head, the DLP is known to be greater than or equal to the difficulty of the IFP. You can make strong arguments that they're equal difficulty in a computational-theoretic sense, and you can make strong arguments that in real silicon DLP will be stronger due to our current lack of understanding of how to efficiently use the general number field sieve for the DLP. The current state of the art in the GNFS requires a large amount of storage overhead for the DLP, while the storage overhead for the IFP is comparatively minimal. As a word of warning, comparing DLP to IFP is a spectacularly black art. There are so many nuances to it that just expressing some of the ideas in English is difficult. As further warning: it's 9:10am, I haven't yet had my morning cup of coffee, and I'm working without my references. This being the internet, there's also a nonzero chance that I'm barking mad. Confirm this information before relying on it. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEcBAEBCgAGBQJGJierAAoJELcA9IL+r4EJSgoH/jz2SyN/4ZfAsnoJossJn6cp /b/CND53iaqPnIv6vKcjDNfseBYdp2ZRHTZPw1ZVhd9+zdUwKr8IfVmFh8+XA/Ra ayEnbf/OzfVw+VK9nSJfvroHBZnW/UQYFkwFsCpwYpXLDSab1JjNPV1Ys67lqx3e gnM2w0fjDoXwE0hI+InCceL+bptOIpZL+xQN3AgYRovsUGG5rwngjOPk31+5SCFV iMe1msmNhOV8KWcIkOFHeRZQxHKMtDVoZfSnv7BLYh4Ufh/moNDpIF9RI1/JuwJI 5eSXPEAzNAOXSxqyyrd5YC9ykMxMss69/BD7I6yfBQxHCcskUBjDsynxjLg+2NQ= =Qxyo -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Quantum computing
On 4/18/07, Anders Breindahl <[EMAIL PROTECTED]> wrote: > > However, I assume you know what you talk about, when you say that we > aren't likely to factor 256-bit-numbers ever. So please restate that -- > even in the face of quantum computers -- we won't ever factor 256 bit > numbers. > > By the way, I realize that this is a more general question of gnupg's > life expectancy in a quantum computer world. But it's interesting to get > answered. Robert was referring to a 256-bit key space, which refers to symmetric encryption, such as AES, Factoring, on the other hand, applies only to public-key RSA encryption. There "bits" mean something totally different; a bit of RSA key length is "worth less" than a bit of symmetric key length. Numbers have already been factored in the ~600 bit range, so at least 1024 bits are recommended for RSA, and 2048 bits is a good idea. The "keyspace" size of RSA is roughly equivalent to the O(exp(64/9b)^(1/3)(log b)^(2/3)) that you quote; That is the number of operations that must be performed to break the algorithm by brute force. For strong symmetric algorithms,like AES or Twofish, the number of operations required is simply two to the power of the number of bits in the key, Note that breaking Diffie-Hellman and other discrete logarithm based algorithms is thought to be nearly equivalent to factoring, but has not been proven to be so. I suggest you borrow a copy of Bruce Schneier's _Applied Cryptography_; it is a very good primer. Regards, Ryan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Quantum computing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 > On 200704172359, Robert J. Hansen wrote: >> 1. We are unlikely to ever be able to brute-force a 256-bit >> keyspace. Ever. Not until computers are made of something other >> than matter, occupy something other than space, run on something >> other than energy, according to rules other than physics. > > I was under the impression that quantum computers were about to > provide > a break in factorization. From quick grep on Wikipedia, I find that: They've been "about to provide" a break in factorization for the last 30 years. > However, I assume you know what you talk about, when you say that we > aren't likely to factor 256-bit-numbers ever. So please restate > that -- > even in the face of quantum computers -- we won't ever factor 256 bit > numbers. We're already factoring 256-bit numbers. Fortunately, I didn't claim 256-bit composites would forever be secure. I claimed 256-bit keyspace searches would be secure. Keyspace search is a different set of problems than factorization. For a brute-force search the best we can do is Grover's quantum database algorithm, which reduces it down to an equivalent 128-bit keyspace. From there we use quantum thermodynamics--namely the Margolus-Levitin theorem--to get some reasonable bounds on how much time, energy, etc., are required to do it. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEcBAEBCgAGBQJGJiWiAAoJELcA9IL+r4EJCTcH/RUOxI6RNuuu2WaCpAeJLfHs 0u+KzJ6MALtonHQOkAbhDTw8zTC+OTHEuN/t2+dwli6E8r7F61RIMpLyPiZpfS0y rQjHMqJPMdr7Xerhn1haGdov2MzbvtloqHBEP9T65fstTEYBXoYMDSNhYVRV1Fpz g+is39fVr6D3LZ5W50VQhtTwmcpGM7ZKl4XSgqtv2UwwPM7dYjMQ+Qgz+5MnPLe3 wZlD06/bvrbY5InFRQFMaFhNtVAC6v42G6W8AOv8WD0kXJCopUGOwYelQ40qhdug DvXWxpApv7jgmStms63AlG3TjQemwF3rkreFsk9IClAZ5T3EpTafqVd3HC4oYBc= =OqFT -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Quantum computing
On 4/18/07, Ryan Malayter <[EMAIL PROTECTED]> wrote: > Factoring, on the other hand, applies only to public-key RSA > encryption. There "bits" mean something totally different; a bit of > RSA key length is "worth less" than a bit of symmetric key length. > Numbers have already been factored in the ~600 bit range, so at least > 1024 bits are recommended for RSA, and 2048 bits is a good idea. This page represents a reasonable snapshot of the state of the art in factoring: http://www.rsa.com/rsalabs/node.asp?id=2093 One must assume that a governmental entity like China's Ministry of State Security can factor significantly larger numbers than the 640 bit factorization done by academic researchers. Which is why you often see recommendations for 1500+ bit RSA keys. -- Ryan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm --import of CA certificate: Bad signature?
Werner Koch <[EMAIL PROTECTED]> writes: >> Although it may be argued that RFC 4055 only applies to RSA-PSS, >> although this particular section is not clear that it only applies to >> RSA-PSS. > > The problem is that allowing for different encodings will require a > complete DER (or well for some old specs even BER) parser in libgcrypt. > Not long ago most crypto libraries showed implementaion flaws in that - > libgcrypt didn't suffer from this due its poor man's and simple approach > to checkthe RSA signature. Given that the code in gpgsm/libgcrypt has > passed several compatibility tests I doubnt that it is a good idea to > change it now and open the way to introduce new bugs. It is possible to avoid a DER/BER decoder if you generate two structures, one with NULL parameters and one with absent parameters, and compare both against what's in the decrypted signatures. >> I should probably change GnuTLS here. > > I'd appreciate that. If it later turns out that too many gnutls created > certificates are in use we might consider to add a hack to gpgsm just > for the SHA-1 case. GnuTLS accepts both variants, so I made the change. I'll release an updated stable version to help get it out as soon as possible. /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm --import of CA certificate: Bad signature?
On Wed, 18 Apr 2007 11:39, [EMAIL PROTECTED] said: > RFC 3279 is updated by RFC 4055 which says in section 2.1 (in > particular the second paragraph): Which is actually Peter's text but with a different suggestion. > Although it may be argued that RFC 4055 only applies to RSA-PSS, > although this particular section is not clear that it only applies to > RSA-PSS. The problem is that allowing for different encodings will require a complete DER (or well for some old specs even BER) parser in libgcrypt. Not long ago most crypto libraries showed implementaion flaws in that - libgcrypt didn't suffer from this due its poor man's and simple approach to checkthe RSA signature. Given that the code in gpgsm/libgcrypt has passed several compatibility tests I doubnt that it is a good idea to change it now and open the way to introduce new bugs. > I should probably change GnuTLS here. I'd appreciate that. If it later turns out that too many gnutls created certificates are in use we might consider to add a hack to gpgsm just for the SHA-1 case. Shalom-Salam, Werner ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm --import of CA certificate: Bad signature?
Werner Koch <[EMAIL PROTECTED]> writes:
> Thus we have an extra NULL and that is the reason that it does not
> verify. I am too tired to read pkcs#1 know; will do that tomorrow.
> Anyway it is the first case that I noticed such a pkcs#1 encoding.
Ah, I see. Whether the parameters should be NULL or absent seem to be
a frequent interop problem.
> Hi,
>
> whether the optional parameter of the AlgorithmIdentifier is really
> optional has changed over time. My ASN.1 derived from the German Sphinx
> profile state:
>
> AlgorithmIdentifier ::= SEQUENCE {
> algorithmOBJECT IDENTIFIER,
> parameters ANY DEFINED BY algorithm OPTIONAL
> -- should be used but set to NULL
> }
>
> rfc3280 (X.509) does not have this remark. Peter Gutmann's X.509 guide
> explains this issue:
>
> Another pitfall to be aware of is that algorithms which have no
> parameters have this specified as a NULL value rather than omitting
> the parameters field entirely. The reason for this is that when the
> 1988 syntax for AlgorithmIdentifier was translated into the 1997
> syntax, the OPTIONAL associated with the AlgorithmIdentifier
> parameters got lost. Later it was recovered via a defect report, but
> by then everyone thought that algorithm parameters were mandatory.
> Because of this the algorithm parameters should be specified as NULL,
> regardless of what you read elsewhere.
>
> How did you create this certificate?
With GnuTLS' certtool.
RFC 3280 references RFC 3279 on this, and it says:
When any of these three OIDs appears within the ASN.1 type
AlgorithmIdentifier, the parameters component of that type SHALL be
the ASN.1 type NULL.
RFC 3279 is updated by RFC 4055 which says in section 2.1 (in
particular the second paragraph):
There are two possible encodings for the AlgorithmIdentifier
parameters field associated with these object identifiers. The two
alternatives arise from the loss of the OPTIONAL associated with the
algorithm identifier parameters when the 1988 syntax for
AlgorithmIdentifier was translated into the 1997 syntax. Later the
OPTIONAL was recovered via a defect report, but by then many people
thought that algorithm parameters were mandatory. Because of this
history some implementations encode parameters as a NULL element
while others omit them entirely. The correct encoding is to omit the
parameters field; however, when RSASSA-PSS and RSAES-OAEP were
defined, it was done using the NULL parameters rather than absent
parameters.
All implementations MUST accept both NULL and absent parameters as
legal and equivalent encodings.
To be clear, the following algorithm identifiers are used when a NULL
parameter MUST be present:
sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL }
sha224Identifier AlgorithmIdentifier ::= { id-sha224, NULL }
sha256Identifier AlgorithmIdentifier ::= { id-sha256, NULL }
sha384Identifier AlgorithmIdentifier ::= { id-sha384, NULL }
sha512Identifier AlgorithmIdentifier ::= { id-sha512, NULL }
Although it may be argued that RFC 4055 only applies to RSA-PSS,
although this particular section is not clear that it only applies to
RSA-PSS.
I should probably change GnuTLS here.
/Simon
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Quantum computing
On 200704172359, Robert J. Hansen wrote: > 1. We are unlikely to ever be able to brute-force a 256-bit > keyspace. Ever. Not until computers are made of something other > than matter, occupy something other than space, run on something > other than energy, according to rules other than physics. I was under the impression that quantum computers were about to provide a break in factorization. From quick grep on Wikipedia, I find that: http://en.wikipedia.org/wiki/Integer_factorization#Difficulty_and_complexity: the best published asymptotic running time is for the general number field sieve (GNFS) algorithm, which, for a b-bit number n, is: O(exp(64/9b)^(1/3)(log b)^(2/3)) But for quantum computers, it'd seem that Shor's algorithm provides a leap: http://en.wikipedia.org/wiki/Shor's_algorithm: Shor's algorithm is a quantum algorithm for factoring a number N in O((log N)^3) time and O(log N) space. However, since large quantum computers are rather expensive, getting log N space is so costly that it isn't relevant just yet. However, I assume you know what you talk about, when you say that we aren't likely to factor 256-bit-numbers ever. So please restate that -- even in the face of quantum computers -- we won't ever factor 256 bit numbers. By the way, I realize that this is a more general question of gnupg's life expectancy in a quantum computer world. But it's interesting to get answered. Regards, skrewz. signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm --import of CA certificate: Bad signature?
Hi,
whether the optional parameter of the AlgorithmIdentifier is really
optional has changed over time. My ASN.1 derived from the German Sphinx
profile state:
AlgorithmIdentifier ::= SEQUENCE {
algorithmOBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL
-- should be used but set to NULL
}
rfc3280 (X.509) does not have this remark. Peter Gutmann's X.509 guide
explains this issue:
Another pitfall to be aware of is that algorithms which have no
parameters have this specified as a NULL value rather than omitting
the parameters field entirely. The reason for this is that when the
1988 syntax for AlgorithmIdentifier was translated into the 1997
syntax, the OPTIONAL associated with the AlgorithmIdentifier
parameters got lost. Later it was recovered via a defect report, but
by then everyone thought that algorithm parameters were mandatory.
Because of this the algorithm parameters should be specified as NULL,
regardless of what you read elsewhere.
How did you create this certificate?
Salam-Shalom,
Werner
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
