[messaging] Recognizing senders of metadata-hidden messages

[Jeff Burdges]

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.  




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20150728/9af62d60/attachment.sig>