Subject: RE: secure sign & encrypt

From: Terje Braaten <[email-masked]>
Date: Thu, 30 May 2002 07:38:22 +0200

Michael Young writes that "The intended recipient is only one of many
pieces of context that a user might mistakenly believe was included
in the signed material." That is correct, but I will still argue that
the information on which keys the message is encrypted to (or intended
to be encrypted to) is special, and belongs in the OpenPGP standard.

It is not only mail that can be signed and encrypted with OpenPGP,
it can be all kinds of electronic documents and messages. When f.ex.
an "X-To-PGP-Key" header might be an adequate solution for e-mail
messages, it will not fit at all for other sorts of messages.
In fact, the only meta data about a message that is common to all
encrypted messages is the recipient public keys. And since this
is meta data about the message that is always present, I think
it is very appropriate to be specified in the protocol a convention
on how this is to be protected in a message that is signed and encrypted.

(If we could just have an optional sub packet on the signature in the first
round I would be happy.)

-- 
Terje Bråten

---

From: "Brian M. Carlson" <[email-masked]>
Date: Thu, 30 May 2002 19:15:10 +0000

> (If we could just have an optional sub packet on the signature in the first

You can have this. The standard declares that subpackets 100 to 110 are
"internal or user-defined". You can even set the critical bit on it if
you like. This should solve your problem. Your only other problem is to
convince an implementer to implement this subpacket, or you can
implement it yourself. Do know that gpg has used 101 in the past for
internal purposes; this might be a bad choice.

This subpacket is completely optional; in fact all but two subpackets
are: the creation time, and the issuer.

Therefore, this discussion can end, knowing everybody is happy.

-- 
Brian M. Carlson
<[email-masked]>
OpenPGP: 0x351336B2DCA1913A

---

From: Jon Callas <[email-masked]>
Date: Thu, 30 May 2002 13:07:12 -0700

> Therefore, this discussion can end, knowing everybody is happy.

The correct solution is to use a notation packet, not the 100-110 range.
That's why they're there.

But other than that, I agree completely. The discussion can end, because the
current protocol has features that support the desired implementation.

    Jon

Date: Thu, 30 May 2002 13:07:12 -0700
Subject: Re: secure sign & encrypt
From: Jon Callas <[email-masked]>
To: "Brian M. Carlson" <[email-masked]>, Terje Braaten <[email-masked]>
CC: OpenPGP <[email-masked]>
Sender: [email-masked]

> Therefore, this discussion can end, knowing everybody is happy.

The correct solution is to use a notation packet, not the 100-110 range.
That's why they're there.

But other than that, I agree completely. The discussion can end, because the
current protocol has features that support the desired implementation.

    Jon

From: "Brian M. Carlson" <[email-masked]>
Date: Thu, 30 May 2002 19:15:10 +0000
To: Terje Braaten <[email-masked]>
Cc: "OpenPGP (E-mail)" <[email-masked]>
Subject: Re: secure sign & encrypt
Content-Conversion: prohibited
Sender: [email-masked]

--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 30, 2002 at 07:38:22AM +0200, Terje Braaten wrote:
>=20
>=20
>=20
> (If we could just have an optional sub packet on the signature in the fir=
st

--=20
Brian M. Carlson
<[email-masked]>

--C7zPtVaVf+AK4Oqc
Content-Type: application/pgp-signature
Content-Disposition: inline

--C7zPtVaVf+AK4Oqc--

To: Terje Braaten <[email-masked]>
Cc: [email-masked]
From: Derek Atkins <[email-masked]>
Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted P GP message is useless
Date: 30 May 2002 10:30:09 -0400
Lines: 39
Sender: [email-masked]

Terje Braaten <[email-masked]> writes:

> > >> 	Encrypt_Bob(K), Encrypt(K, Sign_Alice(Hash(K||Bob_PK)), msg)
> > >>
> > >> with the additional restriction that the encryption mode 
> > should be one
> > >> of the MDC modes (ie appended MAC with K outside encryption, or
> > >> appended hash of msg inside encryption).
> 
> What a wonderful solution. Hello everybody, we go ahead and change
> the next version of the protocol to this. Ok?

No.  It is definitely not ok.  This breaks backwards compatibiltiy
with implementations of 2440.

No matter what you do it should be backwards compatible with existing
software.  Current implementations should still be able to read it,
even if they don't understand it.

My two suggestions still remain:

  1) Write up an RFC that defines how to use a notation packet to do
     what you want, where that notation packet is included in the
     signature.  Within that notation you can store the original
     recipients list.

  2) Write up an RFC that defines how to use 2440 packets in ESE mode.
     I'm fairly sure that most of the existing 2440 implementation can
     read an ESE message (at least if they implemented their parser
     recursively like I did in PGP 5).

Either of these solutions solve your problem _AND_ remain
2440-compatible.

-derek
-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

From: Terje Braaten <[email-masked]>
To: [email-masked]
Subject: RE: Recipient-verifiable messages, was: forwarding an encrypted P GP message is useless
Date: Thu, 30 May 2002 07:48:24 +0200
Sender: [email-masked]

[email-masked] wrote:
> 
> Hal Finney <[email-masked]>:
> > Adam Back writes:
> 
> >> What we proposed is related.  Rather
> >> than the normal encrypted signed message:
> >>
> >> 	Encrypt_Bob(K), Encrypt(K, Sign_Alice(Hash(msg)), msg)
> >>
> >> we proposed:
> >>
> >> 	Encrypt_Bob(K), Encrypt(K, Sign_Alice(Hash(K||Bob_PK)), msg)
> >>
> >> with the additional restriction that the encryption mode 
> should be one
> >> of the MDC modes (ie appended MAC with K outside encryption, or
> >> appended hash of msg inside encryption).

What a wonderful solution. Hello everybody, we go ahead and change
the next version of the protocol to this. Ok?

-- 
Terje Bråten

From: Terje Braaten <[email-masked]>
To: "OpenPGP (E-mail)" <[email-masked]>
Subject: RE: secure sign & encrypt
Date: Thu, 30 May 2002 07:38:22 +0200
Sender: [email-masked]

-- 
Terje Bråten

Date: Wed, 29 May 2002 14:04:49 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: secure sign & encrypt
Sender: [email-masked]

The S/MIME WG has wrestled with the same issues, coming to the same 
problems that have appeared here. The latest thinking there can be 
found in the the tread that starts at 
<http://www.imc.org/ietf-smime/mail-archive/msg01238.html>.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Sun, 26 May 2002 17:52:36 +0200
From: Bodo Moeller <[email-masked]>
To: [email-masked], Hal Finney <[email-masked]>, [email-masked]
Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
Sender: [email-masked]

On Sun, May 26, 2002 at 03:28:41PM +0000, Bodo Moeller wrote:
> Hal Finney <[email-masked]>:
>> Adam Back writes:

>>> we proposed:
>>>
>>> 	Encrypt_Bob(K), Encrypt(K, Sign_Alice(Hash(K||Bob_PK)), msg)

>> I see, that seems to work well too.  [...]

> Does it?  If Bob is willing to reveal  K  and additional data such as
> padding used for RSA encryption, can't everyone verify that this is
> indeed a valid signature by Alice on 'msg'?

Oops, I've been parsing the parentheses incorrectly.

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

Date: Sun, 26 May 2002 17:28:41 +0200 (CEST)
To: [email-masked], "Hal Finney" <[email-masked]>, [email-masked]
From: [email-masked] (Bodo Moeller)
Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
Sender: [email-masked]

Hal Finney <[email-masked]>:
> Adam Back writes:

>> What we proposed is related.  Rather
>> than the normal encrypted signed message:
>>
>> 	Encrypt_Bob(K), Encrypt(K, Sign_Alice(Hash(msg)), msg)
>>
>> we proposed:
>>
>> 	Encrypt_Bob(K), Encrypt(K, Sign_Alice(Hash(K||Bob_PK)), msg)
>>
>> with the additional restriction that the encryption mode should be one
>> of the MDC modes (ie appended MAC with K outside encryption, or
>> appended hash of msg inside encryption).

>> To break that down: we hash Bob's public key so that Bob can't turn
>> around and forge an arbitrary an arbitrary message from Alice to
>> Charlie using signed K.  What Bob is left with is proof that Alice
>> sent him a message, but no evidence of what the message body was.

> I see, that seems to work well too.  [...]

Does it?  If Bob is willing to reveal  K  and additional data such as
padding used for RSA encryption, can't everyone verify that this is
indeed a valid signature by Alice on 'msg'?

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: secure sign & encrypt
Date: Fri, 24 May 2002 20:56:08 -0400
Sender: [email-masked]

To: [email-masked]
Subject: Re: secure sign & encrypt
X-Comment: I, too, was hoping that this would die out before
  the urge to weigh in overwhelmed me, but it hasn't :-).

I generally side with Jon, Hal, and Derek here.  The intended
recipient is only one of many pieces of context that a user
might mistakenly believe was included in the signed material.
Adding a subpacket to address just this one piece of context
doesn't strike me as necessary, particularly since there are
very reasonable solutions within the existing framework:
notation subpackets; or, layered (encrypt-sign-encrypt) processing.

Ultimately the problem is one of user misunderstanding, arguably
exacerbated by the user interfaces in specific implementations.
Either the users need to be better educated, or the implementations
need to do a better job expressing exactly what has been signed
(and, perhaps, for naive users, the indirect implications).
Neither requires a change to the specification, just to the
implementation (of the tool or the user :-).

I appreciate Terje's desire to encode context so that it can be
checked automatically, and a desire for a convention for doing the
encoding, for implementations that want to do so.  I would have no
objection to publishing a convention for encoding the intended
recipients in a notation packet.  That wouldn't have to be part of the
base RFC.  That said, I wouldn't *strenuously* object to this being
documented in the base RFC, or even to a new OPTIONAL subpacket.  I
just don't think it helps enough: it doesn't cover other context;
and, it doesn't help for "legacy" messages.  Here "legacy" means
both old implementations (that don't support the packet) and
old V3 signatures (which don't have subpackets at all).

A few specific comments on one of Terje's notes:

> To word the problem in another way, when Alice send a message to Bob
> that is signed and encrypted, Bob should be able to be sure that it
> was Alice that encrypted the message.

I disagree that this is a fundamental goal -- it is a derived one.
The real goal is more likely that Bob wants to know that the message
is intended for him.  Knowing that Alice encrypted it is neither
necessary nor sufficient to meet this real goal.  I think this
difference is what Derek was getting at when he asked about goals.

> Some solutions:
> - Teach Bob not to trust PGPs sign & encrypt to know who the sender

Perhaps, as a means of teaching Bob:
  - Warn Bob about the limitations, something like:
    "The signature does not name you as the recipient.  This document
     may have been forwarded to you by the original recipient.
     Do not assume that it was intended for you."

    This may seem verbose, but naive users often have problems
    with shorthands for complex concepts: "(Invalid)" comes to mind :-).

    Again, this is the best that you can do for legacy messages, anyway.

> - Make PGP use Encrypt, Sign and Encrypt.

It's fine to have a particular implementation adopt this layering (or
to offer it as an option).  It would be very wrong to legislate this
particular layering.  While users may not understand the implications
of particular layerings, implementors clearly should understand, and
should be trusted to choose the layering appropriate for their
perceived users' needs.  You may want a tool that offers
encrypt-sign-encrypt (to identify the intended recipient); someone
else may want a tool that meets other goals (e.g., anonymity or
plausible deniability).  Any good tool should make it clear what
function it is performing, but that's not a *protocol specification*
issue.

> - Add fingerprints of recipient keys in signature packets (Requires
> a change
>   in the protocol)

Or,
  - Offer to copy context into the plaintext, or into notations.
    For example, an MUA might offer to copy the "To", "cc", and "Subject"
    headers.  It could even inject an "X-To-PGP-Key" header to record the
    key fingerprint/ID for automatic verification by like-minded agents.
    There's no deep reason that this requires a protocol change.

Date: Fri, 24 May 2002 16:58:06 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: secure sign & encrypt
Cc: [email-masked]
Sender: [email-masked]

"David P. Kemp" <[email-masked]> writes:

>Each layer does what it does - if you want the security services provided by
>three layers (ESE), or what S/MIME calls triple-wrapping (SES), then you must
>use three layers.

The motivation for S/MIME triple wrap was AFAIK use by automated mail gateways.
If you always have to sign the plaintext then it makes it impossible to create
a mail gateway which only lets signed data in or out, because the gateway would
have to hold all the private keys in order to verify the sigs.  Thus the SES
triple-wrap.  I know Don Davis looked at the RFC which covered this (2633?)
when he was writing his paper and found it didn't really solve the problem.

