[messaging] Transparency for E2E encrypted messaging at a centralized service

[Moxie Marlinspike]

On 03/26/2014 03:27 PM, Joseph Bonneau wrote:
> I hope not, because I fully expect most users will do neither. My goal
> was to provide *some* protection for users who don't do anything thanks
> to a few users who actually do audit the log against their own history.
> Security comes from the fact that the authorities might be able to MITM
> some users who aren't checking, but eventually they'll slip up and
> attack a users who does check and can then prove it.

Maybe I don't understand.  My reading was that no 3rd party can audit
the log to discovery anything about a MITM of any other user, since key
changes will happen frequently in the normal use case, which would look
identical to a MITM.  3rd parties will just see keys changing a lot.
They'll even frequently see keys changing, then changing back to what
they were before that change.

That would mean the only people who can derive potentially useful
information from the log are the users themselves, or potentially the
people they're corresponding with at that moment.  That's why I
understand it to be trading in-band verification for self-audit based
verification.  My sense is that users won't be able to handle that
themselves, and worse, the ones who try will forget their own history
and end up concluding that they've been MITMd when they haven't.

> Hopefully this is
> enough to make the attacker wary. This has been referred to as the
> "malicious but cautious" adversary model, and I like Tom Ritter's
> explanation that 98% of users trust and 2% of users verify.

If we're going for 2% verify, does this accomplish more than making the
visibility of key conflicts an option that defaults to off, but which 2%
of users will flip on?

- moxie

-- 
http://www.thoughtcrime.org