[messaging] Keyservers discussion - Day 1 highlights

Tom Ritter tom at ritter.vg
Tue Aug 19 07:16:59 PDT 2014

On 19 August 2014 03:18, Trevor Perrin <trevp at trevp.net> 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 <tom at ritter.vg> 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'.


More information about the Messaging mailing list