[messaging] Reduce identity key exposure in Pond

[Trevor Perrin]

On Tue, Mar 31, 2015 at 6:58 AM, Jeff Burdges <burdges at gmail.com> wrote:
>
>
>
> 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.

Right, which is why I wondered if your goal was to "eventually remove
other linkable public keys [...] so it's harder for parties to
recognize they have shared correspondents".

It seems that's not your goal, so I'm unsure what the goal is.


> At present, it’s completely realistic for someone to accidentally post their or your identity key on a public forum.

So what?  Who cares that a server indexes a user by some particular identifier?


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

Why does knowing contact identity keys make any server a "more
interesting target for traffic analysis"?  What does that mean?

There's some piece of this you're assuming but haven't explained, it feels like.


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

You could truncate x (say to 16 bytes, and derive the rest of the
private key via PRG keyed by x), you could also truncate the HMAC.
Adding public-key encrypted data adds an ephemeral public key (32
bytes for 25519), the ciphertext, and probably a MAC.

So I think at least doubling the size of tokens given from Alice to
her correspondents is accurate.


>  In fact, x itself could be the hash of z, which slims down the token size considerably.

If z includes the public-key encrypted to the server, how could the
private key could be a hash of z?


Trevor