<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I think every 5th contact being linkable is likely problematic.  Or at<br>
least, I don't know how to effectively communicate that to set user<br>
expectations.<br></blockquote><div><br></div><div>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".</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Also, it seems plausible that someone could install TextSecure and want<br>
to send an "I'm on TextSecure!" message to more than 5 people before any<br>
of them respond. <br></blockquote><div><br></div><div>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.</div><div><br></div><div>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. </div><div> </div><div><span class="">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. </span>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.</div><div><span class=""><br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">at least 232 requests/second of cpu-bound work.</blockquote></div><div><br></div><div>Yes, although the two Schnorr blind signing operations are both quite straightforward:</div><div><br></div><div><a href="http://blog.cryptographyengineering.com/p/note-on-blind-signature-schemes.html">http://blog.cryptographyengineering.com/p/note-on-blind-signature-schemes.html</a><br></div><div><br></div><div>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.</div><div><br></div><div>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 <i>could</i> spam more people for a while - but he has no way to know that from the outside.</div></div></div></div>