On 01/12/2016 06:27 PM, Phillip Hallam-Baker wrote:
On Tue, Jan 12, 2016 at 8:32 PM, Doug Barton <dougb@xxxxxxxxxxxxx> wrote:
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.
Not without modifying the specs and the apps you can't. If you are
going to do that then proxy recryption does exactly what you want.
It's in GnuPG for years now:
--throw-keyids
Do not put the recipient key IDs into encrypted messages. This
helps to hide the receivers of the message and is a limited
countermeasure against traffic analysis. ([Using a little social
engineering anyone who is able to decrypt the message can check
whether one of the other recipients is the one he suspects.])
On the receiving side, it may slow down the decryption process
because all available secret keys must be tried.
There is another option as well that works similarly, but for single
recipients.
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?
No, each user has their own private key. It is supplied by the group
admin when they subscribed or it is encrypted under their public key
and sent out with each message.
So they have *a* private key for the list, just not necessarily *the*
private key. I suppose that might make it easier to revoke someone's
read access after they've been removed from the list ... it also means
they can't read anything from before they joined, unless the archives
get re-encrypted.
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 is what my understanding of how it is done today by the systems
out there. What I am saying is that twenty years ago Matt Blaze showed
us a better scheme and nobody seemed to notice the importance at the
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.
If you use the old technology, that is one of the problems.
Well, yeah. :) Did I miss a proposal for new tech?
The other
is that you have to find someone you trust to run the mailing list or
the jabber contact service or whatever.
Well that's a given no matter what solution you choose. If you're
relying on someone else to do encryption on your behalf, you have to
trust them. But that's a marginal increase in trust compared to running
a non-encrypted list in the first place.
Doug