On Tue, Mar 31, 2015 at 6:58 AM, Jeff Burdges <[email protected]> wrote:
>
>
>
> On 31 Mar 2015, at 1:43, Trevor Perrin <[email protected]> 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
_______________________________________________
Messaging mailing list
[email protected]
https://moderncrypto.org/mailman/listinfo/messaging
