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.
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
_______________________________________________
Messaging mailing list
[email protected]
https://moderncrypto.org/mailman/listinfo/messaging
