secure sign & encrypt

[Adrian 'Dagurashibanipal' von Bidder]

On Thu, 2002-05-23 at 11:59, Jukka Holappa wrote:

> | You receive an encrypted + signed message. What do you know now?
> |
> | You trust the signature. Do you trust that nobody has read the message
> | in passing?
> |
> 
> I'm sorry to get in the middle of this, but you really can't know that
> with all the signatures you put in it.
> 
> Maybe someone read the message over the shoulder before it was
> signed+encrypted(+signed) or whatever.
> 
> You just have to trust a person to encrypt before anyone sees the
> message. If he/she fails to do this, there's no secret message in it any
> more.

I trust that if a person is encrypting a message to me, this person will
also be certain that the message is handled confidentially until it is
encrypted.

The problem with the attack I'm arguing about is that the message was
*not* encrypted in the first place, but that the recipient receives it
as an encrypted message and thus might put a meaning to a message that
was not intended by the sender.

With current openPGP encryption, encryption is only useful for the
sender (he knows that the message sent is encrypted and will not be read
by anybody other than the intended recipient. Of course he trusts the
recipient not to do the wrong thing with the information). 

Encryption is *not* useful for the recipient - he must not put any
special meaning to the fact that a message was encrypted.

BUT encryption COULD be useful for the recipient, if it was made clear
that the message was sent encrypted in the first place. Of course the
recipient still needs to trust the sender/signer of the message to have
handled the contained information confidentially.


In the end it all boils down that people (or, at least I) automatically
put different meanings to a message, depending on the source of the
message. A message in the newspaper is read differently than the same
message in a letter. In the same way, an unencrypted e-mail message may
be interpreted differently from the same message that comes encrypted -
it tells something about the sender's intention.



Concerning RFC compliance:
from rfc2440, section 5.2.3.1:
======
     An implementation SHOULD ignore any subpacket of a type that it
     does not recognize.
======

So, adding a hashed subpacket with a subpacket type of, say, 110
(explicitely reserved for private use) for the purpose of announcing the
'intended encryption key' on signed+encrypted messages is fully within
the scope of the rfc and SHOULD not break any openPGP compliant
implementations.

Displaying extra warnings on decrypting messages without this special
subpacket should of course not be the default while this is not in
widespread use. Displaying extra warnings in case there is a mismatch
between the intended and the real encryption key can probably safely be
enabled per default.

Also - although I'm in no way involved with writing RFCs - the RFC
documents have been known to be revised and extended from time to time.


Huk
-- vbi



-- 
secure email with gpg            avbidder at fortytwo.ch: key id 0x92082481
                                 avbidder at acter.ch:    key id 0x5E4B731F

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : /pipermail/attachments/20020523/e3c9172d/attachment.bin