[messaging] Keyservers discussion - Day 1 highlights

[Natanael]

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...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140819/31e91ea0/attachment.html>