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

[Tom Ritter]

On 30 March 2014 12:10, Joseph Bonneau <jbonneau at gmail.com> wrote:
> Worth stepping back and re-stating the original design motivation. This is
> not intended to be a better solution for users capable of maintaining a
> secure client, installing a good crypto app properly, and securely verifying
> fingerprints with their contacts ("everybody downloads and uses PGP world").
> The goal is to provide *something* for users at a centralized service that
> gives end-to-end encryption in such a way that some public confidence can be
> built up in the service provider, and the service provider has a technical
> reason to refuse surveillance requests.

Let's take a step back and think about how you achieve authenticity.

 - Prior Authenticated Channel for one of
   - Ratchets key material forward, resulting in a pre-shared secret
   - Is used to communicate public keys/fingerprints
 - Pre-Shared Secret outside of a specific 'channel'
 - Trusted Third Party

Everything else builds out of one of those or is designed to detect
compromise that happened in the past. Can one of these other forms of
authenticity be scaled up to a Twitter scenario?  We're assuming that
detecting compromise in the past is sufficient to deter a 'Malicious
but Cautious' adversary.

What are the other ways to detect prior compromise?  Could one of
those lend themselves to this problem?

What if Alice signs the message with her key saying "I encrypted it to
KeyID X"?  Preventing and detecting a compromise this way makes a lot
of assumptions, the biggest two of which are probably: 1. That we
can't trick Alice into signing a false statement (meaning Trent can't
modify her software on the fly). 2. That Bob knows what Alice's
signing key is.

-tom