On 19 August 2014 03:18, Trevor Perrin <[email protected]> wrote: > Yet I'd ALSO claim the provider is one of the most > important entities for end-to-end crypto to protect us from. > Conundrum.
When you don't trust your provider, I think that can be roughly analogized to trying to solve the present-day CA system while acknowledging they're not going away. The best we've seen come up with is CT. It's a 'Trust but Verify' model, except those who verify are very few. The extension of this, I mentioned a few months ago: On 26 March 2014 08:17, Tom Ritter <[email protected]> wrote: > A design I keep circling back to, despite not liking it all that much, > is a 98% Trust, 2% Verify model. It needs a new name, but the idea is > open specifications, and open ability to write outside clients that > interop that you trust more. The outside client may be browser > extensions silently verifying the code, extensions providing the whole > experience, mobile apps, native apps, whatever. The 2% run these > outside clients and don't 'trust' the service to do the encryption, > the 98% use provider-bootstrapped code that can be tampered with. > Delicately designed, on an individual request, the service shouldn't > know who is the 2% vs the 98% until it's too late to undetectably > tamper. On repeated observations, the service may know, but I think > this can be mitigated a little bit. > Elijah criticized the idea of applying CT to the "user key problem" > [3]. I think the crux of his argument is that we want anonymized key > lookup for relationship-hiding anyways, so we can use that for > auditing (like Nyms). CT doesn't "add enough benefit to justify the > complexity". I don't think we've fully explored the possibility and capability of a network of interconnected, blinding services that perform key lookup. Convergence experimented with this a little, but didn't optimize it. What I imagine: Providers A & B run at least 2 servers each, co-locating one of theirs in the same datacenter. They keep a long-lived TLS session open to each other. I make a request to A, encrypted to B. A immediately passes it to B, which answers and re-encrypts, passing it back to me through A. Other mechanisms like PIR of course exist for anonymized key lookup, but my first thought was 'make it really fast'. -tom _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
