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

[Mike Hearn]

>
> I think every 5th contact being linkable is likely problematic.  Or at
> least, I don't know how to effectively communicate that to set user
> expectations.
>

I'm uncertain whether trying to explain the details to end users is a good
idea. I'd be tempted to just label the upgrade "privacy improvements" and
leave it at that. If there's a class of users who would use TS if contact
adds were 100% unlinkable but not when they're 80% unlinkable, it would be
reasonable to get into the nitty gritty, but I suspect most users just want
to use "an app that does its best to protect my privacy".


> Also, it seems plausible that someone could install TextSecure and want
> to send an "I'm on TextSecure!" message to more than 5 people before any
> of them respond.
>

Sure. Five was picked out of the air. I guess TS already has some kind of
rate limiting so a new user can't immediately send messages to thousands of
contacts after signup, so it can just be aligned to that instead.

Re: multiple rate limits. If I understood correctly, the issue is you have
a leaky bucket per sender:receiver pair, so I can exhaust my quota for user
X but not user Y? That does seem harder.

An initial implementation could use the single token and have linkability
between the actions of the blinded identity. Breaking linkability between
those actions can be a later upgrade. Seems to make it more digestible. It
boils down to a tradeoff between disk storage for expired tokens and cpu
time for clients rotating them to a new key. Do you have any stats on how
often one user messages another without having contacted them before?
That'd let us do some back of the envelope calculations on how much disk /
cpu would be needed for a given user population.

at least 232 requests/second of cpu-bound work.


Yes, although the two Schnorr blind signing operations are both quite
straightforward:

http://blog.cryptographyengineering.com/p/note-on-blind-signature-schemes.html

I bet an optimised implementation can handle all of that traffic on one or
two cores at most. So three machines for redundancy ... it feels plausible.

The expensive part would be the database write on the initial intro. It can
be stored entirely in RAM assuming small nonces and signatures, because if
the data is lost, it merely means the spammer *could* spam more people for
a while - but he has no way to know that from the outside.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20141001/8c0976a7/attachment.html>