Subject: RE: Split Implementations of PGP

From: Eric Burger <[email-masked]>
Date: Wed, 16 Mar 2005 16:19:17 -0500

Forward without download: I've got a 100MB document and a piece of text
saying, "here is the very important document you need to send to foo".  I
*chose* to trust the server, this time, to decrypt the message for me and
tell me the body structure (a big document and a piece of text).  I download
the text, and I decide to forward the document.  I tell the server to do the
forwarding for me on my behalf.

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.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Ingo Luetkebohle
> Sent: Wednesday, March 16, 2005 8:14 AM
> To: Jon Callas
> Cc: OpenPGP
> Subject: Re: Split Implementations of PGP
> 
> 
> 
> Am Mittwoch, den 16.03.2005, 01:46 -0800 schrieb Jon Callas:
> > Something that would help those of us doing crypto and IMAP 
> would be 
> > for IMAP to be less fussy about message size.
> 
> [...]
> 
> It would be very usefull, for me at least, if you could re-state your
> use-case here.  I'm getting the impression that I'm missing something
> fundamental.
> 
> I'm always reading about server-side decryption.  Some people seem to
> see it as a solution for the "one big chunk of ciphertext" 
> problem.  I'm
> not sure what else it would be good for.
> 
> For me, server-side decryption is a nightmare.  Pure and evil.  
> 
> It conflicts with my beliefs about how an end-to-end crypto solution
> should work.  Its not a solution, its a kludge and I'd much rather
> address the *real* problem.
> 
> The server is completely untrusted.  Much too much of my personal data
> is on other's servers already.  Organizations or people, who 
> might have
> different priorities in protecting it than I have.   Thats why I use
> end-to-end encryption when it matters.
> 
> If people say, adressing the real problem would require 
> influencing the
> senders behaviour, and we can't do that, and so we need a work-around
> now -- fine.  I can understand that.  But still, shouldn't that prompt
> us to think about wether we *need* to be able to influence the senders
> behaviour in more ways than we can now?
> 
> 
> P.S. Regarding IMAP and message sizes:  If I get an encrypted message,
> the size of the attachment *is* the message size.  That decryption
> yields a different size doesn't matter because it occurs on 
> the client,
> after download.
> 
> Regards
> 
> -- 
> "There is no limit to what a man can do or how far he can go if he
> doesn't mind who gets the credit." - Robert Woodruff
>

---

From: Ingo Luetkebohle <[email-masked]>
Date: Thu, 17 Mar 2005 00:42:20 +0100

> 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