[messaging] Reduce identity key exposure in Pond

[Jeff Burdges]

On 31 Mar 2015, at 1:43, Trevor Perrin <trevp at trevp.net> wrote:

> 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?

Remember Pond has two key pairs.  Contacts still see the same "message signing" key pair, just not the same identity key.  They cannot verify that they’re talking to the same mailbox, but they know they’re talking to the same “message signing" key. 

In fact, you should verify your pond contacts using the message signing key anyways, not the identity key, as that key is used to sign messages.  At present, the identity key’s only interaction with the ratchet is at initialization.  And the foreign half is still zero then : https://github.com/agl/pond/issues/176

>> 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.

At present, it’s completely realistic for someone to accidentally post their or your identity key on a public forum.  In principle, the fingerprint pull request  https://github.com/agl/pond/pull/175  should address that without tweaking the token plans, but this seems cleaner.  

Someone could email themselves their own state file and have a bad password, compromising all their contact’s identity keys and making the server a more interesting target for traffic analysis.  

>> 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.

I described a pretty fat token, yes.  I doubt one needs to double the token size though.  If I understand correctly, the current token is {x, HMAC(k,y)} and the contact derives y from x to send (y, HMAC(k,y)) with their message.  A token like {x, (z, HMAC(k,y)) } where z is a nonce plus a portion of y encrypted for the server.  In fact, x itself could be the hash of z, which slims down the token size considerably.  

> It prevents correspondents from being able to corroborate that they
> see the same public key for Alice.

Remember Pond has two key pairs.  Contacts still see the same other/main/message key pair, just not the same identity key.  You should verify your contacts using that key anyways, not the identity key, as that key is used to sign messages.

At present, the identity key’s only interaction with the ratchet is at initialization.  And it’s still zero then : 
https://github.com/agl/pond/issues/176

> You're also adding a security property that the server's in position to violate.  

That’s an interesting perspective.  At this level, there are a bunch of “little" security properties that either the server or a client could violate.  Intuitively, I’m more worried about client behavior than about the server. 

> 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.

I’d imagine some people do this today, but that’s a pretty bandwidth heavy solution.  And it’s actually neat that clients can still very that they’e talking to the same person using the "message signing” key. 

Jeff