[messaging] Keyservers discussion - Day 1 highlights
natanael.l at gmail.com
Tue Aug 19 08:59:02 PDT 2014
Den 19 aug 2014 16:17 skrev "Tom Ritter" <tom at ritter.vg>:
> 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.
I recognize this approach from reading about cryptographic voting methods,
the general method is called "cut and choose" where a random subset of
inputs is revealed/unsealed, selected to make malice hard to hide.
So "cut and choose verification"?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Messaging