On Mon, Mar 30, 2015 at 8:40 PM, Jeff Burdges <[email protected]> wrote: > > Adam wants to authenticate message delivery with single use tokens. A token > consists of a public-private key pairs (y,x) along with a proof HMAC(k, y) > that the public key y was issued. > > At present, Pond users have two long term public-private key pairs : > - all your contacts know both public keys, while > - the server identifies your mailbox with your "identity key", but the server > does not know your other key. > > It’s slightly undesirable that your contacts know the public identity key > that identifies your mailbox on the server. > > Instead, the delivery token could hide the identity key the server wants.
Thanks, I think I get it, let me restate to make sure: With one-time delivery tokens the mailbox server needs to know which recipient's inbox an incoming message is for, so the server can validate the token using the appropriate state, and then store the message in the appropriate box. So Alice's correspondents could store some identifier for Alice (call it <id>), and send that along with every message. That's how Pond envisions using delivery tokens. You're suggesting instead that Alice gives her correspondents an *encrypted* <id> value alongside each token. The <id> for each token would be public-key encrypted to a public-key held by the server (and assume randomized encryption, so you can't recognize when the same <id> is encrypted). So now Alice's correspondents don't know her <id> value. On the server side this doesn't accomplish much: the server sees <id> for each message, as before. But Alice's correspondents can't link their tokens and realize they're talking to the same person (unless the server colludes with them). So perhaps your goal is to eventually remove other linkable public keys / data from Pond, so it's harder for parties to recognize they have shared correspondents? > Does this complexity buy us anything? > - Your contacts cannot accidentally reveal your identity key. > - It’s safer to give away a delivery token when introducing two contacts. > - A server must be more thoroughly compromised to gain any traffic > information. > - A hardened server becomes a less attractive target. I don't follow those - the only benefit I see is above. > Does it cost us anything? It makes tokens bigger. Before each token just had to include a (private-key, MAC over public-key). Adding a public-key-encrypted identifier is going to at least double this, I think. Alice has to replenish her correspondents' tokens frequently, since each message consumes a token. Pond's a bandwidth-limited system, so that's a real cost. It prevents correspondents from being able to corroborate that they see the same public key for Alice. You're also adding a security property that the server's in position to violate. An alternative would be for Alice to create separate Pond identities when she wants to communicate under different, unlinkable pseudonyms. This gives her the possibility of keeping these identities unlinked even from the server, so it's arguably a better solution for this problem. Trevor _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
