On Thu, Apr 3, 2014 at 4:09 AM, Michael Rogers <[email protected]> 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 _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
