<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Thanks Moxie, good to know I'm not far behind :-)</div><div><br></div><div>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 already.<br></div><div> </div><div>For the other issues:</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Disk writes:  no disk writes <i>at all</i> 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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></div>