Subject: RE: secure sign & encrypt

From: Terje Braaten <[email-masked]>
Date: Wed, 22 May 2002 21:46:21 +0200

> -----Original Message-----
> From: Jon Callas [mailto:[email-masked]]
> Sent: 22. May 2002 21:10
> To: Terje Braaten; OpenPGP
> Subject: Re: secure sign & encrypt
> 
> 
> Hal posted a pointer to my comments on this from last year. 
> I'll weigh in
> again.
> 
> I think this is an issue with semantics. You can't solve 
> semantic problems
> with added syntax, no matter how much syntax you add.

It is important that the syntax will let you express the semantics
you want to use. So yes, this is also a syntax problem.
It is not possible with the current protocol to make PGP applications
that automatically check if the signer and the encrypter is the same
person when sign & encrypt has been used.

> 
> Furthermore, there are risks with this, too. You can still perform a
> redirection attack on a targeted signature. Suppose Alice is 
> trying to do a
> business deal with both Bob and Charlie, and trying to get 
> the best price.
> If Bob sends Charlie a signed message that is targeted to 
> him, it can be
> more embarrassing than if the signature were untargeted. I'm 
> really sorry,
> but if you send a private message to someone who puts it on 
> their web page,
> you might be irked by this.

I do not quite see the relevance of this. Do you think it is bad
that Charlie can prove that the message was sent to him from Bob
and not only signed by Bob?
If Bob want to prevent this he can sign first and then encrypt,
instead of using the sign & encrypt function in PGP.

> 
> One of the things that I try to keep an eye out for is 
> traffic analysis. I
> think it is a feature of OpenPGP that it puts the signatures 
> inside the
> envelope, because if they're outside the envelope, you have

The signature will still be inside the envelope. Only those that
the message are encrypted to will be able to see the signature.

> cryptographically assisted traffic analysis. Targeting in 
> signatures also
> assists traffic analysis, and users who don't understand that signing
> low-context messages is a bad idea aren't going to understand traffic
> analysis issues.

It will still be possible to just sign something. It is only when
you use sign & encrypt the receivers should be able to be sure that
the one who signed and the one who encrypted the message is the same
person.

> 
> Lastly, if you really, really want to do this, there is 
> already support in
> the OpenPGP protocol for it! This is one of the myriad things 
> notations are
> good for. Software can make a signature with a human-readable 
> notation in it
> that is boilerplate. It could say, "Created on <date> by <source> for
> <target>." There's your targeting, just convince some 
> implementer to do it.

But the point is not to make some human readable boilerplate. The
point is that OpenPGP software automatically should be able to detect
if the message has been faked to look like it is created by
sign & encrypt when it really is not.

> Just don't make me use it, thanks. I'll have even less reason to sign
> things.

You will still have the option to do the signing and encryption in
two operations. Then the 'encrypted to' packets will not be present
in the signature.

-- 
Terje Bråten

---

From: Derek Atkins <[email-masked]>
Date: 22 May 2002 19:23:17 -0400

> instead of using the sign & encrypt function in PGP.

You seem to be under the misconception that "sigh & enrypt" is an
atomic PGP operation.  It is not.  There is "OpenPGP Sign" and there
is "OpenPGP Encrypt", and these two functions _can_ be combined, but
the combination is NOT a single atomic function.  It never was.

All PGP ever had was "first sign and then encrypt".  It was just
user-interface "syntactic sugar" that allows the user to perform both
tasks together.  However, there is no way for a receiver to tell the
difference between a one-pass and two-pass "sign and then encrypt".

> the one who signed and the one who encrypted the message is the same

As I said, there is no "combined sign and encrypt" atomic operation in
OpenPGP (or in regular PGP, for that matter).

> sign & encrypt when it really is not.

What do you mean?  Can you please explain what attack you believe
you are preventing?

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available