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

[John-Mark Gurney]

Tom Ritter wrote this message on Wed, Mar 26, 2014 at 09:17 -0400:
> 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.
> 
> In an online-encrypted document sharing model, for the 98%, this would
> look like a document being OpenPGP-encrypted in javascript with a
> symmetric key you choose, and stored online by the service. The
> recipient visits the fileshare, using javascript OpenPGP-decrypts the
> document using the password they received out-of-band, and downloads
> it. For the 2%, they PGP-encrypt the document using gpg, and upload
> it, communicate the secret out of band, and the recipient decrypts it
> using javascript. Or, they receive a document encrypted with
> javascript and download it and PGP-decrypt it using gpg.  If you build
> the service correctly, the service won't know ahead of time if the
> document is going to be decrypted in javascript or gpg, and thus can't
> reliably attack the user without a chance of detection.
> 
> I think this model comes up again and again, like in Opportunistic
> Encryption for TLS (or whatever it's being called these days).  If the
> server sends a certificate and the client doesn't verify it, an
> attacker can MITM it. But if the attacker knows that _some_ unknown
> clients _do_ verify it, via Convergence or TOFU or the EFF Distributed
> Observatory - attacking the user becomes more dangerous as they could
> get caught.

The only issue w/ this is that it assumes that a user isn't targeted..
As we have seen w/ TAO, this isn't always the case, and if the user is
targeted, they'll know if they run a verifing client or not, and if not
can MITM the messages...  This would only work if all users randomly
verify the messages, but that seems impracticle.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."