Peter.

From: Terje Braaten <[email-masked]>
To: [email-masked]
Subject: RE: secure sign & encrypt
Date: Thu, 23 May 2002 23:25:17 +0200
Sender: [email-masked]

What is the problem I try to solve? I thought that had been clear
through the many mails I sent, but let me try to explain again.

1) Don Davis has a pretty good description of the problem in
	http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html
	He lists many good reasons why this is a problem in section 4.

2) Many users seem to think that PGPs sign & encrypt function is atomic.
	We can try to teach them that is never was so, and never will be
	(a bad solution in my opinion) or we can give the users what they
	want/expect and make it possible to have an atomic sign & encrypt
	in PGP.

To word the problem in another way, when Alice send a message to Bob
that is signed and encrypted, Bob should be able to be sure that it
was Alice that encrypted the message.

Description of attack:

Alice send a signed & encrypted message to Charlie. Charlie decrypts
it and encrypts and sends it to Bob, trying to convince Bob the message
comes directly from Alice. Since Bob see the message is apparently
made by sign & encrypt he thinks it must be Alice that has encrypted it.

Some solutions:

	- Teach Bob not to trust PGPs sign & encrypt to know who the sender
	  of the message is when it is not in the plain text of the signed
	  message.

	- Make PGP use Encrypt, Sign and Encrypt. (Slower
encryption/decryption
	  and bigger messages.)

	- Add fingerprints of recipient keys in signature packets (Requires
a change
	  in the protocol)
-- 
Terje Bråten

From: Terje Braaten <[email-masked]>
To: "'Derek Atkins'" <[email-masked]>, Terje Braaten <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: RE: secure sign & encrypt
Date: Thu, 23 May 2002 22:34:10 +0200
Sender: [email-masked]

Derek Atkins <[email-masked]> writes:
> 
> Terje Braaten <[email-masked]> writes:
> 
> > Derek Atkins <[email-masked]> wrote:
> > > I'm not sure exactly what you mean by when you say Alice 
> saves a copy
> > > of the session key... How does Alice get that key to 
> Charlie?  Also
> > > keep in mind that the interior and exterior encryptions SHOULD be
> > > using different session keys.  So, I don't understand 
> what you mean?
> > 
> > She could send it to Charlie in a different mail, or add it 
> on the outside
> > of the signature (ES) packet before she encrypt and send it 
> to Charlie.
> > And since she control the building of the message, another solution
> > would be that she could also use the same session key in 
> the interior and
> > exterior encryptions no matter what the protocol says 
> should be done.
> 
> But then Charlie KNOWS that Alice did the dastardly deed.  Moreover,
> you'd need extremely special reader to be able to read such a message,
> because it would not be 2440-compliant.

No, if Alice faked the e-mail headers, he could think it was Bob that
sent it to him, and also revealed to him the session key to the inner
encryption packet. It is exactly the same case as if Alice just had
used SE and signed a packet with the recipient keys in the inner message.
Charlie would KNOW that something was wrong, but not if Alice or Bob
was to blame.

> 
> > > Can you show the packets that Charlie sees?  I don't see any way
> > > to add a new ESK on the interior message without invalidating the
> > > signature....
> > 
> > Charlie sees after decrypting the first layer
> >  PreSig[Alice]{ESK [Bob] Enc { Literal { Message } } }PostSig[Alice]
> 
> Ok, can you show me the complete message Charlie receives (before he
> decrypts the first layer)?  Note that if Charlie sees this message, it
> is quite clear that the message was meant for Bob alone.

Yes, but was it Bob that leaked the information or Alice? See he cannot
know.

> 
> > In addition he has, or can make ESK[Charlie]. This 
> information he can
> > claim he must have got from Bob, since he is the only 
> original recipient.
> 
> How can Charlie insert an ESK[Charlie] and not invalidate the
> signature?

He cannot insert it in the inner encryption packet without invalidating
the signature, but he can make use of it to read the encrypted message.

-- 
Terje Bråten

To: Terje Braaten <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: secure sign & encrypt
From: Derek Atkins <[email-masked]>
Date: 23 May 2002 16:29:45 -0400
Lines: 101
Sender: [email-masked]

Which attacks are you trying to prevent?

I've seen different people trying to prevent different attacks here.
Pretty much every solution (except the ESE solution) protects against
some of the various attacks but not all of them.  Even better, ESE is
completely 2440-compliant, wheras all these other approaches seem to
require changes to the protocol.

I'd really like to see a clear problem statement (including a threat
model) before we change 2440 or add new packets that really only help
a subset of the problem.  Please write a concise statement about what
threat(s) you see and the problem(s) you want to solve.  Please leave
out the "how you intend to solve the problems".  We should first agree
that:

        a) a problem exists that needs to be solved, and
        b) we are actually trying to solve the right problem.

-derek

Terje Braaten <[email-masked]> writes:

> Derek Atkins <[email-masked]> wrote:
> > 
> > This doesn't help.  Any recipient could re-encrypt the message and
> > change the list of encrypted recipients.
> > 
> 
> Sure it helps against the man in the middle that disastry wanted to
> protect against. Any recipient of an encrypted message can do what
> he like with it anyway, so no of course it does not help against
> any unfaithful recipient.
> 
> -- 
> Terje Bråten
> 
> 
> > > disastry wrote:
> > > > fake pubkey encryption packets can be added
> > > > by man in the middle so that recipient thinks that 
> > message was encrypted
> > > > to him and to other preson.
> > > > 
> > > > I wrote about it here:
> > > > 
> > http://lists.gnupg.org/pipermail/gnupg-devel/2001-August/006285.html
> > > 
> > > I think this can be solved by modifying
> > > Sym. Encrypted Integrity Protected Data Packet (Tag 18).
> > > 
> > > Now it is:
> > > 
> > > version byte == 1
> > > encrypted data
> > > 
> > > encrypted data consists of:
> > >   encrypted iv
> > >   encrypted plaintext
> > >   encrypted Modification Detection Code Packet (Tag 19)
> > > 
> > > I suggest:
> > > 
> > > version byte == 2
> > > encrypted data
> > > 
> > > encrypted data consists of:
> > >   encrypted iv
> > >   encrypted Recipients packet (Tag 20)
> > >     (put it before plaintext - if it would be after it would
> > >      be difficult to find where plaintext ends, when decrypting)
> > >   encrypted plaintext
> > >   encrypted Modification Detection Code Packet (Tag 19)
> > > 
> > > Recipients packet
> > >   version byte == 1
> > >   number of recipients, 2 bytes (should be enough..)
> > >   number_of_recipients*20 byte list of fingerprints recipient keys
> > >     (16 byte RSA v3 key fingerprints are appended with 4 zeros
> > >      (or maybe with 4 lowest keyid bytes? I think, it's 
> > even better))
> > > 
> > > 
> > > this ensures that recipient list is intact not only for 
> > signed & encrypted messages
> > > but also for encrypted only messages.
> > > 
> > > __
> > > Disastry  http://disastry.dhs.org/
> > 
> > -- 
> >        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
> > 

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

To: Terje Braaten <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: secure sign & encrypt
From: Derek Atkins <[email-masked]>
Date: 23 May 2002 16:21:50 -0400
Lines: 44
Sender: [email-masked]

Terje Braaten <[email-masked]> writes:

> Derek Atkins <[email-masked]> wrote:
> > I'm not sure exactly what you mean by when you say Alice saves a copy
> > of the session key... How does Alice get that key to Charlie?  Also
> > keep in mind that the interior and exterior encryptions SHOULD be
> > using different session keys.  So, I don't understand what you mean?
> 
> She could send it to Charlie in a different mail, or add it on the outside
> of the signature (ES) packet before she encrypt and send it to Charlie.
> And since she control the building of the message, another solution
> would be that she could also use the same session key in the interior and
> exterior encryptions no matter what the protocol says should be done.

But then Charlie KNOWS that Alice did the dastardly deed.  Moreover,
you'd need extremely special reader to be able to read such a message,
because it would not be 2440-compliant.

> > Can you show the packets that Charlie sees?  I don't see any way
> > to add a new ESK on the interior message without invalidating the
> > signature....
> 
> Charlie sees after decrypting the first layer
>  PreSig[Alice]{ESK [Bob] Enc { Literal { Message } } }PostSig[Alice]

Ok, can you show me the complete message Charlie receives (before he
decrypts the first layer)?  Note that if Charlie sees this message, it
is quite clear that the message was meant for Bob alone.

> In addition he has, or can make ESK[Charlie]. This information he can
> claim he must have got from Bob, since he is the only original recipient.

How can Charlie insert an ESK[Charlie] and not invalidate the
signature?

> Terje Bråten

-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

From: Terje Braaten <[email-masked]>
To: "'Derek Atkins'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: secure sign & encrypt
Date: Thu, 23 May 2002 22:09:25 +0200
Sender: [email-masked]

Derek Atkins <[email-masked]> wrote:
> 
> This doesn't help.  Any recipient could re-encrypt the message and
> change the list of encrypted recipients.
> 

Sure it helps against the man in the middle that disastry wanted to
protect against. Any recipient of an encrypted message can do what
he like with it anyway, so no of course it does not help against
any unfaithful recipient.

-- 
Terje Bråten

> > disastry wrote:
> > > fake pubkey encryption packets can be added
> > > by man in the middle so that recipient thinks that 
> message was encrypted
> > > to him and to other preson.
> > > 
> > > I wrote about it here:
> > > 
> http://lists.gnupg.org/pipermail/gnupg-devel/2001-August/006285.html
> > 
> > I think this can be solved by modifying
> > Sym. Encrypted Integrity Protected Data Packet (Tag 18).
> > 
> > Now it is:
> > 
> > version byte == 1
> > encrypted data
> > 
> > encrypted data consists of:
> >   encrypted iv
> >   encrypted plaintext
> >   encrypted Modification Detection Code Packet (Tag 19)
> > 
> > I suggest:
> > 
> > version byte == 2
> > encrypted data
> > 
> > encrypted data consists of:
> >   encrypted iv
> >   encrypted Recipients packet (Tag 20)
> >     (put it before plaintext - if it would be after it would
> >      be difficult to find where plaintext ends, when decrypting)
> >   encrypted plaintext
> >   encrypted Modification Detection Code Packet (Tag 19)
> > 
> > Recipients packet
> >   version byte == 1
> >   number of recipients, 2 bytes (should be enough..)
> >   number_of_recipients*20 byte list of fingerprints recipient keys
> >     (16 byte RSA v3 key fingerprints are appended with 4 zeros
> >      (or maybe with 4 lowest keyid bytes? I think, it's 
> even better))
> > 
> > 
> > this ensures that recipient list is intact not only for 
> signed & encrypted messages
> > but also for encrypted only messages.
> > 
> > __
> > Disastry  http://disastry.dhs.org/
> 
> -- 
>        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
> 

From: Terje Braaten <[email-masked]>
To: "'Derek Atkins'" <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: RE: secure sign & encrypt
Date: Thu, 23 May 2002 22:02:30 +0200
Sender: [email-masked]

Derek Atkins <[email-masked]> wrote:
> I'm not sure exactly what you mean by when you say Alice saves a copy
> of the session key... How does Alice get that key to Charlie?  Also
> keep in mind that the interior and exterior encryptions SHOULD be
> using different session keys.  So, I don't understand what you mean?

She could send it to Charlie in a different mail, or add it on the outside
of the signature (ES) packet before she encrypt and send it to Charlie.
And since she control the building of the message, another solution
would be that she could also use the same session key in the interior and
exterior encryptions no matter what the protocol says should be done.

> 
> Can you show the packets that Charlie sees?  I don't see any way
> to add a new ESK on the interior message without invalidating the
> signature....

Charlie sees after decrypting the first layer
 PreSig[Alice]{ESK [Bob] Enc { Literal { Message } } }PostSig[Alice]

In addition he has, or can make ESK[Charlie]. This information he can
claim he must have got from Bob, since he is the only original recipient.

-- 
Terje Bråten

To: Terje Braaten <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: secure sign & encrypt
From: Derek Atkins <[email-masked]>
Date: 23 May 2002 15:42:50 -0400
Lines: 43
Sender: [email-masked]

I'm not sure exactly what you mean by when you say Alice saves a copy
of the session key... How does Alice get that key to Charlie?  Also
keep in mind that the interior and exterior encryptions SHOULD be
using different session keys.  So, I don't understand what you mean?

