Mailing List Archive: GnuPG: users

getting an encrypted file to show what public key was used

Index | Next | Previous | View Threaded

lefevre.10 at osu

May 29, 2012, 6:45 AM

Post #1 of 17 (664 views)
Permalink

getting an encrypted file to show what public key was used

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 remote hosts, so I cannot troubleshoot the
complete circuit on my own.

The host that cannot decrypt their file has the decruption running in
some kind of Windows batch file. The error message they get seems to
indicate the name of the public key that was used to encrypt the file.
I am trying to figure out of the name of the public key is actually
encoded into the gpg file. This is their error message:

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 [at] another_company>"
gpg: decryption failed: secret key not available

However, when I try to decrypt the file I'm sending them, without the
key, I get simply

$> gpg --decrypt sensitive_file.gpg
gpg: encrypted with ELG-E key, ID F1940956
gpg: decryption failed: secret key not available

I want gpg to report the email address of the key used to encrypt the
file, like in the error message I'm getting from the remote host. I
want to see "Different Public Key <another_key [at] another_company>",
like in their error message. But my gpg doesn't report that.

Is the name of the public key really encoded into the encrypted file?
Or is something else mixed up on the remote host (for instance, them
having the other hosts' private key)?

How can I see the name of the public key that encrypted the file? Am I
missing a switch?

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users

rjh at sixdemonbag

May 29, 2012, 8:02 AM

Post #2 of 17 (657 views)
Permalink

Re: getting an encrypted file to show what public key was used [In reply to]

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 [at] another_company>"
> gpg: decryption failed: secret key not available

Oh, cute. A short ID collision. :) Quaero Corporation's, apparently.

Short answer: try using gpg -vvvv sensitive-file.gpg. This will give
you a large amount of detailed information that might be useful for your
debugging.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users

tanguy.herrmann at gmail

May 29, 2012, 8:16 AM

Post #3 of 17 (651 views)
Permalink

Re: getting an encrypted file to show what public key was used [In reply to]

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=0xF1940956&op=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
fingerprint. And the flaw make that OpenPGP verify only that short Key
ID instead of the full fingerprint, and that leads to collision of Key
ID even if the keys are differents ...

The easier solution for you would be to create a new key

On Tue, May 29, 2012 at 5:02 PM, Robert J. Hansen <rjh [at] sixdemonbag> wrote:
> 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 [at] another_company>"
>> gpg: decryption failed: secret key not available
>
> Oh, cute. A short ID collision. :) Quaero Corporation's, apparently.
>
> Short answer: try using gpg -vvvv sensitive-file.gpg. This will give
> you a large amount of detailed information that might be useful for your
> debugging.
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users [at] gnupg
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users

mailinglisten at hauke-laging

May 29, 2012, 8:17 AM

Post #4 of 17 (651 views)
Permalink

Re: getting an encrypted file to show what public key was used [In reply to]

Am Di 29.05.2012, 11:02:03 schrieb Robert J. Hansen:
> 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 [at] another_company>"
> >
> > gpg: decryption failed: secret key not available
>
> Oh, cute. A short ID collision. :)

What can you see that from?

Hauke
--
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814

Attachments:

signature.asc (0.54 KB)

rjh at sixdemonbag

May 29, 2012, 8:28 AM

Post #5 of 17 (655 views)
Permalink

Re: getting an encrypted file to show what public key was used [In reply to]

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 Corporation already has a certificate with the
short ID of 0xF1940956 on the keyservers, created
2002-04-25.
4. He imported Quaero Corporation's certificate
5. He believes he's using the correct certificate for his
correspondent, since he's using the short ID they
specified
6. He's actually using Quaero Corporation's certificate
7. And his correspondents can't read the traffic, since
he's using the wrong certificate.

I could be wrong, of course, but that's where I'd place my bets.

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."

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users

mailinglisten at hauke-laging

May 29, 2012, 8:31 AM

Post #6 of 17 (653 views)
Permalink

Re: getting an encrypted file to show what public key was used [In reply to]

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 [at] another_company>"
> gpg: decryption failed: secret key not available
>
> However, when I try to decrypt the file I'm sending them, without the
> key, I get simply
>
> $> gpg --decrypt sensitive_file.gpg
> gpg: encrypted with ELG-E key, ID F1940956
> gpg: decryption failed: secret key not available

