On 13 Jan 2016 06:33, "Doug Barton" <dougb@xxxxxxxxxxxxx> wrote:
> 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.
>
If I understand proxy re-encryption correctly - and I almost certainly do not - then there are four roles. It'd be really useful to be shot down on any misunderstandings here. Note that I have no clue how the maths works, and have therefore attributed this to the crypto-fairies.
The sender, who has the private keys for themselves, and the public key of the proxy.
The proxy, which has the recryption keys of the members.
The members, who each have their own private keys.
The administrator, who has magic fairy dust allowing new keys to be added as members of the proxy.
When senders send to the proxy, they're encrypting in a special way which means that the proxy can't decrypt; instead it can only re-key the message to each member. The proxy also cannot add other keys (including its own), so cannot just add itself as a member and decrypt the result. Members receive the message, and thanks to the crypto-fairies, they see it as signed by the sender. I like to think of this as a special-case of homomorphic encryption, but only so I can sound like I know what I'm talking about.
Members provide their public key to the administrator on joining; the administrator then applies magic fairy dust to provide the proxy with a recryption key specific to that member.
Reading Phillip's message, it seems that last bit may be wrong - perhaps each member gets a key pair from the administrator. That would be rather disappointing, since it requires the administrator to be much more trusted than I'd hoped for. If I understand the literature correctly, though, the proxy never has access to the private key.
I suspect that while Phillip is using the mailing list case to explain it, proxy recryption is a much better fit when the members are your devices, the administrator is you, and the proxy is your account-proxy in XMPP, or your IMAP server (perhaps) in mail. The limitations of administrators having to provide keys become much more manageable then.
For those not blessed with XMPP knowledge, the bare jid - user@xxxxxxxxxxx - is actually hosted on the server and can trivially see every message; each connected device has a full-jid, user@xxxxxxxxxxx/resource, so the bare jid would be the recryption proxy and everything works out very neatly with the existing model.
> Doug
>