can you see any problem with this?

[David Shaw]

On Tue, Feb 05, 2008 at 12:02:48PM -0500, Adrian Thurston wrote:
> Hi,
> 
> I'd like to serve messages that have been encrypted to a large number of
> people, however I don't want to reveal the list of recipients so I'm
> going to use --throw-keys.
> 
> But speed at the decryption end is a concern, so I thought I would break
> up an encrypted message into packets and when a client requests it serve
> up only the packet that corresponds to the session key encrypted to
> them, then the content packet. I haven't tried it yet, but it seems as
> though it should work. I'd like to know if there is any non-obvious
> reason why it is a bad idea.

It's hard to really answer this as there isn't enough information to
say one way or another.

Speaking strictly to your question, and not the "is this wise"
question, if I understand it, you are proposing encrypting to a large
number of people, breaking the resultant encrypted message into many
PKESK packets (one per recipient) and one encrypted packet.  Then,
send each recipient their own PKESK plus the encrypted packet.

So, yes, that would work.  GPG even ships with the tools to make such
a message.  And it's safe to do so with the caveat that every user
will have the same encrypted message and be able to decrypt it.  On
the one hand, no big deal, becuase you sent everyone the same message,
so you clearly wanted them to have it.  On the other hand, it gives
Alice the ability to know that Baker got the same message that Alice
did.  Whether that is important or not depends on what you are doing.

Also, given that you are only sending each recipient their own PKESK,
why bother to use --throw-keyid ?  It might be easier to just encrypt
the whole message to each recipient individually rather than do all
the packet surgery.

David