Was this try in the same GnuPG environment like the encoding or was one within
PHP and the other one as your regular user account?

GnuPG does not report UIDs if the key is not available in the keyring. The
error message tells us that the key which you have encoded for (0xF1940956 (or
its main key), "Different Public Key <another_key [at] another_company>) is
part of the decoding system's keyring but only the public key. So you encode
for the wrong key.

> I want gpg to report the email address of the key used to encrypt the
> file, like in the error message I'm getting from the remote host. I
> want to see "Different Public Key <another_key [at] another_company>",
> like in their error message. But my gpg doesn't report that.

You have to import the respective key in order to get that information.

> Is the name of the public key really encoded into the encrypted file?

No, just the (long) ID of the used key (i.e. possibly a subkey).

> How can I see the name of the public key that encrypted the file? Am I
> missing a switch?

You can search the keyservers for subkeys, too.

gpg --keyserver pool.sks-keyservers.net --search-keys 0xF1940956

I am confused by Robert's short ID collision hint but my remarks should be
correct anyway.

Hauke
--
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814

Attachments:

signature.asc (0.54 KB)

wk at gnupg

May 29, 2012, 8:35 AM

Post #7 of 17 (652 views)
Permalink

Re: getting an encrypted file to show what public key was used [In reply to]

On Tue, 29 May 2012 15:45, lefevre.10 [at] osu 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 file. Use this to
find the key on a server, etc.

Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users

mailinglisten at hauke-laging

May 29, 2012, 8:36 AM

Post #8 of 17 (652 views)
Permalink

Re: getting an encrypted file to show what public key was used [In reply to]

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 a nice possibility for checking how serious the handling of keys by
your partners is: Create a key with a short ID collision for a key available
on the keyservers and give them the short ID... 8-)

Hauke
--
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814

Attachments:

signature.asc (0.54 KB)

hka at qbs

May 29, 2012, 9:06 AM

Post #9 of 17 (651 views)
Permalink

Re: getting an encrypted file to show what public key was used [In reply to]

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 4.5, "validate the certificate
> > he just received."
>
> Looks like a nice possibility for checking how serious the handling of
> keys by your partners is: Create a key with a short ID collision for a
> key available on the keyservers and give them the short ID... 8-)
>

No, thank you. Getting people to use any form of crypto is hard enough. We
don't need to show them that it doesn't fix all problems...

Regards,
--
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawer�w 30/85
tel. +48 (22) 646-61-51, 646-74-24
www.qbs.com.pl

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users

rjh at sixdemonbag

May 29, 2012, 9:24 AM

Post #10 of 17 (652 views)
Permalink

Re: getting an encrypted file to show what public key was used [In reply to]

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 "seems likely.")

> And the flaw make that OpenPGP verify only that short Key
> ID instead of the full fingerprint, and that leads to collision of Key
> ID even if the keys are differents ...

Certificate validation uses the full fingerprint.

> The easier solution for you would be to create a new key

I apologize for sounding strident here, but that advice is both
malinformed and wrong.

It's malinformed because when something fails, we should learn why it
failed and develop processes to prevent the failure in the future.
Saying "well, just have a do-over" is not consistent with the best
practices of software engineering.

It's wrong because it's the other person whose certificate has a
collision. He can create all the new certificates he wants but it won't
change a thing. He may also not be able to persuade the other person to
generate a new certificate: they may have already invested a lot in
their current certificate, and may not want to switch.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users

lefevre.10 at osu

May 29, 2012, 10:54 AM

Post #11 of 17 (653 views)
Permalink

Re: getting an encrypted file to show what public key was used [In reply to]

On Tue, May 29, 2012 at 11:28 AM, Robert J. Hansen <rjh [at] sixdemonbag> 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 the keyservers, created
> � � � � � �2002-04-25.
> � � � �4. �He imported Quaero Corporation's certificate
> � � � �5. �He believes he's using the correct certificate for his
> � � � � � �correspondent, since he's using the short ID they
> � � � � � �specified
> � � � �6. �He's actually using Quaero Corporation's certificate
> � � � �7. �And his correspondents can't read the traffic, since
> � � � � � �he's using the wrong certificate.
>
> I could be wrong, of course, but that's where I'd place my bets.

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.