Can you show the packets that Charlie sees?  I don't see any way
to add a new ESK on the interior message without invalidating the
signature....

-derek

Terje Braaten <[email-masked]> writes:

> David P. Kemp <[email-masked]> wrote:
> > Your proposal for an extra packet does not address this alleged flaw.
> > Note that Alice could sign a message saying "encrypted to 
> > Bob", and then
> > encrypt and send the message to Charlie, thus framing Bob for breach
> > of confidence.
> 
> Now that I have had time to think about it, the same could be done if
> we used ESE. Alice can encrypt the packet to Bob and save a copy of
> the symmetric key used to encrypt the message before encrypting it with
> Bobs public key. Then she sign the encrypted packet, include some extra
> packet with the session key she saved and encrypt it for Charlie.
> Then Charlie receives an ESE packet where he can decrypt the inner
> encryption
> with the symmtreic key provided. And looking at the signature it looks like
> it is originally encrypted for Bob, so it "must" be Bob that has leaked
> the information and also given him the symmetric key.
> 
> So, in that respect my solution is no inferior to ESE regarding security.
> And you avoid the cost of one extra encryption.
> 
> -- 
> Terje Bråten
> 

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

From: Terje Braaten <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: RE: secure sign & encrypt
Date: Thu, 23 May 2002 21:31:27 +0200
Sender: [email-masked]

David P. Kemp <[email-masked]> wrote:
> Your proposal for an extra packet does not address this alleged flaw.
> Note that Alice could sign a message saying "encrypted to 
> Bob", and then
> encrypt and send the message to Charlie, thus framing Bob for breach
> of confidence.

Now that I have had time to think about it, the same could be done if
we used ESE. Alice can encrypt the packet to Bob and save a copy of
the symmetric key used to encrypt the message before encrypting it with
Bobs public key. Then she sign the encrypted packet, include some extra
packet with the session key she saved and encrypt it for Charlie.
Then Charlie receives an ESE packet where he can decrypt the inner
encryption
with the symmtreic key provided. And looking at the signature it looks like
it is originally encrypted for Bob, so it "must" be Bob that has leaked
the information and also given him the symmetric key.

So, in that respect my solution is no inferior to ESE regarding security.
And you avoid the cost of one extra encryption.

-- 
Terje Bråten

To: [email-masked]
Cc: [email-masked]
Subject: Re: secure sign & encrypt
From: Derek Atkins <[email-masked]>
Date: 23 May 2002 14:47:27 -0400
Lines: 60
Sender: [email-masked]

This doesn't help.  Any recipient could re-encrypt the message and
change the list of encrypted recipients.

-derek

[email-masked] writes:

