[messaging] Metadata free instant messaging protocol, with basic spam throttling

Mike Hearn mike at plan99.net
Tue Sep 30 03:50:57 PDT 2014

Thanks Moxie, good to know I'm not far behind :-)

W.R.T the header fields, I'd been assuming that the forward-secrecy/axolotl
stuff would run inside an encrypted wrapper so the server doesn't see any
of that. But I assume there's a good reason it doesn't work this way

For the other issues:

Clients reregistering at will. I admit I'd forgotten about that and this
makes it fundamentally different to email where accounts are long lived.
The fact that the client can't store long term data and there are no
passwords is .... problematic. From an abuse perspective I guess some
heuristics about how often to allow re-registration would be the best you
can do. You can build statistical models about how often users are expected
to re-register and watch out for numbers that are re-registering more often
than that. It's not quite as good as when the user has a password and thus
a long lived account though.

Token reuse: tokens are only used when introducing yourself to a new
contact for the first time. If the client cycles through the tokens then
only every 5th new contact is linkable. I think your suggestion of simply
rotating keys every N hours and having clients refresh the tokens is
reasonable. N could be adaptive to let operators trade off CPU vs disk time
on the server dynamically.

Disk writes:  no disk writes *at all* is definitely a tough constraint and
very unlike the email world. However, again, updating the token db is only
needed for first time introductions. After contact is made all subsequent
messaging sessions only need to look up the group public key at connect
time, which I guess can be a regular disk DB with enough memcache to get
latency and iops within your budget.

Deniability:   I must admit I never convinced myself as to the value of
this. I find it hard to imagine a real world scenario in which someone says
"ah ha! i will ignore this otherwise solid evidence against you because
it's possible that the evidence was forged!".   Does deniability ever come
up outside of hypothetical court cases? If so, surely police routinely
present evidence that could theoretically have been forged but which is
admitted anyway, because in practice forgery of evidence is rare? My
intuition would be that deniability is perhaps worth discarding to get
other kinds of privacy features.

Periodic tasks:   good smearing can make this load more or less constant,
but I don't know anything about TextSecure's cost models or budgetary
constraints so can't comment much on this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140930/30215a03/attachment.html>

More information about the Messaging mailing list