I was confused about how the remote host could learn the "name" of the
public key, but apparently their script looks it up from public
sources, or already has it on their keyring, or whatever.

I was not aware of a method I could use to tell which key I had just
encrypted a file with, but thanks to the replies, I now know that the
key ID will let me know :)

Steve Lefevre

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users

rjh at sixdemonbag

May 29, 2012, 11:12 AM

Post #12 of 17 (652 views)
Permalink

Re: getting an encrypted file to show what public key was used [In reply to]

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 via a
non-email/non-IM form of contact, like the telephone). After getting in
touch with the right person and verifying to your satisfaction that
you're really talking to the right person, just ask: "Hey, I need the
full fingerprint of your OpenPGP key. Not the short ID, but the full
fingerprint. Would you help me with that, please?"

Write down the full fingerprint.

Then say, "And could you please email me your public key?"

Then:

$ gpg --delete-key 0xF1940956

Once the email with their certificate arrives, save it to disk and:

$ gpg --import <their certificate>
$ gpg --edit-key <their certificate>

>From the edit-key screen, type 'fingerprint' to check the full
fingerprint. Make sure it matches what you were given on the phone. If
it matches, then from the edit-key screen, type 'lsign'. This will
validate the certificate, and at this point you'll have a fairly high
assurance that you're using the correct certificate. :)

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users

wk at gnupg

May 29, 2012, 12:29 PM

Post #13 of 17 (653 views)
Permalink

Re: getting an encrypted file to show what public key was used [In reply to]

On Tue, 29 May 2012 19:54, lefevre.10 [at] osu 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. --with-colons prints the long bit key ID.

Shalom-Salam,

Werner

p.s.
I have said this at least a hundred times, but it is still not known
well enough. The small scripts in tools/ use this method and should
give the intial idea to look into the man page and check what this
--with-colons is about. Would an option --annotate which enables
--with-colons, --batch, and --status-fd be helpful?

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users

lefevre.10 at osu

May 29, 2012, 12:32 PM

Post #14 of 17 (655 views)
Permalink

Re: getting an encrypted file to show what public key was used [In reply to]

On Tue, May 29, 2012 at 3:29 PM, Werner Koch <wk [at] gnupg> wrote:
> On Tue, 29 May 2012 19:54, lefevre.10 [at] osu 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. �--with-colons prints the long bit key ID.
>

I was being a bit ambiguous -- by 'script' I meant a PHP program, not
a shell script :P

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users

mailinglisten at hauke-laging

May 29, 2012, 1:02 PM

Post #15 of 17 (657 views)
Permalink

Re: getting an encrypted file to show what public key was used [In reply to]

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, and --status-fd be helpful?

I don't think so because giving --with-colons, --batch, and --status-fd is not
the problem. Making this easier should not have a big effect on the problem.

The problem is knowledge (and discipline). So the aim should be to spread the
knowledge. This could be done by printing a warning to stderr when stdin and
stdout are not terminals and these options are not given:

"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/..."

Hauke
--
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814

Attachments:

signature.asc (0.54 KB)

wk at gnupg

May 29, 2012, 3:14 PM

Post #16 of 17 (653 views)
Permalink

Re: getting an encrypted file to show what public key was used [In reply to]

On Tue, 29 May 2012 22:02, mailinglisten [at] hauke-laging 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/..."

Well, scripts won't see that message ;-). They might also assume
something about stderr output and break. Well, such a break has the
benefit that the authors need to look at the problem.

Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-users mailing list
Gnupg-users [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-users

mwood at IUPUI

May 30, 2012, 5:57 AM

Post #17 of 17 (652 views)
Permalink

Re: getting an encrypted file to show what public key was used [In reply to]

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."

Indeed. The problem is much like a hash index. And anyone who's used
hash indexing* should know that he must search the indicated "bucket"
for the record which actually matches the search key. Hashing only
cuts the size of the search space; it doesn't guarantee reducing it to
a single-element space.

----------------
* And anyone who puts socks in one drawer and shirts in another has
used hash indexing. :-)

--
Mark H. Wood, Lead System Programmer mwood [at] IUPUI
Asking whether markets are efficient is like asking whether people are smart.

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads