On Tue, May 29, 2012 at 11:28:36AM -0400, Robert J. Hansen wrote:
This goes to underline the importance of proper certificate validation.
If I have the sequence of events correct, then it could have been
avoided entirely if there had been a Step 4.5, validate the certificate
he just received.
I am using gnupg via PHP's wrapper for it. I am sending an ecrypted
files to remote hosts, using two different keys for the respective
hosts. One host can decrypt the file properly, but the other host
cannot.
I am trying to troubleshoot this bug. Of course, I do not have the
private keys from the
On 5/29/12 9:45 AM, Steven Lefevre wrote:
gpg: encrypted with 2048-bit ELG-E key, ID F1940956, created 2002-04-25
Different Public Key another_key@another_company.com
gpg: decryption failed: secret key not available
Oh, cute. A short ID collision. :) Quaero Corporation's, apparently.
On 5/29/12 11:17 AM, Hauke Laging wrote:
What can you see that from?
Can't, but it seems to be the most likely option.
The most likely cause of this seems to be --
1. His correspondent said use certificate 0xF1940956.
2. He did a gpg --recv-key 0xF1940956.
3. Quaero
Am Di 29.05.2012, 11:28:36 schrieb Robert J. Hansen:
This goes to underline the importance of proper certificate validation.
If I have the sequence of events correct, then it could have been
avoided entirely if there had been a Step 4.5, validate the certificate
he just received.
Looks like
On Tue, 29 May 2012 15:45, lefevre...@osu.edu said:
$ gpg --decrypt sensitive_file.gpg
gpg: encrypted with ELG-E key, ID F1940956
gpg: decryption failed: secret key not available
Use
gpg --keyid-format long --decrypt sensitive_file.gpg
to see the non-abbreviated key ID as stored in the
Steven,
The key who has the Short Key ID of F1940956 has the same short Key ID
as : http://keyserver.ubuntu.com:11371/pks/lookup?search=0xF1940956op=vindex
This is a flaw in the OpenPGP protocol (If I remember right). Short
Key ID are only the last 8 hexadecimal characters of the full
On 05/29/2012 11:35 AM, Werner Koch wrote:
Use
gpg --keyid-format long --decrypt sensitive_file.gpg
to see the non-abbreviated key ID as stored in the file. Use this to
find the key on a server, etc.
i've seen a lot of these mistakes where people seem to think that 32-bit
keyids are
Am Di 29.05.2012, 09:45:48 schrieb Steven Lefevre:
Beginning GPG Decryption
Using current version of GNUPG
gpg: encrypted with 2048-bit ELG-E key, ID F1940956, created 2002-04-25
Different Public Key another_key@another_company.com
gpg: decryption failed: secret key not available
Am Di 29.05.2012, 11:51:06 schrieb Daniel Kahn Gillmor:
I think switching the default to long would be on balance a Good Thing.
A smaller change which should solve most of these problems could be to
change the error message. If gpg is operating with the short format then a
respective hint
On Tuesday 29 of May 2012 17:36:25 Hauke Laging wrote:
Am Di 29.05.2012, 11:28:36 schrieb Robert J. Hansen:
This goes to underline the importance of proper certificate validation.
If I have the sequence of events correct, then it could have been
avoided entirely if there had been a Step
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2012-05-29 17:51, Daniel Kahn Gillmor wrote:
On 05/29/2012 11:35 AM, Werner Koch wrote:
...
I think switching the default to long would be on balance a Good
Thing.
I agree, and don't see much of a reason not to use a long KeyID rather
On 5/29/12 11:51 AM, Daniel Kahn Gillmor wrote:
Perhaps GnuPG should change the default of --keyid-format from short
to long?
Hurts interoperability. Once someone learns the process on PGP or
BouncyCastle or [insert OpenPGP implementation here], they're going to
want to take those same skills
On 5/29/12 11:16 AM, Tanguy Herrmann wrote:
This is a flaw in the OpenPGP protocol (If I remember right).
The protocol is fine, but it seems that the people involved did not
properly validate certificates. (Note that I'm not certain about this,
hence my seems. Maybe I should qualify it as
On May 29, 2012, at 11:51 AM, Daniel Kahn Gillmor wrote:
On 05/29/2012 11:35 AM, Werner Koch wrote:
Use
gpg --keyid-format long --decrypt sensitive_file.gpg
to see the non-abbreviated key ID as stored in the file. Use this to
find the key on a server, etc.
i've seen a lot of these
On Tue, May 29, 2012 at 1:47 PM, David Shaw ds...@jabberwocky.com wrote:
On May 29, 2012, at 11:51 AM, Daniel Kahn Gillmor wrote:
What is your concern here, though - accidental or intentional collision?
Certainly both; while accidental collision isn't probable, 32-bit IDs
aren't exactly
On May 29, 2012, at 2:05 PM, Sam Whited wrote:
On Tue, May 29, 2012 at 1:47 PM, David Shaw ds...@jabberwocky.com wrote:
On May 29, 2012, at 11:51 AM, Daniel Kahn Gillmor wrote:
What is your concern here, though - accidental or intentional collision?
Certainly both; while accidental
On 5/29/12 1:54 PM, Steven Lefevre wrote:
This is, not surprisingly, the case. There was bad logic in my script
and somehow, somewhere, it's using the wrong key for this particular
host.
The good news is it's an easy problem to fix. :)
Get in touch with your contact over there (preferably
On Tue, May 29, 2012 at 11:28 AM, Robert J. Hansen r...@sixdemonbag.org wrote:
1. His correspondent said use certificate 0xF1940956.
2. He did a gpg --recv-key 0xF1940956.
3. Quaero Corporation already has a certificate with the
short ID of 0xF1940956 on
On Tue, 29 May 2012 19:54, lefevre...@osu.edu said:
This is, not surprisingly, the case. There was bad logic in my script
and somehow, somewhere, it's using the wrong key for this particular
Speaking of scripts: Scripts should use --with-colons and never try to
parse the regular output.
On Tue, May 29, 2012 at 3:29 PM, Werner Koch w...@gnupg.org wrote:
On Tue, 29 May 2012 19:54, lefevre...@osu.edu said:
This is, not surprisingly, the case. There was bad logic in my script
and somehow, somewhere, it's using the wrong key for this particular
Speaking of scripts: Scripts
On 05/29/2012 02:18 PM, David Shaw wrote:
The reason I bring it up is that using the v3 key attack, 64-bit key IDs have
no particular benefit over 32-bit IDs for intentional collisions (i.e. an
attacker generating a key with the same key ID as the victim in order to
confuse matters and/or
Am Di 29.05.2012, 21:29:51 schrieb Werner Koch:
I have said this at least a hundred times, but it is still not known
well enough.
You probably mean: Among the readers of this list. How much known may it be
in the wild...?
Would an option --annotate which enables
--with-colons, --batch,
On May 29, 2012, at 3:34 PM, Daniel Kahn Gillmor wrote:
On 05/29/2012 02:18 PM, David Shaw wrote:
The reason I bring it up is that using the v3 key attack, 64-bit key IDs
have no particular benefit over 32-bit IDs for intentional collisions (i.e.
an attacker generating a key with the same
On Tue, 29 May 2012 22:02, mailinglis...@hauke-laging.de said:
You are probably running gpg non-interactively. In order not to break
scripts
it is strongly encouraged to use scripted output of gpg only with the options
--with-colons, --batch and --status-fd. See http://www.gnupg.org/...;
25 matches
Mail list logo