> disastry wrote:
> > fake pubkey encryption packets can be added
> > by man in the middle so that recipient thinks that message was encrypted
> > to him and to other preson.
> > 
> > I wrote about it here:
> > http://lists.gnupg.org/pipermail/gnupg-devel/2001-August/006285.html
> 
> I think this can be solved by modifying
> Sym. Encrypted Integrity Protected Data Packet (Tag 18).
> 
> Now it is:
> 
> version byte == 1
> encrypted data
> 
> encrypted data consists of:
>   encrypted iv
>   encrypted plaintext
>   encrypted Modification Detection Code Packet (Tag 19)
> 
> I suggest:
> 
> version byte == 2
> encrypted data
> 
> encrypted data consists of:
>   encrypted iv
>   encrypted Recipients packet (Tag 20)
>     (put it before plaintext - if it would be after it would
>      be difficult to find where plaintext ends, when decrypting)
>   encrypted plaintext
>   encrypted Modification Detection Code Packet (Tag 19)
> 
> Recipients packet
>   version byte == 1
>   number of recipients, 2 bytes (should be enough..)
>   number_of_recipients*20 byte list of fingerprints recipient keys
>     (16 byte RSA v3 key fingerprints are appended with 4 zeros
>      (or maybe with 4 lowest keyid bytes? I think, it's even better))
> 
> 
> this ensures that recipient list is intact not only for signed & encrypted messages
> but also for encrypted only messages.
> 
> __
> Disastry  http://disastry.dhs.org/

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

Date: Thu, 23 May 2002 19:26:05 +0200
From: [email-masked]
To: [email-masked]
Subject: Re: secure sign & encrypt
Sender: [email-masked]

disastry wrote:
> fake pubkey encryption packets can be added
> by man in the middle so that recipient thinks that message was encrypted
> to him and to other preson.
> 
> I wrote about it here:
> http://lists.gnupg.org/pipermail/gnupg-devel/2001-August/006285.html

I think this can be solved by modifying
Sym. Encrypted Integrity Protected Data Packet (Tag 18).

Now it is:

version byte == 1
encrypted data

encrypted data consists of:
  encrypted iv
  encrypted plaintext
  encrypted Modification Detection Code Packet (Tag 19)

I suggest:

version byte == 2
encrypted data

encrypted data consists of:
  encrypted iv
  encrypted Recipients packet (Tag 20)
    (put it before plaintext - if it would be after it would
     be difficult to find where plaintext ends, when decrypting)
  encrypted plaintext
  encrypted Modification Detection Code Packet (Tag 19)

Recipients packet
  version byte == 1
  number of recipients, 2 bytes (should be enough..)
  number_of_recipients*20 byte list of fingerprints recipient keys
    (16 byte RSA v3 key fingerprints are appended with 4 zeros
     (or maybe with 4 lowest keyid bytes? I think, it's even better))

this ensures that recipient list is intact not only for signed & encrypted messages
but also for encrypted only messages.

__
Disastry  http://disastry.dhs.org/

From: Terje Braaten <[email-masked]>
To: [email-masked]
Subject: RE: secure sign & encrypt
Date: Thu, 23 May 2002 18:20:47 +0200
Sender: [email-masked]

Dominikus Scherkl <[email-masked]> wrote:
> > > Your proposal for an extra packet does not address this alleged
> flaw.
> > > Note that Alice could sign a message saying "encrypted to 
> > > Bob", and then
> > > encrypt and send the message to Charlie, thus framing Bob 
> for breach
> > > of confidence.
> > 
> > No, because then Charlie would know it was something fishy going on.
> > He would not now if Alice or Bob (or some one else) was to blame,
> > but he would get a warning message saying that this is an invalid
> > signed & encrypted message.
> Hey, this is an attack at _Bob_ - Charlie don't needs to be nice!
> The simple possibility of such attacks discredits the trust in beeing
> the original receiver of a message, so we gain nothing!

The only one that could mount such an attack is Alice, the
person that has signed the message. So such an attack would be easily
traceable. The trust in who is the original receiver of a message
will depend on that you trust the signer if test to see if
the signer and encrypter is the same person is false.
Yes, that makes this method a bit weaker than ESE. When the test
fails you cannot infer anything about who was the real recipient.
But if the test to see if the signer and encrypter is the same person
returns true, then you can indeed be sure that the signer and
encrypter is the same person.

-- 
Terje Bråten

content-class: urn:content-classes:message
Subject: RE: secure sign & encrypt
Date: Thu, 23 May 2002 17:58:11 +0200
From: "Dominikus Scherkl" <[email-masked]>
To: "Derek Atkins" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi.

> > I see no other way than "encrypt, sign and encrypt" (ESE)
> > to archive all cyptografic goals which seems inportant to me:

> The interesting thing is that there is nothing STOPPING an application
> from doing this today.  OpenPGP messages like the following are
> perfectly legal syntax, even in 2440:
> 
> ESK [...] Enc { PreSig ESK [...] Enc { Literal { Message } } PostSig }
> 
> Go ahead and implement this.  I'm fairly sure that most of the OpenPGP
> Parsers out there will Do The Right Thing with this (I'm 99% sure that
> PGP 6.5.x will do this, since I wrote that original parser code).

Of course. That's the main advantage of ESE, we can do it without
protocol changes - to insert a new button in the applications will
be enough.
In addition ESE has the property John Callas repeatedly claimed
to be important, and which can't be archived by simply adding
a copy of the header fields to the envelop:
it ensures that the reciever cannot forward a message
without destroying the signature or reveiling that it was
originaly send to him for his eyes only.
Also ESE can't be cheeted by adding fake addresses to the envelop.

And the old SE remains available, if you like the message can be
forwarded but therefore repudiated.

Best Regards
-- 
Dominikus Scherkl
[email-masked]

content-class: urn:content-classes:message
Subject: RE: secure sign & encrypt
Date: Thu, 23 May 2002 17:40:45 +0200
From: "Dominikus Scherkl" <[email-masked]>
To: "Terje Braaten" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi!

> > Your proposal for an extra packet does not address this alleged
flaw.
> > Note that Alice could sign a message saying "encrypted to 
> > Bob", and then
> > encrypt and send the message to Charlie, thus framing Bob for breach
> > of confidence.
> 
> No, because then Charlie would know it was something fishy going on.
> He would not now if Alice or Bob (or some one else) was to blame,
> but he would get a warning message saying that this is an invalid
> signed & encrypted message.
Hey, this is an attack at _Bob_ - Charlie don't needs to be nice!
The simple possibility of such attacks discredits the trust in beeing
the original receiver of a message, so we gain nothing!

Best Regards.
-- 
Dominikus Scherkl
[email-masked]

Date: Thu, 23 May 2002 17:04:48 +0200
From: [email-masked]
To: [email-masked]
Subject: Re: secure sign & encrypt
Sender: [email-masked]

vedaal wrote:
> ----- Original Message -----
> From: "Terje Braaten" <[email-masked]>
> Sent: Monday, May 20, 2002 7:31 PM
> Subject: RE: secure sign & encrypt
> 
> [...]
> 
>  > The problem is that most users when they decrypt a message
> > that is signed, they will think they can be sure the signer
> > and the encrypter is the same person/entity.
> > It would be a major improvement in the OpenPGP specification
> > to allow applications to ensure that that really is the case.
> 
> [...]
> 
> Functionally, that is the case now in Open PGP.
> 
> Even though a signed and encrypted message can be separated into a
> verifiable free standing signed message, and then
> re-encrypted and sent on to someone else,
> it 'cannot' {afaik} be re-combined into a signed and encrypted message that
> appears the same as a de-novo signed and encrypted message.

it can be done.
it's even not necessary to fully decrypt the message,
one can just decrypt only pubkey encryption to get session key,
then encrypt this session key to other pubkey!

what bothering me more is that fake pubkey encryption packets can be added
by man in the middle so that recipient thinks that message was encrypted
to him and to other preson.

I wrote about it here:
http://lists.gnupg.org/pipermail/gnupg-devel/2001-August/006285.html

__
Disastry  http://disastry.dhs.org/
http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon
 ^----PGP 2.6.3ia-multi06 (supports IDEA, CAST5, BLOWFISH, TWOFISH,
      AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes)

From: Terje Braaten <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: RE: secure sign & encrypt
Date: Thu, 23 May 2002 16:08:02 +0200
Sender: [email-masked]

David P. Kemp <mailto:[email-masked]> wrote: 
> Your proposal for an extra packet does not address this alleged flaw.
> Note that Alice could sign a message saying "encrypted to 
> Bob", and then
> encrypt and send the message to Charlie, thus framing Bob for breach
> of confidence.

No, because then Charlie would know it was something fishy going on.
He would not now if Alice or Bob (or some one else) was to blame,
but he would get a warning message saying that this is an invalid
signed & encrypted message.

> 
> You can't take two operations that are inherently separable and create
> a magic hack that makes them inherently and verifiably atomic.  Each
> layer does what it does - if you want the security services provided
> by three layers (ESE), or what S/MIME calls triple-wrapping (SES),
> then you must use three layers.

Well, if you use three layers (ESE), you get the added bonus that you
can easily see what is wrong if someone try to do something bad.
But also with my proposed method you can verify if everything is ok or not.

-- 
Terje Bråten

Date: Thu, 23 May 2002 15:10:34 +0100
From: Matthew Byng-Maddick <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: secure sign & encrypt
Organization: Colondot.net
Mail-Copies-To: never
Sender: [email-masked]

On Thu, May 23, 2002 at 02:22:19PM +0200, Terje Braaten wrote:
> Matthew Byng-Maddick <[email-masked]> wrote:
> > As others have pointed out, what is the "atomic sign & 
> > encrypt" of which you
> > speak?
> I envision that in a not too far feature, we can call the
> sign & encrypt function in PGP an atomic sign & encrypt.
> This is the solution of the problem that I have been trying
> to describe all the time.
[...]
> Adding a new signature packet called 'encrypted to' (or something
> like that) would allow OpenPGP applications to implement
> such an atomic sign & encrypt. It could say in the protocol
> that an application MAY implement atomic sign & encrypt,
> and if it does, it MUST do such and such.

Of course, a better way to do this is the obvious one, for the signtext
to start with "Dear Bob," and then you know who it was intended for. This
is the recommendation in the few cryptographic texts I've read about
non-repudiation.

This, of course, requires educating users, <sarcasm>which is a much harder
problem than attempting to solve it in some convoluted (and probably wrong)
cryptographic way.</sarcasm>

If your users don't properly understand the attempted guarantees of the
cryptosystem, then whatever you do to try and make it better, they will
almost certainly make some other assumption about it.

MBM

-- 
Matthew Byng-Maddick         <[email-masked]>           http://colondot.net/

To: Terje Braaten <[email-masked]>
Cc: [email-masked]
Subject: Re: secure sign & encrypt
From: Derek Atkins <[email-masked]>
Date: 23 May 2002 09:25:42 -0400
Lines: 28
Sender: [email-masked]

Terje Braaten <[email-masked]> writes:

> The method I have suggested is to sign the recipient's name into the
> message, as this avoids another costly encryption. Unfortunately
> this is very disturbing to those that think sign and encrypt must
> and should be independent layers in the protocol. But I think
> there should be possible to open up for certain exceptions to this
> layer thinking when security needs demands it.

As has been pointed out, you do NOT need an automated method to
do this.  Just put a plane user-readable string of the recipient's
identity into the signed message -- the PLAINTEXT message.

This is something that the MUA would do and requires no changes to the
PGP Protocol.

Note that any user with any intelligence would know that a message
that begins "Dear Bob" was _not_ meant for Charlie.

> Terje Bråten

-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

Date: Thu, 23 May 2002 09:21:50 -0400
From: "David P. Kemp" <[email-masked]>
To: Terje Braaten <[email-masked]>
CC: OpenPGP <[email-masked]>
Subject: Re: secure sign & encrypt
Sender: [email-masked]

Terje Braaten wrote:
> 
> Derek Atkins <[email-masked]> writes:
> 
> > Repeat to yourself: IT IS A FEATURE THAT SIGN AND ENCRYPT ARE
> > SEPARABLE OPERATIONS.  Once you make that statement, there is no way,
> > short of layering violations, to do what you want to do except at the
> > application later duplicating the information.
> 
> And I say it is a security flaw that that sign and encrypt must be
> separable operations, and for the implementation of an atomic and secure
> sign & encrypt you have to make an exception to this layering model.

Your proposal for an extra packet does not address this alleged flaw.
Note that Alice could sign a message saying "encrypted to Bob", and then
encrypt and send the message to Charlie, thus framing Bob for breach
of confidence.

You can't take two operations that are inherently separable and create
a magic hack that makes them inherently and verifiably atomic.  Each
layer does what it does - if you want the security services provided
by three layers (ESE), or what S/MIME calls triple-wrapping (SES),
then you must use three layers.

From: Terje Braaten <[email-masked]>
To: [email-masked]
Subject: RE: secure sign & encrypt
Date: Thu, 23 May 2002 15:07:38 +0200
Sender: [email-masked]

Dominikus Scherkl <mailto:[email-masked]> wrote:
> I see no other way than "encrypt, sign and encrypt" (ESE)
> to archive all cyptografic goals which seems inportant to me:

Yes that is one of the five methods Don Davis wrote about as a solution in
http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html

I agree with you that SES is not a good solution because it leaves
the signature unprotected at the outer layer.

The method I have suggested is to sign the recipient's name into the
message, as this avoids another costly encryption. Unfortunately
this is very disturbing to those that think sign and encrypt must
and should be independent layers in the protocol. But I think
there should be possible to open up for certain exceptions to this
layer thinking when security needs demands it.

-- 
Terje Bråten

From: Terje Braaten <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: RE: secure sign & encrypt
Date: Thu, 23 May 2002 14:54:23 +0200
Sender: [email-masked]

Derek Atkins <[email-masked]> writes:
> You see, I view this just like regular mail.  There is the envelope
> information, and there is the "letter".  By _CONVENTION_ the person
> writing a letter duplicates the envelope information on the inside.

A very useful picture indeed. The PGP program puts the information
about who it is encrypted to on the envelope on the outside. So
if we want to have this convention the PGP program must also be the
application that put this same information on the inside of the
envelope. The natural place to do this, as I see it, is for the PGP
program to make additional signature packets and put it in the signed
part of the signature.

If the OpenPGP protocol is not changed, there is no way for any PGP
application to implement any such convention. So it has to be a
part of the OpenPGP protocol.

> Repeat to yourself: IT IS A FEATURE THAT SIGN AND ENCRYPT ARE
> SEPARABLE OPERATIONS.  Once you make that statement, there is no way,
> short of layering violations, to do what you want to do except at the
> application later duplicating the information.

And I say it is a security flaw that that sign and encrypt must be
separable operations, and for the implementation of an atomic and secure
sign & encrypt you have to make an exception to this layering model.

-- 
Terje Bråten

To: Terje Braaten <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: secure sign & encrypt
From: Derek Atkins <[email-masked]>
Date: 23 May 2002 08:46:45 -0400
Lines: 49
Sender: [email-masked]

Terje Braaten <[email-masked]> writes:

> The problem is that even though sign & encrypt is not atomic
> now, that is what most users expect. I do not find it
> satisfying as a programmer to have to say to the users
> "Sorry, but the OpenPGP protocol do not allow any atomic
> sign & encrypt that would have solved your problem, so
> you will have to do without."

I disagree that all users are calmoring for this feature, but I
suppose we will have to agree to disagree on that.

> Adding a new signature packet called 'encrypted to' (or something
> like that) would allow OpenPGP applications to implement
> such an atomic sign & encrypt. It could say in the protocol
> that an application MAY implement atomic sign & encrypt,
> and if it does, it MUST do such and such.

Just so long as the user has to specifically specify this
functionality.  Note that this is a tradeoff and you LOSE a nice
feature of PGP in the process.  The feature that you lose is
repudiation of the recipient of a message.  You can honestly say to a
judge "I have no idea how he got that message -- I didn't encrypt it
to him".  Maybe you don't consider that a feature; some people do.

> My suggestion for a protocol for atomic sign & encrypt is
> that the application MUST make an 'encrypted to' packet in
> the signature for each key the message and signature packet
> is encrypted to in the encryption packet.
> These 'encrypted to' packets MUST be in the signed part of the signature.

As has already been suggested, the Notation packet can already do
this.  Just create an "encrypted-to" notation convention and publish
it as and RFC (and then convince people to implement it).  You do not
need any new packets to do what you want.

> An application that implement decrypt & verify MUST/SHOULD warn the user if
> the key used to decrypt the message is not found in an 'encrypted to'
> packet in the signature if the signature contains 'encrypted to'
> packets and thus indicates that the message is created by an atomic
> sign & encrypt.

-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

To: "Dominikus Scherkl" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: secure sign & encrypt
From: Derek Atkins <[email-masked]>
Date: 23 May 2002 08:37:55 -0400
Lines: 52
Sender: [email-masked]

The interesting thing is that there is nothing STOPPING an application
from doing this today.  OpenPGP messages like the following are
perfectly legal syntax, even in 2440:

ESK [...] Enc { PreSig ESK [...] Enc { Literal { Message } } PostSig }

Go ahead and implement this.  I'm fairly sure that most of the OpenPGP
Parsers out there will Do The Right Thing with this (I'm 99% sure that
PGP 6.5.x will do this, since I wrote that original parser code).

-derek

"Dominikus Scherkl" <[email-masked]> writes:

> Hi.
> 
> > Well, I intended it to become an atomic function.
> Nice. And how? Common public key cryptography doesn't provide
> algorithms to sign an encrypt in a single, undividable step.
> 
> I see no other way than "encrypt, sign and encrypt" (ESE)
> to archive all cyptografic goals which seems inportant to me:
> 
> Two goals require ES:
> - to ensure that the reciever cannot forward a message
>   without destroying the signature or reveiling that it was
>   originaly send to him for his eyes only we must sign after
>   encryption.
> - to convince the receiver he was the original target we 
>   also need to first encryt and than sign.
> 
> two further goals require SE:
> - to ensure the signature is not used for another message
>   we must first sign than encrypt (else especialy for RSA
>   there exist a choosen key attack).
> - to hide that you are sending signed messages you also need
>   to do encryption as the very last step.
> 
> The easiest way to archive all four is ESE, an it is worth
> the time cost of two encryptions, I think.
> 
> Best Regards.
> 
> -- 
> Dominikus Scherkl
> [email-masked]

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

To: Terje Braaten <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: secure sign & encrypt
From: Derek Atkins <[email-masked]>
Date: 23 May 2002 08:32:08 -0400
Lines: 46
Sender: [email-masked]

Terje Braaten <[email-masked]> writes:

> Alice makes a love poem, signs & encrypts it and sends it to Bob.
> Some months later they have broken up with each other. Bob decides
> to be mean to Alice, and encrypts the signed love poem and sends it
> to Charlie, faking the From header in the mail so it look likes it is
> from Alice. Then Charlie has a message that is encrypted to him and signed
> by Alice. It seems to Charlie like it is created by sign & encrypt in
> PGP, so he is convinced this must be a message from Alice that she
> has encrypted specially for him.

Note that this will already say:

Good signature from Alic.
Signature made <Date three months ago>

Don't you think Charlie would be suspicious about that?  I would
certainly be suspicious if the signature date wasn't pretty close
to the mail date.  And I would also be suspicious if the mail date
wasn't close to "today".

> What I would like is any PGP implementation to be able to display a message
> like "Good signature from nn. Warning, this message is not made with atomic
> sign & encrypt, and may be encrypted by some one else."

You see, I view this just like regular mail.  There is the envelope
information, and there is the "letter".  By _CONVENTION_ the person
writing a letter duplicates the envelope information on the inside.
This is not done automatically by the Postal Service, nor is it done
automatically by the enveloping process.  A user could just as easily
leave that information out of the letter (thereby opening themselves
to this same attack in meatspace).

This is not something that should be solved at the Protocol Layer.
Repeat to yourself: IT IS A FEATURE THAT SIGN AND ENCRYPT ARE
SEPARABLE OPERATIONS.  Once you make that statement, there is no way,
short of layering violations, to do what you want to do except at the
application later duplicating the information.

-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

From: Terje Braaten <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: RE: secure sign & encrypt
Date: Thu, 23 May 2002 14:22:19 +0200
Sender: [email-masked]

Matthew Byng-Maddick <[email-masked]> wrote:
> 
> As others have pointed out, what is the "atomic sign & 
> encrypt" of which you
> speak?

I envision that in a not too far feature, we can call the
sign & encrypt function in PGP an atomic sign & encrypt.
This is the solution of the problem that I have been trying
to describe all the time.

The problem is that even though sign & encrypt is not atomic
now, that is what most users expect. I do not find it
satisfying as a programmer to have to say to the users
"Sorry, but the OpenPGP protocol do not allow any atomic
sign & encrypt that would have solved your problem, so
you will have to do without."

Adding a new signature packet called 'encrypted to' (or something
like that) would allow OpenPGP applications to implement
such an atomic sign & encrypt. It could say in the protocol
that an application MAY implement atomic sign & encrypt,
and if it does, it MUST do such and such.

My suggestion for a protocol for atomic sign & encrypt is
that the application MUST make an 'encrypted to' packet in
the signature for each key the message and signature packet
is encrypted to in the encryption packet.
These 'encrypted to' packets MUST be in the signed part of the signature.

An application that implement decrypt & verify MUST/SHOULD warn the user if
the key used to decrypt the message is not found in an 'encrypted to'
packet in the signature if the signature contains 'encrypted to'
packets and thus indicates that the message is created by an atomic
sign & encrypt.

-- 
Terje Bråten

content-class: urn:content-classes:message
Subject: RE: secure sign & encrypt
Date: Thu, 23 May 2002 13:52:13 +0200
From: "Dominikus Scherkl" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Hi.

> Well, I intended it to become an atomic function.
Nice. And how? Common public key cryptography doesn't provide
algorithms to sign an encrypt in a single, undividable step.

I see no other way than "encrypt, sign and encrypt" (ESE)
to archive all cyptografic goals which seems inportant to me:

Two goals require ES:
- to ensure that the reciever cannot forward a message
  without destroying the signature or reveiling that it was
  originaly send to him for his eyes only we must sign after
  encryption.
- to convince the receiver he was the original target we 
  also need to first encryt and than sign.

two further goals require SE:
- to ensure the signature is not used for another message
  we must first sign than encrypt (else especialy for RSA
  there exist a choosen key attack).
- to hide that you are sending signed messages you also need
  to do encryption as the very last step.

The easiest way to archive all four is ESE, an it is worth
the time cost of two encryptions, I think.

Best Regards.

-- 
Dominikus Scherkl
[email-masked]

Date: Thu, 23 May 2002 11:10:37 +0100
From: Matthew Byng-Maddick <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: secure sign & encrypt
Organization: Colondot.net
Mail-Copies-To: never
Sender: [email-masked]

On Thu, May 23, 2002 at 11:00:15AM +0200, Terje Braaten wrote:
> What I would like is any PGP implementation to be able to display a message
> like "Good signature from nn. Warning, this message is not made with atomic
> sign & encrypt, and may be encrypted by some one else."

As others have pointed out, what is the "atomic sign & encrypt" of which you
speak?

MBM

-- 
Matthew Byng-Maddick         <[email-masked]>           http://colondot.net/

From: Terje Braaten <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: RE: secure sign & encrypt
Date: Thu, 23 May 2002 11:00:15 +0200
Sender: [email-masked]

Derek Atkins <[email-masked]> writes:
> 
> 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.

Well, I intended it to become an atomic function. Many users perceive it
today to be an atomic function, and I think it would be really nice
and a big improvement of the software if it really became a secure
atomic function.

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

That is what I see as a major weakness with PGP today. There should be
a difference, and the user should be able to be sure that the signer
and encrypter is the same person if atomic sign & encrypt is used.
It is both very user friendly to make it that way, and it will make
it more secure since it is a already a wide misconception that you
can tell the difference with the current implementation.

[snip]
> > 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.
> 
> What do you mean?  Can you please explain what attack you believe
> you are preventing?

Alice makes a love poem, signs & encrypts it and sends it to Bob.
Some months later they have broken up with each other. Bob decides
to be mean to Alice, and encrypts the signed love poem and sends it
to Charlie, faking the From header in the mail so it look likes it is
from Alice. Then Charlie has a message that is encrypted to him and signed
by Alice. It seems to Charlie like it is created by sign & encrypt in
PGP, so he is convinced this must be a message from Alice that she
has encrypted specially for him.

What I would like is any PGP implementation to be able to display a message
like "Good signature from nn. Warning, this message is not made with atomic
sign & encrypt, and may be encrypted by some one else."

-- 
Terje Bråten

Date: Thu, 23 May 2002 16:09:33 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: secure sign & encrypt
Cc: [email-masked]
Sender: [email-masked]

Derek Atkins <[email-masked]> writes:

>No, the best way around this problem is the USER INTERFACE and EDUCATION.

Jim Schaad posted a good analysis of this a while back.  It's attached below
for people who haven't seen it.

Peter.

-- Snip --

I was hoping that this issue was going to disappear if I ignored it.  I
feel that the problem listed, while potentially interesting, is not one
that can be solved via this type of mechanism.

The problem:  I get a message, signed, and I forward it to you signed
and then possibly encrypted.  You believe that since it was encrypted to
you that nobody else could have sent it but the signer.

Response:  1) A better answer is to put names in e-mail.  2) Am I
suppose to start doing this for all signed mail.  3) How do I convince a
large company like Microsoft that this is even an interesting problem
for them to "fix" in their mail.  4) This does not fix information leaks
in anyway. (A far more interesting problem in my estimation.)

