<div dir="ltr">Here's an idea that arose between Daniel Kahn Gillmor and I (mistakes all my own). Imagine you're a centralized web service and you want to offer E2E encrypted messaging between your users. Hardening Twitter direct messages could be a target, but potentially others.<div>


<br></div><div>The goals and requirements are limiting here and this is not going to be a perfect system:</div><div>*most users can't install software and the browser is all they have (or maybe an app in the best case)</div>


<div>*users aren't going to compare fingerprints. The user experience has to be push-button</div><div>*the centralized service is a middleperson for all comms, no P2P or out-of-band</div><div>*users must be able to use multiple devices seamlessly and not lose access even if they lose all key material</div>

<div><br></div><div>So here's a proposal:</div><div>*Users can generate a private-key in their browser or app on demand</div><div>*Centralized service, after normal authentication (password, ideally 2-factor) issues certificates for these keys in browser using a private service-specific CA</div>

<div>*Users can download certs from the central service for their contacts and use these for encrypted messaging.</div><div>*The service runs a Certificate Transparency-style log for every certificate it issues and a similar transparency log for revocation (Revocation Transparency or Mark Ryan's Enhanced Certificate Transparency). Users query these structures to get proof that the certs they are using are genuine and not revoked.</div>

<div>*Outside auditors scan the log for correctness and provide a web interface to check which certs were issued for your username and when. </div><div><br></div><div>This system could be built with very few changes to the user experience and adds some security properties, namely E2E encryption and some visibility if bogus credentials are ever issued due to a subpoena or compromise.</div>

<div><br></div><div>The main challenges are:</div><div>*Synching keys between devices. One option is password-protected private keys you download from the service and decrypt in-browser. This has some security downsides and is a pain. Another option is a device pairing protocol similar to Firefox Synch, but this is also difficult. Finally, you can just have multiple keys/certs per device, but this requires broadcast encrypting messages. I'm not sure what's best here.</div>

<div>*Serving modified Javascript can violate security, and this might be the attack that government subpoenas would demand. Though this would be theoretically detectable, and might be legally riskier to demand.</div><div>

*Messages to users who've never generated a key. Does the service pre-emptively generate one on their behalf and hand it off to them? Or are they unreachable until they opt-in to the new system?</div><div>*The number of users may be much larger than the number of web domains (100 M or more), with frequent updates, so running a transparency log is a huge task, potentially much bigger than CT.</div>

<div>*Privacy. Is it okay to have a public structure with usernames, showing every time they've asked for a new key?</div><div>*The usual issues with how many users will ever check the log, and if it will be audited, as well as the desire for an outside party to run a log in case the central service's log screws up due to a bug.</div>

<div><br></div><div>There's also a big legal question around if a NSL could force a service to issue a certificate for intercepting messages which would leave public evidence. </div><div><br></div><div>Again, the goal here isn't perfection. We'd like much stronger approaches for users who can run their own software and not depend on a central service. But we'd also like to have a one-click solution that could provide some not-trivial-to-bypass encryption for traffic currently passing through Twitter/Facebook/Gmail and the like.</div>

<div><br></div><div>Cheers,</div><div><br></div><div>Joe</div>
</div>