On Mon, 2015-07-27 at 23:07 -0700, Brian Warner wrote: > On 7/24/15 1:09 AM, Jeff Burdges wrote: > > I believe the distinction in Vuvuzela between dialing contacts you > > haven't contacted recently, and conversations as bursts of messages > > should be relevant to token distribution. > > > > I think Vuvuzela used a unique mailbox for each conversation, making > > trial decryption far more viable in that case. I'd imagine one could > > evolve the conversation mailbox address with the ratchet state if > > desired. > > Ah, interesting, so there could be one protocol for creating a "room" or > a "mailbox", and a separate one for maintaining the tokens necessary for > a given room. There are probably fewer rooms than potential senders, so > trial decryption is easier. I guessing it'd feel more "connection > oriented": there's a distinct UI and/or network thing that happens when > you establish a new conversation.
Yes, exactly. Vuvuzela is simple enough that they can analyze how long an already-dialed conversation can go for while protecting the metadata from routers. They show that you can maintain these already-dialed conversations for quite a while for relatively little bandwidth. It's worth keeping any eye out for already-dialed conversations to be relevant elsewhere. > Since Trevor suggested that we might combine the delivery token with the > ratchet, I went ahead and wrote up what an all-token protocol would look > like, where each (single-use) token is used both for mailbox delivery > and recipient key selection: > > http://www.lothar.com/blog/53-petmail-delivery/ Nice post. At present, Petmail's re-randomizable delivery tokens (STID?) are created by multiplying two curve25519 public keys by a second scalar? I wondered if there might be properties in between R1 and R0, like : "the recipient cannot identify senders from the transport, but each individual sender can send only one message per time window" I suppose we should consider the system "hard to implement" if you need multiple servers though, which sounds likely for this. I suppose the VLR group signature scheme would be S1 M0 R0 Rev0, with the caveat that revoking involves the server, but presumably VLR is hard to implement and leaves the server open to computational DoS like BBS does. I suppose Pond's new token scheme is also S1 M0 R0 Rev0? In both cases, the S1 comes from the system's need to identify the recipient mailbox externally to the token, yes? You could wrap the delivery token in a Sphinx/HORNET mixnet header, but that's a huge token. Also, if we've an S0 system that supports introductions, then any introduction is followed by a negotiation in which the contacts must recognize if they were already contacts or not. I'd expect this costs : (a) either one extra round trip with the introducer or multiple round trips between introduced parties, and (b) makes the user interface counterintuitive because you keep being introduced to people you already know.* I'd consider that a good argument for abandoning S0 in favor of S1, at least for normal human messaging. In what applications do you imagine S0 being so important? Add some pairwise but non-transitive identity? * Involuntary contact introductions sounds highly problematic. As does an exponentially expanding contact pool. Jeff p.s. There is a "trivial" S0 M0 R0 Rev0 delivery scheme in which all connections remain "dialed" in that the mailbox number for that particular pair of contacts is derived from a hash of the previous axolotl round's rootkey, similarly to how pond derives the encryption key for the axolotl header. This is delivery authentication in the sense that you'll never bother to check a mailbox that does not already belong to you. And mailboxes move all the time. This scheme does not scale. And it does not protect the server from DoS either. It does however show that "dialing" need only communicate intent, not actual data, and could even be probabilistic.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
