Subject: separation of signed and encrypted pgp mesages into signed pgp messages

From: "vedaal" <[email-masked]>
Date: Mon, 2 Jul 2001 13:15:27 -0400

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

There was a recent paper,
<http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html>
describing a flaw in the sign and encrypt function of Open PGP.

the author assumes that is is possible for the recipient
to strip off the encryption from a signed and encrypted pgp message, 
leaving only a verified signed message,
and that the ability to do this is ensured in the Open PGP Standard

{afaik} this can be done in pgp only when both the receiver and sender are
using RSA keys, 

{can be done only from 2.6.x with the simple one step command: 
 pgp -da(filename)
which will leave an armored signed message in text form, with a signature
that verifies in any version of pgp

cannot be done in later command line versions of pgp, as the -d command,
will just decrypt, and not leave a signature,   
the -b command will do the same.}

the people at sci.crypt seem to feel that as long as the program conforms
to pgp standards, such a separation is *do-able* for any key type, even if
a
custom program must be written to do this.

does anyone know of any way that this separation can be done for a message 
signed and encrypted with a DH/dss key, 
with pgp, gpg or any other program, and, is it, in-fact, guaranteed by the 
Open PGP Standard, that it 'must' be so?

vedaal

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.263 / Virus Database: 135 - Release Date: 6/22/01

---

From: Jon Callas <[email-masked]>
Date: Mon, 2 Jul 2001 11:15:39 -0700

>describing a flaw in the sign and encrypt function of Open PGP.

Well, while this is an interesting paper, it doesn't really describe a
cryptographic problem at all, it describes a semantic problem.

The problems he outlines don't require encryption, they all work equally
well with clear-signed messages, and as someone else pointed out probably
work just fine with unsigned messages for the simple reason that if someone
sends bare text, people tend to believe its authenticity.

>{afaik} this can be done in pgp only when both the receiver and sender are

OpenPGP describes that a message is signed, and then the bundle of the
plaintext and signature are encrypted. So yes, it's certainly possible for
someone to decrypt a message and you then have in your hands a signed
message. It does *not* matter what key type it is; the packet formats are
the same no matter what the key type.

>Open PGP Standard, that it 'must' be so?

Take a look at the RFC. Look in particular at Section 10.2. There's nothing
in there that specifies what the key type is.

	Jon

---

From: "Michael Young" <[email-masked]>
Date: Mon, 2 Jul 2001 16:35:51 -0400

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

> describing a flaw in the sign and encrypt function of Open PGP.

Despite the gratuitously over-hyped title, the paper does make it
clear that the "flaw" is one of understanding.  In particular, it is
necessary to understand *what* is being signed, and for many systems,
it is *only* the message body.  Unsigned material, including headers
(sender, receiver, and what-not), can be changed.  If you want clear
identities (or other context) in the signed text, you need to put
them there.

Yes, some products gloss over the details.  PGP, for instance,
labels the function "Encrypt&Sign" when it really works in the
other order.

> and that the ability to do this is ensured in the Open PGP Standard

Yes.  This *can* be a desirable feature.  If you don't like it, you
can: (a) include enough context in the signed material; and/or, (b)
manually encrypt, then sign (but as the paper points out, doing so
without context offers only marginally different protection).  I'd be
more than happy for end-user agents to offer to do one or both.  I
would not be happy with the specification mandating particular agent
behavior -- it does not appear to mandate sign-then-encrypt now.

> {afaik} this can be done in pgp only when both the receiver and sender are

No.  The specification does not tie packet composition to the type
of key used.  [But in practice: newer PGP versions that support DSA/DH
keys also support one-pass signatures, so they may have extra packets,
but this has no bearing on the "problem" at hand.]