On Thu, Apr 2, 2015 at 5:28 PM, Joseph Bonneau <[email protected]> wrote: > Coming to this thread a little late, I would try to summarize this as an > attempt to separate two types of keys: > > *Message keys, for which we might like for Bob and Charlie to be able to > link Alice's message keys to be sure they're talking to the same party (or > compare against, say, a CONIKS server somewhere). > *"Identity keys" (not a great name) which are used for routing to a specific > mailbox.
Agreed we're discussing the relationship between: (1) the public keys used by parties to authenticate each other (2) the delivery identifiers used to inform recipient servers which recipient you're delivering a message to In Pond I think there's a 1-to-1 relationship. Jeff was suggesting keeping this but encrypting the delivery identifier to the recipient server's public key as part of the "delivery tokens" Alice gives to her correspondents. I didn't think that accomplished much, since: - Communications between Alice's correspondents and Alice's server will have transport encryption anyways - Alice's server needs to receive the identifier either way - Alice's correspondents will still be able to recognize they are talking to the same party due to the "linkable" public key (1) > We'd like Bob and Charlie (or Bob today and Bob tomorrow) to be > able to easily set up to route to different mailboxes for Alice, using the > same message keys for encryption (or keys ratcheted forward from them). That > way the server can't easily link all of Alice's traffic. > > Currently the two are intertwined in Pond and the suggestion of "just have > multiple Pond identities" is a little unsatisfactory. What if I'd like to > break up traffic analysis the server can do (or even use multiple servers) > while keeping a consistent Message key for my correspondents? > > Is that the problem that we're trying to solve? If so, I think there are > some pretty straightforward ways to do this by allowing Alice to have > multiple mailboxes with the same key You're suggesting relaxing the 1-to-1 relationship so that Alice could use her same public key but have different delivery identifiers on different servers. I see that as potentially a convenience (Alice could change providers without triggering TOFU warnings). But I don't see it as an important security property: the situation where Alice is OK that her correspondents can recognize the shared identity but doesn't want her servers to recognize it seems contrived. I think a useful notion of unlinkable identities needs to be more thorough, e.g. either - no linkable identifiers, every connection with a correspondent uses unrelated keys - identifiers are linkable, users have to manage separate accounts if they want separate identities (Pond) Trevor _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
