On 01/02/2016 09:13 AM, Phillip Hallam-Baker wrote:
On Sat, Jan 2, 2016 at 2:25 AM, <l.wood@xxxxxxxxxxxx> wrote:
"If Alice wants to encrypt the message for a group of people, she has to encrypt the message for every member of the group."
really? not encrypt the message to a random key, then encrypt that key separately to each member? much less processing...
That is how it is done under the covers, yes. But that is the sort of
optimization that I assume everyone knows.
With standard S/MIME or PGP, the final message has a decryption blob
for every recipient. So if you are sending to the IETF list, there are
three consequences:
1) The sender has to know the entire recipient list
2) Every message sent reveals the entire recipient list
Not necessarily ... there are ways to encrypt a message without
revealing the encryption keys that it was encrypted to. They are
slightly messier for each list member to decrypt if they have multiple
keys, but for users who only have single keys they are actually quite
painless.
3) The recipient list cannot be expanded after the message is sent
That's no worse than current mailing list software.
Using the recryption approach, the sender only encrypts the message
once, to the key corresponding to the group (or security label if you
want to think of it that way). So messages don't disclose anything
about the other list members.
This isn't just better security, it is a lot easier to implement
because senders don't need extraneous information. It is also more
manageable because a member added to the list after the fact can read
all the messages in the archive.
Doesn't this require each member to have the group's private key so that
they can decrypt the messages? I thought (but have not verified) that
such systems decrypt the message with the group's private key, then
re-encrypt it to the public keys of the list members at that point in time.
That would mean of course that you would only be able to decrypt
messages from the time period where you were a member of the list.
Doug