[messaging] Message delivery and revocation in Pond etc

[Trevor Perrin]

On Thu, Apr 3, 2014 at 4:09 AM, Michael Rogers <michael at briarproject.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 30/03/14 17:31, Trevor Perrin wrote:
>> Bob and his server share an HMAC key k.  Bob distributes to each
>> of his contacts a bunch of pairs (x, HMAC(k,y)) where (x,y) are a
>> signature keypair (y=g^x).
>>
>> Contacts then send (msg, y, HMAC(k,y), sig(msg, x)) to the server,
>> which records used values of HMAC(k,y) and rejects them in future.
>
> Is crypto needed here? Assuming secure connections between Bob and the
> server, and Bob's contacts and the server, Bob could just upload some
> random tokens to the server, and hand the same tokens out to his
> contacts; each token would be redeemable for delivery of one message.
> Bob would know which tokens had been given to which contacts, but the
> server wouldn't.

I think you want signatures for garbage messages which fail end-to-end
authentication but could be used to fill the recipient's mailbox with
junk.

With signatures a recipient can attribute a garbage message to a
particular sender, or to the server (if the message can't be
attributed to a sender, e.g. bad signature).


> To revoke a contact's access, either (a) remove the contact's tokens
> from the server (but this lets the server guess how many contacts you
> have based on what fraction of tokens you remove), or (b) stop giving
> the contact fresh tokens, allow the outstanding tokens to be spent, or
> (c) stop giving the contact fresh tokens, connect to the server
> anonymously and spend the outstanding tokens yourself.

Interesting point on (c) - the recipient could "revoke" the tokens
anonymously by using them, which would avoid leaking the fact of
revocation.  But if the sender is spamming you, you might want the
server to delete messages already received, which would require a more
explicit revocation like (a).

Anyways, whether it's better for the server to maintain a whitelist of
tokens, or give the server a verification key (e.g. HMAC key) and have
it maintain a blacklist of seen tokens, I'm not sure.  Seems like it
could work either way.


Also, the Pond group-signature approach could be improved by using
"VLR" signatures, according to Dan Boneh, which would eliminate some
of the awkwardness around revocation.  Haven't looked at this, but
from his description I think it might be computationally expensive if
too many revocations:

http://cseweb.ucsd.edu/~hovav/dist/preteripsistic.pdf


Trevor