[messaging] Reduce identity key exposure in Pond

[Trevor Perrin]

On Mon, Mar 30, 2015 at 8:40 PM, Jeff Burdges <burdges at gmail.com> 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