From: John Dlugosz
I'm not quite that extreme, but I don't sign anything that I wouldn't
sign
if it were on paper, not on bits.
I'm a bit more mellow. When talking to someone on the phone, you can
authenticate who you are talking to, from the voice. In hand-written
letters, you can see the handwriting. Electronic text has =no=
personalization to it, so the signature takes the place.
OpenPGP specifies that the signature goes inside the envelope. The
reason
I understand the reasons why encrypt-then-sign is better. But I think it
could be even better yet. Mathematically combining the two operations into
one, or, to reuse existing primitives, jump through hoops. For example,
take a nonce and logically append both half its plaintext and ciphertext to
the original plaintext that will be signed. Now, you can't verify the
signature without also being able to verify that the included nonce
decrypts, as well.
Hmm, a simpler way would be to use a keyed hash to make the digest, with
the key encrypted "to" the recipient. Yea, I like that. Let me further
refine... A subpacket contains the HMAC key and a block of random numbers
the same size as the hash (e.g. 160 bits), encrypted to the recipient. The
recipient decrypts the key, repeats the hash, and then XOR's in the random
number. The result is sent to the basic signature algorithm. Now, if he
chooses to reveal the contents of this inner packet without providing the
means to decrypt it himself, then it's trivial to forge because you can
adjust the random number to make the hash match that of a tampered message.
Result, you can't verify the signature without being able to decode the
inner envelope. The inner envelope is signed by itself, and would contain
a plain hash of the main message, to tie it together.
Jon Callas <jon(_at_)callas(_dot_)org> on 04-09-2002 04:27:04 PM
To: john(_dot_)dlugosz(_at_)kodak(_dot_)com, mutz(_at_)kde(_dot_)org
cc: kmail(_at_)kde(_dot_)org, ietf-822(_at_)imc(_dot_)org,
ietf-openpgp(_at_)imc(_dot_)org
Subject: Re: Bug#40394: forwarding an encrypted PGP message is useless
At 3:33 PM -0500 4/9/02, john(_dot_)dlugosz(_at_)kodak(_dot_)com wrote:
But I think PGP uses "sign, then encrypt" which means software could
decrypt but leave the signature intact. As I recall, this was thought to
be a non-problem with respect to re-targeting, because you can put the
recipient's name in the message at the application level. e.g. "Dear
Sue,"
is part of the message, so it can't be mistaken as a message to Joan. But
that doesn't handle the issue of private information in the message. It's
possible for Sue to reveal the signed message to someone else, who can
verify the signature, without needing Sue's key. I would prefer if that
were impossible--without Sue's key, the message can't be authenticated
either.
OpenPGP specifies that the signature goes inside the envelope. The reason
for this is that if the signature is outside the envelope, then the
attacker knows both the source and destination of the message. In short, it
provides cryptographically enhanced traffic analysis.
Yes, you're right, someone can decrypt a signed message and then send on
the signed, decrypted message. They can also take a screenshot of the
screen and send the image on to someone else. I know many people who do not
sign messages for this very reason. We added a non-signature integrity
check to OpenPGP messages so you'd have some way of knowing you got the
message intact without requiring the sender to sign it.
There are security risks to signing messages. A good friend of mine is of
the opinion that you should never sign anything that you aren't willing to
forward on to City Hall for inclusion in the public record. He never signed
anyone ele's key for this reason, let alone a message. I'll add that this
guy was an VP at an investment bank, not a cypherpunk with outlaw
fantasies.
I'm not quite that extreme, but I don't sign anything that I wouldn't sign
if it were on paper, not on bits.
Mathematics cannot solve real-world security problems. If you're confessing
secrets to someone who gossips, you have security problems. If you send
signed, encrypted messages to someone who will decrypt them and send them
(or send a screenshot of your messagae) on, then you have the same security
problem.
A trusted channel to an untrustworthy person is not secure. And to
paraphrase Laotse, you cannot create trust with cryptography, no matter how
much cryptography you use.
Jon