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
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: 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: 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 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: 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
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
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 Disclaimer -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: 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
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: 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
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 brutus/idl/products/evolution/2.4/brutus-keyring/ 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
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: 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?
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?
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
