Am Mittwoch, den 16.03.2005, 16:19 -0500 schrieb Eric Burger:
Note that I *chose* to trust the server FOR THIS MESSAGE ONLY. That is why
we asked the question about split implementations. It would be VERY BAD if
we had to trust the server with our private key.
I like the selectivity and it appears that, given current PGP/MIME
practice, your suggestion is the best one can do.
I'd like to suggest something in addition to that: Allow for
*replacement* of the session-key packet, instead of decryption. Here's
how it would work:
The client receives the encrypted session key from the server, decrypts
it, *immediately recrypts* using the recipients public key and passes
the encrypted session-key back to the server. The server then proceeds
to *replace* the encrypted session key in the message (without ever
decrypting it!) and forwards it to the intended recipient. Because the
session key stays the same, the recipient can decrypt it.
When used with separately encrypted attachments, it would enable
forwarding something without ever downloading it, and without the server
ever seeing the decrypted content. This wouldn't be terribly useful
right now, because all clients encrypt the whole message and I would
have trouble making a forwarding decision without looking at the
content, but when a client ever implements a different PGP/MIME usage,
the combination would be terrific, in my very humble opinion.
There's one possible gotcha: I don't know about the security
implications of encrypting the same plaintext (here, the session key)
with two different public keys. I can't think of any problems right
now, but wouldn't exclude the possibility of a leak to occur. I hope
there's enough cryptographers here to shout in that event, though :)
Ingo
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil