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

Mike Hearn mike at plan99.net
Tue Sep 30 09:15:38 PDT 2014


Thanks. Yes that scheme does look better, although the "store all used
values" part would seem to be a deal killer for TextSecure. But as far as I
can tell it's not required that the server does this, if you don't care
about an introduced/authorized contact flooding you. If the only rate
limiting needed is new contact relationships being established, then the
client can churn through the one time use tokens as normal and just be
aware that if it accidentally reuses them, the server could link those two
messages together. Not a big deal as long as it's done correctly most of
the time.

I guess implementing in TextSecure could take place in stages:

   1. Find a way to make the messages within a chat fully unlinkable. I'm
   not sure what kind of transport space constraints TS has now secure SMS is
   being dropped. Get it rolled out.

   2. Integrate Orchid/Tor and connect back to TS HQ in parallel to the
   original message sending codepath. Measure how much delay would be added on
   average and how often Tor fails but direct connects succeed. There doesn't
   seem much point obfuscating at the app layer if the network layer can't
   also be obfuscated in the real world. Get it rolled out.

   3. Assuming Tor is going to work, implement "intro token" blind signing
   and HMAC tokens but don't enforce their usage, see how often people run out
   in practice (false positives) and tune the quantity issued. I'm assuming
   here that TS is currently spam free, otherwise this tuning could be thrown
   off. Figure out a re-registration throttle that wouldn't hurt ordinary
   users. Get it rolled out. No-op from the users POV.

   4. Now all the pieces are working in parallel to the old send path,
   start enforcing the new rules and eventually stop submitting messages
   directly unless there are cases where Tor isn't working (China/corp
   firewalls?)

A fairly large project, but it should all be invisible to end users and
there are a series of nice milestones along the way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140930/faedfb76/attachment.html>


More information about the Messaging mailing list