Why this does not work:  I don't know how to begin to tell Microsoft how
to write this code.  The simple case is, if my mail box name is not on
the To/CC line then pop up a warning message.  But this is not an easy
thing to say and program in.

1. When I was working at Microsoft, people sent me mail at the address
"[email-masked]", my mailbox name was
"[email-masked]".  There is no way to determine that these
are or are not the same address.  While in this case they were they
could just have easily been different addresses.

2. Today, the email address that I give people is "[email-masked]",
but this is not the mail box address that I use.  This address forwards
mail to a second address where I down-load my mail from.  Now either the
message is always going to show up for me, or I have a configuration
issue to explain to users (and to write UI for).

3. If I receive e-mail because I am on a mailing list (such as this
mailing list), either I get the message for all mail to that list, or I
have a configureation issue to explain to users (and to write UI for).
This becomes even more fun if you look at nested mailing lists.  This
mailing list address could be contained on one or more other ietf
mailling lists thus I get mail indirectly and infrequently from some
other entity mailing list that I do not know that I am on.

4. BCC addressing causes massive problems.  Either the message always
comes up, I lose the concept of BCC because the address is included, or
a separate signature operation must be included for every BCC
recipeient.  (Does the BCC signature still have the list of all non-BCC
recipients?).  The process of generating addition signature operations
is not acceptable in my estimation, and would likely generate lots of
interesting problems with signed receipts.

5. What are the correct processing rules to deal with the following
situations:
- Nested signatures:  Does this element in an outer signature remove the
requirement for it to be checked on an inner signature?  Does it add or
change the behavior in some way?
- Parallel signature:  What does this mean for two different
side-by-side signatures, possible with different recipient lists?  If I
am on either list I don't need to display this warning?
- Nested Messages:  What happens if I bodily encapsulate an RFC822
message and forward it to you.  Do you check for the encapsulating but
not the embedded message?  Do you check the embedded message for the
from address of the encapsulating message?

I think that this is an interesting accademic problem, until I see a
real world need for a solution I think it should be ignored.

jim

To: Terje Braaten <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: secure sign & encrypt
From: Derek Atkins <[email-masked]>
Date: 22 May 2002 19:23:17 -0400
Lines: 41
Sender: [email-masked]

Terje Braaten <[email-masked]> writes:

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

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

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

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

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

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

From: Terje Braaten <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: RE: secure sign & encrypt
Date: Wed, 22 May 2002 21:46:21 +0200
Sender: [email-masked]

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

Date: Wed, 22 May 2002 12:09:47 -0700
Subject: Re: secure sign & encrypt
From: Jon Callas <[email-masked]>
To: Terje Braaten <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

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.

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.

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

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.
Just don't make me use it, thanks. I'll have even less reason to sign
things.

    Jon

From: Terje Braaten <[email-masked]>
To: "OpenPGP (E-mail)" <[email-masked]>
Subject: RE: secure sign & encrypt
Date: Wed, 22 May 2002 20:07:41 +0200
Sender: [email-masked]

> -----Original Message-----
> From: Hal Finney [mailto:[email-masked]]
> Sent: 22. May 2002 19:09
> To: [email-masked]; [email-masked]
> Subject: RE: secure sign & encrypt
> 
> 
> The problem is that this sign-and-encrypt issue is just the tip of
> the iceberg.  It is not worth redoing the protocol when there 
> are these
> other issues that will remain unresolved.

I disagree with this. The encryption of a message is much more
fundamentally linked to the signing of the same message, both in
practice and in peoples mind. Since we do have a function called
sign & encrypt in PGP, users will assume that it really is a secure
sign & encrypt, and that they can trust it to be one operation where
the signature and the encryption is linked.

Even more sophisticated users like f.ex. Vedaal on this list, seem to
think that already in PGP you can be sure that the signer is the same as
the encrypter if it appears that the message has been made by a PGP
sign & encrypt operation.

[snip]
> I read the paper and closely followed the extensive discussion on the
> cryptography list when this came out last year.  In my opinion the
> consensus among the professionals on that list was that, properly
> understood, there is more to this than a protocol flaw that can be
> easily patched.  It represents a fundamental property of 
> encrypted email.
> Some data is protected and some is not.

And I think we should make who the message is encrypted to a part
of what is protected, as long as PGP offers a function called sign &
encrypt.

> 
> The real solution is to put the entire email, headers and all, into
> the signed envelope, and then for the receiving software to compare
> the protected headers with those on the actual message.  This will
> detect substition of from/to lines as well as other changes, and will
> work for both signed and signed+encrypted messages.
> 
> We do have data structures to support this via PGP/MIME and the
> Message/rfc822 MIME type.  However actually implementing this
> functionality is difficult as it requires close integration with the
> email software.  In practice, probably only email software providers
> would be in a position to provide this level of functionality.

Yes, this is really an issue that should go into the PGP/MIME standard
as well, and there also protect important headers in the mail like
To, From, Cc, Date, etc.
But here we discuss the core OpenPGP standard, and since it includes
detailed specifications on how sign & encrypt is to be done,
this also should be fixed in this standard.

Also note that this problem is not specific to messages sent by e-mail,
but applies to all messages that is signed & encrypted and may not
naturally contain a To or From field.

-- 
Terje Bråten

Date: Wed, 22 May 2002 10:09:03 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: secure sign & encrypt
Sender: [email-masked]

The problem is that this sign-and-encrypt issue is just the tip of
the iceberg.  It is not worth redoing the protocol when there are these
other issues that will remain unresolved.

First, as mentioned before there is still the chance of confusion if a
clearsigned message is misdirected.  Most people will assume that if they
get an email from someone who PGP signed it, that the email was directed
towards them.  The PGP signature will add weight and authority to this
misconception.  Fixing the sign and encrypt problem won't help with this.

Second, there are other issues than sender/recipient which people
may assume implicitly are being protected by PGP.  This could include
message subject and possibly other header fields.  People will often
assume a certain context in interpreting a message based on this data.
If someone gets an email from their boss with the subject "Smithers
account" and the content tells them to "cancel the account immediately",
the subject line is crucially important in interpreting the message.
PGP does not protect this data, but users may not understand this.

I read the paper and closely followed the extensive discussion on the
cryptography list when this came out last year.  In my opinion the
consensus among the professionals on that list was that, properly
understood, there is more to this than a protocol flaw that can be
easily patched.  It represents a fundamental property of encrypted email.
Some data is protected and some is not.

The real solution is to put the entire email, headers and all, into
the signed envelope, and then for the receiving software to compare
the protected headers with those on the actual message.  This will
detect substition of from/to lines as well as other changes, and will
work for both signed and signed+encrypted messages.

We do have data structures to support this via PGP/MIME and the
Message/rfc822 MIME type.  However actually implementing this
functionality is difficult as it requires close integration with the
email software.  In practice, probably only email software providers
would be in a position to provide this level of functionality.

Hal

From: Terje Braaten <[email-masked]>
To: "OpenPGP (E-mail)" <[email-masked]>
Subject: RE: secure sign & encrypt
Date: Wed, 22 May 2002 18:10:34 +0200
Sender: [email-masked]

> -----Original Message-----
> From: Derek Atkins [mailto:[email-masked]]
> Sent: 22. May 2002 16:09
[...]
> No, the best way around this problem is the USER INTERFACE and
> EDUCATION.  If you receive a signed message that looks like:

I have to disagree with you there Derek. It is not possible to
write an user interface that automatically detects this problem if
there is no support for it in the protocol. It has to be specified
in the protocol that under a sign & encrypt operation the application
MUST make an 'encrypted to' packet in the signature for each key
the message and signature packet is encrypted to in the encryption packet.
These 'encrypted to' packets MUST be in the signed part of the signature.

An application that implement decrypt & verify MUST warn the user if
the key used to decrypt the message is not found in an 'encrypted to'
packet in the signature (if it is to be a good signature).

No matter how much you try to educate your users, I think that
yet for a few decades most people will think that when they receive
an email that is both signed and encrypted, most will assume that
they can be sure that the signer and the encrypter is the same person.
I think it will be a very great improvement in the protocol to make
it so that it really can be true.

-- 
Terje Bråten

From: Terje Braaten <[email-masked]>
To: "'vedaal'" <[email-masked]>, [email-masked]
Subject: RE: secure sign & encrypt
Date: Wed, 22 May 2002 16:22:34 +0200
Sender: [email-masked]

> -----Original Message-----
> From: vedaal [mailto:[email-masked]]
> Sent: 22. mai 2002 15:01
> To: [email-masked]
> Subject: Re: secure sign & encrypt

[...]
> I thought that a packet that simply records the elapsed time 
> in fractions of
> a second, between signing and encrypting,
> could be added without affecting the signature or encryption 
> packets, and
> might be easier to implement without affecting
> backward compatiblity.

If it is not signed (i.e. a signed signature packet) but only added
to the message on the outside, it is nothing that stops the attacker
from just faking that time packet.

