On 30 March 2014 12:10, Joseph Bonneau <[email protected]> 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 _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
