Re: A weakness in PGP signatures, and a suggested solution

-----BEGIN PGP SIGNED MESSAGE-----

> > In article <Pine.ULT.3.91.960110182255.18692H-100000@xdm011>, Jeffrey Goldberg <cc047@Cranfield.ac.uk> says:
> 
> But then the recipient has a PGP-signed message from you which
> isn't encrypted (using pgp -d). That person could then impersonate
> you. Eg Alice the jilted lover could resend the goodbye message
> with forged headers to Bob's new girlfriend to get back at him.

  Ah ha! Now I understand what this argument has been all about. This 
is not a flaw with PGP, but with the software doing the signing. It 
should/could add a line with a time and date stamp inside the 
signature envelope, or Bob could add more information, making the 
message more specific.

  I don't think PGP needs to be 'fixed', but the signing software 
does.

   Brian
 

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBMP0gGHIWObr6ZnuNAQFqpQMAhEDxcClXzwqS5QLSYgbGC0SdPwOSppgG
cbEcHEamA+C/fzlCRl1FoCkvA/SPHoZB29FNJSH8hnP6s5OZQfFf3LZXPL+/UFiL
64i7dlt6Ajtg58eDiMj/+qPsHd8hbAuV
=jj8n
-----END PGP SIGNATURE-----
--- <blane@eskimo.com> -------------------- <http://www.eskimo.com/~blane> ---
  Embedded System Programmer, EET Student, Interactive Fiction author (RSN!)
==============  11 99 3D DB 63 4D 0B 22  15 DC 5A 12 71 DE EE 36  ============

"Brian C. Lane" <blane@eskimo.com> writes:
> > > In article <Pine.ULT.3.91.960110182255.18692H-100000@xdm011>, Jeffrey Gol
> >
> > But then the recipient has a PGP-signed message from you which
> > isn't encrypted (using pgp -d). That person could then impersonate
> > you. Eg Alice the jilted lover could resend the goodbye message
> > with forged headers to Bob's new girlfriend to get back at him.
>
>   Ah ha! Now I understand what this argument has been all about. This
> is not a flaw with PGP, but with the software doing the signing. It
> should/could add a line with a time and date stamp inside the
> signature envelope, or Bob could add more information, making the
> message more specific.
>
>   I don't think PGP needs to be 'fixed', but the signing software
> does.

I think a two-fold fix would be welcome;

1. The signing software needs to copy these headers within the body in
a standard way. I think I've seen a couple of such hacks already.
That's a welcome idea.

2. When PGP verified the signature, it should have an option to look outside
the signed portion for RFC 822 headers and compare them to the signed copy
of he headers inside. If this is not in PGP, then then function would have to
be done by some non-portable wrapper.
(Of course, if your headers aren't RFC 822, you're out of luck.)

(As someone pointed out, PGP already time-stamps the signature.)

---

Dr. Dimitri Vulis
Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

> 2. When PGP verified the signature, it should have an option to look outside
> the signed portion for RFC 822 headers and compare them to the signed copy
> of he headers inside. If this is not in PGP, then then function would have to
> be done by some non-portable wrapper.
> (Of course, if your headers aren't RFC 822, you're out of luck.)

How?  PGP has no idea what is around the PGP message.  Also, the PGP
armor is, by definition, not a cryptographic manipulation, rather it
is just a tool for convenience.  The Armoring done by PGP could just
as easily be done by MIME or UUEncode; the functionality is just the
same as far as PGP is concerned.  The only difference is for the user,
who knows that "BEGIN PGP MESSAGE" means feed this data to PGP rather
than feeding it to some other program.

PGP really only looks at the contents between the BEGIN and END.  It
can't do anything else.  In fact, only the PGP Armor code even deals
with that.  By definition, PGP is a binary protocol and deal with
binary data objects.  So how can it look at any "RFC 822 Headers"?
There are no such animals in PGP.  It is perfectly legal to remove all
data before the BEGIN and all data after then END and feed the result
to PGP...

As I said, armor is a convenience to the user only.

PGP will not be modified in this way; it is the job of the mailer
(MUA) to do this sort of thing.  Sorry.

-derek

Derek Atkins writes:
[Dr Dimitri writes:]
> 
> > 2. When PGP verified the signature, it should have an option to look outside
> > the signed portion for RFC 822 headers and compare them to the signed copy
> > of he headers inside. If this is not in PGP, then then function would have to
> > be done by some non-portable wrapper.
> > (Of course, if your headers aren't RFC 822, you're out of luck.)
 
[..]
 
> PGP really only looks at the contents between the BEGIN and END.  It
> can't do anything else.  In fact, only the PGP Armor code even deals
> with that.  By definition, PGP is a binary protocol and deal with
> binary data objects.  So how can it look at any "RFC 822 Headers"?
> There are no such animals in PGP.  It is perfectly legal to remove all
> data before the BEGIN and all data after then END and feed the result
> to PGP...
> 
> As I said, armor is a convenience to the user only.
> 
> PGP will not be modified in this way; it is the job of the mailer
> (MUA) to do this sort of thing.  Sorry.

I agree.
PGP should be as generic as possible; making it "know" about RFC822
and mailers makes it less generic.

Your PGP-aware mail agent should add a line to the text to be
encrypted, consisting of a random number (hopefully very unguessable
and fairly random) and an RFC822 header:

X-PGP-nonce: b1de70694f5f0824f89cb3f09aece01d

and replicate that in the RFC822 envelope.
Put just the nonce value and not the header in the block to be
encrypted if you're concerned about assisting a known-plaintext attack.

The nonce can't be extracted from the PGP ciphertext unless the attacker
has the ability to crack PGP, in which case merely re-directing
PGP encrypted messages to different recipients is beneath them. :-)
It is small and is easily verified by the human looking at the message.
PGP, or more accurately the MUA, won't need to check it (although
that would be fairly easy to do).

But like Derek says, PGP shouldn't do it, the MUA should.

-- 
Eric Murray  ericm@lne.com  ericm@motorcycle.com  http://www.lne.com/ericm
PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03  92 E8 AC E6 7E 27 29 AF

> Your PGP-aware mail agent should add a line to the text to be
> encrypted, consisting of a random number (hopefully very unguessable
> and fairly random) and an RFC822 header:
> 
> X-PGP-nonce: b1de70694f5f0824f89cb3f09aece01d
> 
> and replicate that in the RFC822 envelope.
> Put just the nonce value and not the header in the block to be
> encrypted if you're concerned about assisting a known-plaintext attack.

Actually, that doesn't work either -- if I wanted to forward the
message you sent me to someone else to make them think that you sent
it to them, I could just take the nonce and put that in the header of
my forwarded message and it would match...

No, you need to include the "to" and "cc" fields as well inside the
signed message.  But again, the MUA should do this, not PGP.

-derek