> 
> [...]
> 
> > If it is not a signature packet, I do not understand what would
> > keep the attacker from making a fake timestamp when 
> re-encrypting the
> > message.
> 
> It would be an 'record of actual elapsed time' packet,  
> measured from the
> time the program calls for the time of signing,
> to the time it calls for encrypting.  It would not be 'calculated' by
> measuring the recorded (old) timestamp of the signature,
> and then re-setting the attacker's computer to the same time 
> and measuring
> the fractions of seconds till the encryption.

You say "It would not be 'calculated' by ...", but then you rely
on the attacker using a certain program or implementation of OpenPGP.
When designing a security protocol, we must assume that an attacker
will be able to use any program that he likes or even write his own
programs.
If it is permitted by the protocol, the attacker can do it, even
if it is not possible to do it using the usual implementations of the
protocol.

> 
> { i do not yet know how to read and write code :(  , so it is only my
> opinion of what seems plausibly 'do-able' ,
> it may be that it has flaws that experienced programmers can 
> instantly see,
> if so, i apologize in advance}

You are forgiven.

-- 
Terje Bråten

To: "vedaal" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: secure sign & encrypt
From: Derek Atkins <[email-masked]>
Date: 22 May 2002 10:09:17 -0400
Lines: 93
Sender: [email-masked]

How is the receiver supposed to know what the delta-t is?
How do you deal with different machines of different speeds?
What if the sender is a PalmPilot and the receiver is a Pentium-4 3GHz?
There is absolutely no consistency in the time.

Worse, an attacker who wants to re-send the message already knows what
the original delta-t is, and can add it to any new packets they
create.

Even putting a timestamp into the ESK to enforce "ESK time == Sig
Time" doesn't help you, because there is no way to verify the
timestamp on other ESKs (to see if they've been added).  All you know
is that "This message was encrypted by someone who was able to see the
original" (which could be the sender, or could be one of the
"original" receipients.

No, the best way around this problem is the USER INTERFACE and
EDUCATION.  If you receive a signed message that looks like:

  --- begin message ---
  To: peter, paul, mary
  Subject: Hi
  Date: <now>

  I QUIT!  Have a nice day!
  --- begin signature ---
  <stuff>
  --- end signature ---

(Or think of the same type of message but signed and encrypted)..

Notice how the original recipients are part of the signed message?  If
this gets forwarded to another person, they would know that they were
not an intended recipient.  You cannot change that without
invalidating the signature.

-derek

"vedaal" <[email-masked]> writes:

> ----- Original Message -----
> From: "Terje Braaten" <[email-masked]>
> To: "OpenPGP (E-mail)" <[email-masked]>
> Sent: Wednesday, May 22, 2002 6:51 AM
> Subject: RE: secure sign & encrypt
> 
> [...]
> > > If there could be a packet added linking the time of
> > > encryption to the time
> > > of signing,
> > > {including elapsed time in seconds [or 0.00x seconds], and
> > > therefore not
> > > attackable by trying to re-set the re-encrypting
> > > computer to the time recorded in the original signed message.}
> >
> > I do not understand how you intend this packet to be added.
> > If it is a signature packet, would not the changes to be done
> > be about the same as if we added an 'encrypted to' packet?
> 
> Yes,     it could be done your way too, with about the same amount of
> change.
> 
> I thought that a packet that simply records the elapsed time in fractions of
> a second, between signing and encrypting,
> could be added without affecting the signature or encryption packets, and
> might be easier to implement without affecting
> backward compatiblity.
> 
> [...]
> 
> > If it is not a signature packet, I do not understand what would
> > keep the attacker from making a fake timestamp when re-encrypting the
> > message.
> 
> It would be an 'record of actual elapsed time' packet,  measured from the
> time the program calls for the time of signing,
> to the time it calls for encrypting.  It would not be 'calculated' by
> measuring the recorded (old) timestamp of the signature,
> and then re-setting the attacker's computer to the same time and measuring
> the fractions of seconds till the encryption.
> 
> { i do not yet know how to read and write code :(  , so it is only my
> opinion of what seems plausibly 'do-able' ,
> it may be that it has flaws that experienced programmers can instantly see,
> if so, i apologize in advance}
> 
> --vedaal

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

From: "vedaal" <[email-masked]>
To: <[email-masked]>
Subject: Re: secure sign & encrypt
Date: Wed, 22 May 2002 09:00:32 -0400
Sender: [email-masked]

----- Original Message -----
From: "Terje Braaten" <[email-masked]>
To: "OpenPGP (E-mail)" <[email-masked]>
Sent: Wednesday, May 22, 2002 6:51 AM
Subject: RE: secure sign & encrypt

[...]
> > If there could be a packet added linking the time of
> > encryption to the time
> > of signing,
> > {including elapsed time in seconds [or 0.00x seconds], and
> > therefore not
> > attackable by trying to re-set the re-encrypting
> > computer to the time recorded in the original signed message.}
>
> I do not understand how you intend this packet to be added.
> If it is a signature packet, would not the changes to be done
> be about the same as if we added an 'encrypted to' packet?

Yes,     it could be done your way too, with about the same amount of
change.

I thought that a packet that simply records the elapsed time in fractions of
a second, between signing and encrypting,
could be added without affecting the signature or encryption packets, and
might be easier to implement without affecting
backward compatiblity.

[...]

> If it is not a signature packet, I do not understand what would
> keep the attacker from making a fake timestamp when re-encrypting the
> message.

It would be an 'record of actual elapsed time' packet,  measured from the
time the program calls for the time of signing,
to the time it calls for encrypting.  It would not be 'calculated' by
measuring the recorded (old) timestamp of the signature,
and then re-setting the attacker's computer to the same time and measuring
the fractions of seconds till the encryption.

{ i do not yet know how to read and write code :(  , so it is only my
opinion of what seems plausibly 'do-able' ,
it may be that it has flaws that experienced programmers can instantly see,
if so, i apologize in advance}

--vedaal

From: Terje Braaten <[email-masked]>
To: "OpenPGP (E-mail)" <[email-masked]>
Subject: RE: secure sign & encrypt
Date: Wed, 22 May 2002 12:51:36 +0200
Sender: [email-masked]

vedaal <[email-masked]> wrote:
> It seems that one thing that is definitely different in a 
> message that is
> sent as 'sign and encrypt',
> and one that is re-encrypting a signed message, is the time 
> in which it is
> being done.
> 
> An authentic 'sign and encrypt' message, has the signature 
> and encryption
> done within seconds of each other.
> 
> If there could be a packet added linking the time of 
> encryption to the time
> of signing,
> {including elapsed time in seconds [or 0.00x seconds], and 
> therefore not
> attackable by trying to re-set the re-encrypting
> computer to the time recorded in the original signed message.}

I do not understand how you intend this packet to be added.
If it is a signature packet, would not the changes to be done
be about the same as if we added an 'encrypted to' packet?
If it is not a signature packet, I do not understand what would
keep the attacker from making a fake timestamp when re-encrypting the
message.

>  and that packet tied to an MDC, it might serve as a means of 
> detection of
> re-encrypted signed messages.
> 
> It should be able to be done without affecting backward compatibility,
> and those using earlier implementations, could accomplish the 
> same thing (if
> really necessary), by using
> [encrypt, sign & encrypt].

This is also one of the solutions suggested in
http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html
to use encrypt, sign, encrypt instead of just sign & encrypt.
It is also possible to use sign, encrypt, sign.

But I think that adds an computational overhead when processing the
encryption/decryption that would be avoided by adding an extra packet
to the signature.

-- 
Terje Bråten

From: Terje Braaten <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: RE: secure sign & encrypt
Date: Wed, 22 May 2002 12:31:32 +0200
Sender: [email-masked]

Jon Callas <[email-masked]> wrote:
> It's important to understand what's in the envelope and what 
> is not in the
> envelope. The ESK is like the address on an envelope. It's not in the
> envelope. It's outside the envelope and is not protected.

That is a good picture of what is the problem. The solution I proposed
is to put a copy of the address(es) on the outside of the envelope also
inside the envelope. If what is on the outside do not match what is on
the inside the user should get a warning that the message is (most probably)
encrypted by some one else than the person that signed the message.

-- 
Terje Bråten

Date: Tue, 21 May 2002 11:31:50 -0700
Subject: Re: secure sign & encrypt
From: Jon Callas <[email-masked]>
To: vedaal <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On 5/21/2002 8:36 AM, "vedaal" <[email-masked]> wrote:

> Also, could the MDC be utilized to prevent such substitutions, by detecting
> alterations of any of the packets?

No. The MDC protects the contents of the symmetric encryption. It does not
protect the ESKs. Nothing protects them, beyond their own encryption.

It would be possible, for example, to make an SMTP server that took a PGP
message with several ESKs in one message, and explode that into N messages,
each with only one ESK. If such a thing existed, the receiver could not
detect it. 

As Derek mentioned, you could even put in utterly bogus MDCs. These could
never be detected as bogus unless you happened to have the key that opened
it.

There are a number of interesting "harrassment attacks" that you can do. For
example, let's suppose I run a server that's an intermediate between Alice
and Bob. I intercept a message Alice's message, and then add in an ESK
that's encrypted to the Lotus Notes/NSA key that Adam Back created into a
PGP key. This is utterly bogus -- I just made up some 128 bit number and
encrypted it to that key. But I insert it in the message and send it on to
Bob. If Bob concludes that Alice is CCing the NSA on messages, then that's a
not unreasonable conclusion to draw. I can just sit back and snicker.

It's important to understand what's in the envelope and what is not in the
envelope. The ESK is like the address on an envelope. It's not in the
envelope. It's outside the envelope and is not protected.

    Jon

From: "vedaal" <[email-masked]>
To: <[email-masked]>
Subject: Re: secure sign & encrypt
Date: Tue, 21 May 2002 14:20:45 -0400
Sender: [email-masked]

----- Original Message -----
From: "Derek Atkins" <[email-masked]>
To: "vedaal" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, May 21, 2002 12:23 PM
Subject: Re: secure sign & encrypt

> > Also, could the MDC be utilized to prevent such substitutions, by
detecting
> > alterations of any of the packets?
>
> No, because the MDC could be recreated as well.  The MDC is tied to K
> but has no signature associated with it to tie it to the actual
> sender.

It seems that one thing that is definitely different in a message that is
sent as 'sign and encrypt',
and one that is re-encrypting a signed message, is the time in which it is
being done.

An authentic 'sign and encrypt' message, has the signature and encryption
done within seconds of each other.

If there could be a packet added linking the time of encryption to the time
of signing,
{including elapsed time in seconds [or 0.00x seconds], and therefore not
attackable by trying to re-set the re-encrypting
computer to the time recorded in the original signed message.}
 and that packet tied to an MDC, it might serve as a means of detection of
re-encrypted signed messages.

It should be able to be done without affecting backward compatibility,
and those using earlier implementations, could accomplish the same thing (if
really necessary), by using
[encrypt, sign & encrypt].

--just a thought,

vedaal

To: "vedaal" <[email-masked]>
Cc: <[email-masked]>
From: Derek Atkins <[email-masked]>
Subject: Re: secure sign & encrypt
Date: 21 May 2002 12:23:14 -0400
Lines: 34
Sender: [email-masked]

"vedaal" <[email-masked]> writes:

> Wouldn't that cause a CRC error, indicating that the message was tampered
> with?
> Or could a new CRC be calculated and included in the new re-encrypted
> message?

Which CRC do you mean?  Do you mean the armor CRC?  That's re-created.
Internally, the signature and encryption are completely separable.  If
you sign a message (note: NOT clearsigning), you would get the same
internal structure as you get when you sign and encrypt a message.
The only difference is that in the latter, when you encrypt, you take
the output from the signature transform and encrypt it, rather than
sending it to a file (or to ascii armor).

> Also, could the MDC be utilized to prevent such substitutions, by detecting
> alterations of any of the packets?

No, because the MDC could be recreated as well.  The MDC is tied to K
but has no signature associated with it to tie it to the actual
sender.

> Thanks,
> 
> vedaal
> 
> {i don't know,  so am asking}

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

From: "vedaal" <[email-masked]>
To: <[email-masked]>
Subject: Re: secure sign & encrypt
Date: Tue, 21 May 2002 11:36:40 -0400
Sender: [email-masked]

----- Original Message -----
From: "Derek Atkins" <[email-masked]>
To: "vedaal" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, May 21, 2002 10:33 AM
Subject: Re: secure sign & encrypt

>
> sorry, vedaal, but you are incorrect.  With current OpenPGP is _IS_
> possible to strip off the encryption from a message and re-encrypt it
> to another user, keeping the signature intact.  In fact, back in the
> early 90's (and mid-90's when we were first designing the pre-OpenPGP
> packets), this was in fact a design goal!
>
> Remember that a signed/encrypted message looks like:
>
>         ESK{PubA, K} ... Enc{K, PreSig{Hash{M}}, Lit{M}, PostSig{Hash{M}}}
>
> Given this format, you can easily replace the K in ESK{} and Enc{}
> without destroying the Presig,Literal,PostSig packets.

Wouldn't that cause a CRC error, indicating that the message was tampered
with?
Or could a new CRC be calculated and included in the new re-encrypted
message?

Also, could the MDC be utilized to prevent such substitutions, by detecting
alterations of any of the packets?

Thanks,

vedaal

{i don't know,  so am asking}

To: "vedaal" <[email-masked]>
Cc: <[email-masked]>
From: Derek Atkins <[email-masked]>
Subject: Re: secure sign & encrypt
Date: 21 May 2002 10:33:31 -0400
Lines: 72
Sender: [email-masked]

sorry, vedaal, but you are incorrect.  With current OpenPGP is _IS_
possible to strip off the encryption from a message and re-encrypt it
to another user, keeping the signature intact.  In fact, back in the
early 90's (and mid-90's when we were first designing the pre-OpenPGP
packets), this was in fact a design goal!

Remember that a signed/encrypted message looks like:

        ESK{PubA, K} ... Enc{K, PreSig{Hash{M}}, Lit{M}, PostSig{Hash{M}}}

Given this format, you can easily replace the K in ESK{} and Enc{}
without destroying the Presig,Literal,PostSig packets.

Now, it may be that the current _implementations_ do not make it easy
for a user to do so, but that is an implementation detail, not a
protocol detail.  The protocol could allow you to do so.

-derek

"vedaal" <[email-masked]> writes:

> ----- Original Message -----
> From: "Terje Braaten" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, May 20, 2002 7:31 PM
> Subject: RE: secure sign & encrypt
> 
> [...]
> 
>  > The problem is that most users when they decrypt a message
> > that is signed, they will think they can be sure the signer
> > and the encrypter is the same person/entity.
> > It would be a major improvement in the OpenPGP specification
> > to allow applications to ensure that that really is the case.
> 
> [...]
> 
> Functionally, that is the case now in Open PGP.
> 
> Even though a signed and encrypted message can be separated into a
> verifiable free standing signed message, and then
> re-encrypted and sent on to someone else,
> it 'cannot' {afaik} be re-combined into a signed and encrypted message that
> appears the same as a de-novo signed and encrypted message.
> 
> The most that can be done with the separation and re-encryption, is to have
> a message, that upon decryption, is clearsigned,
> or armored signed, and even the armored signed message is clearly of a
> different form than a de novo armored signed message;
> {a de novo armored signed message always has the message block begin with
> the letters 'ow', the separated armored signed
> message never does}.
> 
> Someone receiving a re-encrypted separated signed message, can instantly
> tell upon decryption, that it was an 'intentionally'
> re-encrypted message, and not an original.
> 
> The only time that this could be a problem, is for very new users, who may
> inadvertently get into a habit of clearsigning and then encrypting, instead
> of using the one-function 'sign and encrypt' , and as soon as it is pointed
> out to them that it is simpler and easier to use 'sign and encrypt' single
> function, they will probably do so.
> 
> hth,
> 
> vedaal
> 

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

From: Terje Braaten <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: secure sign & encrypt
Date: Tue, 21 May 2002 16:28:16 +0200
Sender: [email-masked]

vedaal <[email-masked]> wrote:
> 
> ----- Original Message -----
> From: "Terje Braaten" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, May 20, 2002 7:31 PM
> Subject: RE: secure sign & encrypt
> 
> [...]
> 
>  > The problem is that most users when they decrypt a message
> > that is signed, they will think they can be sure the signer
> > and the encrypter is the same person/entity.
> > It would be a major improvement in the OpenPGP specification
> > to allow applications to ensure that that really is the case.
> 
> [...]
> 
> Functionally, that is the case now in Open PGP.

How can that be? Which functionality in Open PGP are you referring to?
Is it specified anywhere in the RFC?

> 
> Even though a signed and encrypted message can be separated into a
> verifiable free standing signed message, and then
> re-encrypted and sent on to someone else,
> it 'cannot' {afaik} be re-combined into a signed and 
> encrypted message that
> appears the same as a de-novo signed and encrypted message.
> 
> The most that can be done with the separation and 
> re-encryption, is to have
> a message, that upon decryption, is clearsigned,
> or armored signed, and even the armored signed message is clearly of a
> different form than a de novo armored signed message;
> {a de novo armored signed message always has the message 
> block begin with
> the letters 'ow', the separated armored signed
> message never does}.
> 
> Someone receiving a re-encrypted separated signed message, 
> can instantly
> tell upon decryption, that it was an 'intentionally'
> re-encrypted message, and not an original.

If the attacker only an ordinary user, that might be the case.
But if who the message is supposed to be encrypted to is not signed
when the signature is added, it is only a matter of being a good programmer
to fake a "signed & encrypted" message, given the Open PGP standard
as it is today.

We should not rely on security through obscurity.

-- 
Terje Bråten

From: "vedaal" <[email-masked]>
To: <[email-masked]>
Subject: Re: secure sign & encrypt
Date: Tue, 21 May 2002 08:56:03 -0400
Sender: [email-masked]

----- Original Message -----
From: "Terje Braaten" <[email-masked]>
To: <[email-masked]>
Sent: Monday, May 20, 2002 7:31 PM
Subject: RE: secure sign & encrypt

[...]

 > The problem is that most users when they decrypt a message
> that is signed, they will think they can be sure the signer
> and the encrypter is the same person/entity.
> It would be a major improvement in the OpenPGP specification
> to allow applications to ensure that that really is the case.

[...]

Functionally, that is the case now in Open PGP.

Even though a signed and encrypted message can be separated into a
verifiable free standing signed message, and then
re-encrypted and sent on to someone else,
it 'cannot' {afaik} be re-combined into a signed and encrypted message that
appears the same as a de-novo signed and encrypted message.

The most that can be done with the separation and re-encryption, is to have
a message, that upon decryption, is clearsigned,
or armored signed, and even the armored signed message is clearly of a
different form than a de novo armored signed message;
{a de novo armored signed message always has the message block begin with
the letters 'ow', the separated armored signed
message never does}.

Someone receiving a re-encrypted separated signed message, can instantly
tell upon decryption, that it was an 'intentionally'
re-encrypted message, and not an original.

The only time that this could be a problem, is for very new users, who may
inadvertently get into a habit of clearsigning and then encrypting, instead
of using the one-function 'sign and encrypt' , and as soon as it is pointed
out to them that it is simpler and easier to use 'sign and encrypt' single
function, they will probably do so.

hth,

vedaal

From: Terje Braaten <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: secure sign & encrypt
Date: Tue, 21 May 2002 01:31:47 +0200
Sender: [email-masked]

Well, it is not only to add a new packet, but also add to
the user programs a check that if the packet is present in
the signature, the signature block should come from
decrypting a message with one the expected keys.

Clear signed messages should pose no user problems, because
the users generally understands that such the cryptographic
software will not give any confirmation of the origin of the
message.

The problem is that most users when they decrypt a message
that is signed, they will think they can be sure the signer
and the encrypter is the same person/entity.
It would be a major improvement in the OpenPGP specification
to allow applications to ensure that that really is the case.

Have you read the link
http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html

I really think it addresses a real problem.

-- 
Terje Bråten

-----Original Message-----
From: Hal Finney [mailto:[email-masked]]
Sent: 21. mai 2002 00:12
To: [email-masked]; [email-masked]
Subject: Re: secure sign & encrypt

There was quite a bit of discussion about this last year on the
cryptography mailing list.  I thought Jon Callas' message was good,
pointing out the wider ramifications of this kind of "failure":
http://www.mit.edu:8008/bloom-picayune/crypto/8891.

It is really not clear that solving it is as simple as adding a new
packet.  There are still other ways that things can go wrong, such
as simply redirecting a clear-signed message.  The fundamental problem
is that people don't understand what is protected and what isn't in
a signed mail message.

Hal

Date: Mon, 20 May 2002 15:12:26 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: secure sign & encrypt
Sender: [email-masked]

There was quite a bit of discussion about this last year on the
cryptography mailing list.  I thought Jon Callas' message was good,
pointing out the wider ramifications of this kind of "failure":
http://www.mit.edu:8008/bloom-picayune/crypto/8891.

It is really not clear that solving it is as simple as adding a new
packet.  There are still other ways that things can go wrong, such
as simply redirecting a clear-signed message.  The fundamental problem
is that people don't understand what is protected and what isn't in
a signed mail message.

Hal

From: Terje Braaten <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: secure sign & encrypt
Date: Mon, 20 May 2002 22:27:03 +0200
Sender: [email-masked]

Hi

Take a look at:
http://lists.gnupg.org/pipermail/gnupg-devel/2002-May/007159.html

Have you considered what Adrian writes about here in this forum?
I think it is a very good solution to add a 'intended encryption key' or
somthing like that in the section
5.2.3.1. Signature Subpacket Specification.

-- 
Terje Bråten

Date: Mon, 13 May 2002 20:53:09 -0700
Subject: Re: Dash-escaping clarification
From: Jon Callas <[email-masked]>
To: David Shaw <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On 5/13/2002 7:43 PM, "David Shaw" <[email-masked]> wrote:

> Nothing in the draft seems to discourage dash-escaping more than just
> the lines beginning with a dash.  Still, I am concerned with the
> receiving side not knowing that these other lines may be escaped as
> well (they may match on a dash-space-dash at the beginning of the
> line, rather than dash-space).  A sentence saying something like "Any
> other line MAY be dash-escaped as well at the discretion of the
> sender" would be very helpful here.

It's fine with me.

    Jon

Date: Mon, 13 May 2002 22:43:30 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Dash-escaping clarification
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Hi,

Section 7.1 (Dash-Escaped Text) of 2440bis05 says, in part, that
dash-escaped text is "the ordinary cleartext where every line starting
with a dash '-' (0x2D) is prefixed by the sequence dash '-' (0x2D) and
space ' ' (0x20)."

Since the most common use of dash-escaped text is in email, both PGP
and GnuPG (by default) also dash-escape lines starting with the word
"From " (with the space).  This is for the usual mbox-inspired
reasons.  If the "From " line isn't escaped, then some downstream mail
system may escape it, thus breaking the signature.

Nothing in the draft seems to discourage dash-escaping more than just
the lines beginning with a dash.  Still, I am concerned with the
receiving side not knowing that these other lines may be escaped as
well (they may match on a dash-space-dash at the beginning of the
line, rather than dash-space).  A sentence saying something like "Any
other line MAY be dash-escaped as well at the discretion of the
sender" would be very helpful here.

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

Sensitivity: 
Subject: Re: How do I do this with OpenPGP?
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Date: Wed, 8 May 2002 10:08:43 -0500
Sender: [email-masked]

From: John Dlugosz

Thanks again, Hal, the light is beining to dawn.

>> It's a somewhat complicated concept and not usually very useful outside
of relatively closed systems.

I'm working on a closed system.  What you describe is pretty much what I'm
doing.

Basically, instead of just "this is Bob" chaining down the trust, with the
assumption that everyone in that chain of trust is within the organization,
I can verify that everything in the chain back to Trent has the trust
signature packet too, meaning that this link is not just some random
employee but someone empowered to say "this is Bob".  Is that right?

So, if I understand right, Trent will put the trust signature subpacket
onto his certification of his vice-trents.  There might be several layers
here, and finally the supervisors who have face-to-face contact with
someone can sign the UserID, but can't further delegate their signing
authority.  The "level" (depth) lets me do that, and the "amount" isn't
useful for my purpose.

--John

Date: Tue, 7 May 2002 15:13:13 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: How do I do this with OpenPGP?
Cc: [email-masked]
Sender: [email-masked]

> From: John Dlugosz
>
> Thanks, Hal.
>
> Is Trent's signature on the key itself or on a UserID?
>
> It seems that either has semantic implications, but what do existing
> general-purpose tools do?  I like the latter for my application.

Normally it is on a userid.  It is binding the given name to the key,
that is, the signature is asserting its belief that the name belongs
to the key and vice versa.

> What's the relationship between the "Trust signature" key subpacket, and
> using key types 0x11-0x13?

The trust signature subpacket is used for the signer to publicly declare
that he trusts the key being signed as a signing key.  Normally a
signature just means that the signer is asserting that the name belongs
with the key, and that's what the signature types 0x11-0x13 are for.

Trust signatures are used to enable what we call "meta introducers"
which are signers who are empowered to declare that other keys have
key-signing authority.  For example, in a corporate application the chief
security officer may be declared to be a meta-introducer by the employees,
and he can then delegate signing authority to departmental officers.

It's a somewhat complicated concept and not usually very useful outside
of relatively closed systems.

Hal

Sensitivity: 
Subject: Re: How do I do this with OpenPGP?
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Date: Tue, 7 May 2002 17:16:26 -0500
Sender: [email-masked]

From: John Dlugosz

Thanks, Hal.

Is Trent's signature on the key itself or on a UserID?

It seems that either has semantic implications, but what do existing
general-purpose tools do?  I like the latter for my application.

What's the relationship between the "Trust signature" key subpacket, and
using key types 0x11-0x13?

--John

"Hal Finney" <[email-masked]> on 05-07-2002 04:56:25 PM

To:    [email-masked], [email-masked]
cc:
Subject:    Re: How do I do this with OpenPGP?

You should use the signature expiration time subpacket, in Trent's
signature on the key.

Hal

> From: John Dlugosz
>
> One of the nice things about OpenPGP is that multiple signatories are
> possible on a key, each "meaning" something.  Basically, it trent signs a
> key, it's OK with me for (purpose A), and the fact that Carl signed it
too
> for some other purpose is beside the point.
>
> But, I want Trent to be able to certify a key for a certain time period.
> Tag 2, type 0x10-0x13 doesn't contain a date.  I suppose there's a more
> complicated way to do this, though?  type 0x1F says "...for statements
that
> non-self certifiers want to make about the key itself" so maybe something
> in there?  Or certifing one of the (time range) subkeys instead of the
main
> key?
> Anyone?

Date: Tue, 7 May 2002 18:09:42 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: How do I do this with OpenPGP?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Tue, May 07, 2002 at 04:29:53PM -0500, [email-masked] wrote:
> 
> From: John Dlugosz
> 
> One of the nice things about OpenPGP is that multiple signatories are
> possible on a key, each "meaning" something.  Basically, it trent signs a
> key, it's OK with me for (purpose A), and the fact that Carl signed it too
> for some other purpose is beside the point.
> 
> But, I want Trent to be able to certify a key for a certain time period.
> Tag 2, type 0x10-0x13 doesn't contain a date.  I suppose there's a more
> complicated way to do this, though?  type 0x1F says "...for statements that
> non-self certifiers want to make about the key itself" so maybe something
> in there?  Or certifing one of the (time range) subkeys instead of the main
> key?

I think you are looking for section 5.2.3.10: Signature expiration
time.  Or if the key belongs to Trent's and he wants to make the whole
key go away after a while, then section 5.2.3.6: Key expiration time.

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

Date: Tue, 7 May 2002 14:56:25 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: How do I do this with OpenPGP?
Sender: [email-masked]

You should use the signature expiration time subpacket, in Trent's
signature on the key.

Hal

> From: John Dlugosz
>
> One of the nice things about OpenPGP is that multiple signatories are
> possible on a key, each "meaning" something.  Basically, it trent signs a
> key, it's OK with me for (purpose A), and the fact that Carl signed it too
> for some other purpose is beside the point.
>
> But, I want Trent to be able to certify a key for a certain time period.
> Tag 2, type 0x10-0x13 doesn't contain a date.  I suppose there's a more
> complicated way to do this, though?  type 0x1F says "...for statements that
> non-self certifiers want to make about the key itself" so maybe something
> in there?  Or certifing one of the (time range) subkeys instead of the main
> key?
>
> Anyone?

Sensitivity: 
Subject: How do I do this with OpenPGP?
To: [email-masked]
From: [email-masked]
Date: Tue, 7 May 2002 16:29:53 -0500
Sender: [email-masked]

From: John Dlugosz

One of the nice things about OpenPGP is that multiple signatories are
possible on a key, each "meaning" something.  Basically, it trent signs a
key, it's OK with me for (purpose A), and the fact that Carl signed it too
for some other purpose is beside the point.

But, I want Trent to be able to certify a key for a certain time period.
Tag 2, type 0x10-0x13 doesn't contain a date.  I suppose there's a more
complicated way to do this, though?  type 0x1F says "...for statements that
non-self certifiers want to make about the key itself" so maybe something
in there?  Or certifing one of the (time range) subkeys instead of the main
key?

Anyone?

--John

Date: Fri, 3 May 2002 09:50:20 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: common modulus attack on RSA
Sender: [email-masked]

We already have a note relevant to this in section 5.1:

   Note that when an implementation forms several PKESKs with one
   session key, forming a message that can be decrypted by several keys,
   the implementation MUST make new PKCS-1 padding for each key.

This will ensure that the "m" value is different for each encryption key.
That will thwart the common modulus attack and some other possible
attacks.

Hal Finney

> From: John Dlugosz
>
> In "Applied Cryptography", page 472, Schneier warns against ever encrypting
> the same plaintext with two keys having the same n (but different e).
>
> Different public keys may indeed have a common n, either by chance, because
> of an implementation that reuses a small set of n, or a deliberate attack.
>
> The session key is encrypted to multiple public keys.
>
> Looking at section 5.1 of RFC2440, it appears that only the MPI of the
> RSA-encrypted value of m is used.  I'm supposing that m is much smaller
> than n, so the whole thing takes one "block" through RSA.
>
> The other values put into m (the algorithm and the  checksum) are the same,
> too, so m will be identical in every public-key encrypted session key
> packet.

To: [email-masked]
Cc: [email-masked]
Subject: Re: common modulus attack on RSA
From: Derek Atkins <[email-masked]>
Date: 03 May 2002 11:19:25 -0400
Lines: 51
Sender: [email-masked]

You do realize that the liklihood of using the same 'N' is near zero.
If you and I choose the same N, that means that we can effectively
decrypt each others' messages.

Also, the 'm' being encrypted has random padding, and that random
padding should be unique per key.  In other words, 'm' _should_ be
different for each key anyways.

-derek

[email-masked] writes:

> From: John Dlugosz
> 
> In "Applied Cryptography", page 472, Schneier warns against ever encrypting
> the same plaintext with two keys having the same n (but different e).
> 
> Different public keys may indeed have a common n, either by chance, because
> of an implementation that reuses a small set of n, or a deliberate attack.
> 
> The session key is encrypted to multiple public keys.
> 
> Looking at section 5.1 of RFC2440, it appears that only the MPI of the
> RSA-encrypted value of m is used.  I'm supposing that m is much smaller
> than n, so the whole thing takes one "block" through RSA.
> 
> The other values put into m (the algorithm and the  checksum) are the same,
> too, so m will be identical in every public-key encrypted session key
> packet.
> 
> Perhaps the new draft should note that an implementation could warn about
> multiple recipients with the same n.  Remember, this could be done by
> other-than-chance, such as deliberatly introducing them as an attack.
> Better yet, I'd be happier if another number, chosen by the encryptor, were
> prepended to the session key, different for each recipient (e.g. a simple
> counter).
> 
> Is the note that a new PKCS-1 padding be made doing exactly this?  If so,
> does that add a unique value to the =end= (what I normally think of as
> padding), or does it pre-pend anything, too?  If so, is it guaranteed that
> the length of the final m is shorter than n?
> 
> --John
> 
> 

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

Subject: common modulus attack on RSA
To: [email-masked]
From: [email-masked]
Date: Fri, 3 May 2002 09:58:51 -0500
Sender: [email-masked]

From: John Dlugosz

In "Applied Cryptography", page 472, Schneier warns against ever encrypting
the same plaintext with two keys having the same n (but different e).

Different public keys may indeed have a common n, either by chance, because
of an implementation that reuses a small set of n, or a deliberate attack.

The session key is encrypted to multiple public keys.

Looking at section 5.1 of RFC2440, it appears that only the MPI of the
RSA-encrypted value of m is used.  I'm supposing that m is much smaller
than n, so the whole thing takes one "block" through RSA.

The other values put into m (the algorithm and the  checksum) are the same,
too, so m will be identical in every public-key encrypted session key
packet.

Perhaps the new draft should note that an implementation could warn about
multiple recipients with the same n.  Remember, this could be done by
other-than-chance, such as deliberatly introducing them as an attack.
Better yet, I'd be happier if another number, chosen by the encryptor, were
prepended to the session key, different for each recipient (e.g. a simple
counter).

Is the note that a new PKCS-1 padding be made doing exactly this?  If so,
does that add a unique value to the =end= (what I normally think of as
padding), or does it pre-pend anything, too?  If so, is it guaranteed that
the length of the final m is shorter than n?

--John

Date: Fri, 03 May 2002 09:37:39 +0200
From: Marc Mutz <[email-masked]>
Subject: Re: Clearsigned messages and MIME
To: Florian Weimer <[email-masked]>
Cc: [email-masked]
Organization: KDE
Content-description: clearsigned data
Sender: [email-masked]

On Thursday 02 May 2002 22:12, Florian Weimer wrote:
<snip>
> > I think most implementations will only recognize clearsigning on
> > text/plain body parts.  Probably other text subtypes, too.
>
> Already with some ISO 8859 variants, text might look light random
> binary garbage to the casual reader. ;-)

No charset I know of contains NULs. Most of them use CRLF as canonical line 
ends. That's what separates 8bit text from binary data. That even goes so far 
as to require two QP {en,de}coders for the two.

Marc

- -- 
Marc Mutz <[email-masked]>

To: Marc Mutz <[email-masked]>
Cc: [email-masked]
Subject: Re: Clearsigned messages and MIME
From: Florian Weimer <[email-masked]>
Date: Thu, 02 May 2002 22:12:13 +0200
Lines: 33
Sender: [email-masked]

Marc Mutz <[email-masked]> writes:

> On Wednesday 01 May 2002 12:35, Florian Weimer wrote:
>> How does one implement it correctly?  Add the signatures after
>> generating the actual octet stream, and then apply a suitable
>> Content-Transfer-Encoding afterwards?
>
> octet-stream? Do you want to clearsign binary data?

Sort of, yes.

> I think most implementations will only recognize clearsigning on
> text/plain body parts.  Probably other text subtypes, too.

Already with some ISO 8859 variants, text might look light random
binary garbage to the casual reader. ;-)

> For text, this is what KMail does:
> - apply charset encoding to obtain 8bit text

This results in an octet stream (in contrast to a sequence of
characters).

> - clearsign with --textmode
> - put the result into a text/lpain body part
> - apply CTE, if any.

I see.  Gnus will do the same, in the future.

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Date: Thu, 02 May 2002 14:15:16 +0200
From: Marc Mutz <[email-masked]>
Subject: Re: Clearsigned messages and MIME
To: Florian Weimer <[email-masked]>, [email-masked]
Organization: KDE
Content-description: clearsigned data
Sender: [email-masked]

On Wednesday 01 May 2002 12:35, Florian Weimer wrote:
> How does one implement it correctly?  Add the signatures after
> generating the actual octet stream, and then apply a suitable
> Content-Transfer-Encoding afterwards?

octet-stream? Do you want to clearsign binary data? I think most 
implementations will only recognize clearsigning on text/plain body parts. 
Probably other text subtypes, too.

For text, this is what KMail does:
- - apply charset encoding to obtain 8bit text
- - clearsign with --textmode
- - put the result into a text/lpain body part
- - apply CTE, if any.

Marc

- -- 
Marc Mutz <[email-masked]>

Date: Wed, 1 May 2002 17:38:06 +0200
From: Thomas Roessler <[email-masked]>
To: Florian Weimer <[email-masked]>
Cc: [email-masked]
Subject: Re: Clearsigned messages and MIME
Mail-Followup-To: Florian Weimer <[email-masked]>, [email-masked]
Sender: [email-masked]

On 2002-05-01 12:35:56 +0200, Florian Weimer wrote:

>How does one implement it correctly?  Add the signatures after 
>generating the actual octet stream, and then apply a suitable 
>Content-Transfer-Encoding afterwards?

That's how I'd do it.

-- 
Thomas Roessler                        <[email-masked]>

To: [email-masked]
Subject: Clearsigned messages and MIME
From: Florian Weimer <[email-masked]>
Date: Wed, 01 May 2002 12:35:56 +0200
Lines: 8
Sender: [email-masked]

How does one implement it correctly?  Add the signatures after
generating the actual octet stream, and then apply a suitable
Content-Transfer-Encoding afterwards?

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898