> A final, and salient feature on the key distribution approach is that it allows only prospective eavesdropping -- that is, law enforcement must first target a particular user, and only then can they eavesdrop on her connections. There's no way to look backwards in time.<p>Actually, its even weaker of an attack than that. Signal (for example) stores a copy of the keys locally on the other person's device after a conversation has been initiated (and notifies users if they've changed). You could augment this with TUF or some other updating system to make additions of new devices (or removal of old ones) also secure. So really the distribution attack only works for <i>first connection</i>. And this is why PGP key signing parties are a thing (and why I ask for two forms of government ID before signing their keys).
He's missed the real approach - "work reduction". This is giving the cryptosystem or the random number generator some hidden property which reduces the amount of work required to break the key. We've seen this repeatedly in cryptosystems deployed with bad random number generators.[1][2]<p>[1] <a href="https://www.schneier.com/blog/archives/2012/02/lousy_random_nu.html" rel="nofollow">https://www.schneier.com/blog/archives/2012/02/lousy_random_...</a>
[2] <a href="https://umaine.edu/scis/files/2014/10/The-Sad-History-of-Random-Bits.pdf" rel="nofollow">https://umaine.edu/scis/files/2014/10/The-Sad-History-of-Ran...</a>
I believe the master key sharding he mentions based on this <a href="https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing" rel="nofollow">https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing</a> and has actually been implemented(though I'm not sure if it is at the scale he implies) here <a href="https://www.vaultproject.io/docs/concepts/seal.html" rel="nofollow">https://www.vaultproject.io/docs/concepts/seal.html</a>
That's good timing, given the discussion yesterday on a similar topic:<p><pre><code> https://news.ycombinator.com/item?id=12254960
</code></pre>
There are a couple of things in the article I'm not sure Matt got quite right.<p>WhatsApp does let you compare key fingerprints, believe it or not. At least you can scan QR codes to check. I don't know if doing that triggers a key change warning in future.<p>End-to-end encryption doesn't seem to impact whether law enforcement can look backwards in time or not. Simply not logging message content is sufficient to prevent this. WhatsApp couldn't provide law enforcement with message content prior to a tap being requested even before they integrated the Signal protocol because they didn't log message content at all (or so they say). Introducing E2E crypto in the style of WhatsApp solves only one specific threat model as far as I can tell - if someone is capable of hacking your datacenter to the extent that they can siphon off and log messages by themselves without you noticing, but they aren't also capable of doing a key switcheroo. This would be a strange but possible kind of hack. Note that this assumes the users aren't storing their device keys and comparing them by hand and that the hacker can't influence the code that gets shipped.<p>He assumes the user can detect key mismatches. Even if users can compare keys, this assumes that their client does what they think it does. It's noted in another comment here but all it takes to undo this assumption is getting Google or Apple to push a dummy binary to the specific devices of interest that claims things are encrypted even when they aren't.<p>You wouldn't need to deploy threshold crypto 'at scale' for the proposed scheme to work. Some schemes like Shoup threshold RSA result in a normal public key:<p><pre><code> http://www.shoup.net/papers/thsig.pdf
</code></pre>
So the only part that's non standard is the software for working with the shares to decrypt, which only has to work and exist between the various agencies.<p>But I'm not actually even sure you need special threshold crypto schemes. I guess you could also take the session key(s) and encrypt them with key 1, then encrypting that value with key 2, etc, to build up an onion of encryptions. The various participants then have to pass around the value in the same order hard-coded into the software to get it back. The advantage of this approach is you can use ordinary HSMs to protect the keys, i.e. the hardware itself enforces that the private key may never leave the hardware unless it's being cloned to another HSM.<p>But these are all minor details. The point Matt makes is well made, which is that you can build backdoors into cryptographic systems, and the reasons people don't want to do this are primarily political rather than technical. I continue to be concerned that the tech community may be about to burn its credibility with the mainstream population for no reason by claiming this stuff is impossible to do or is completely unthinkable, when it's actually not. Opinion polling showed that there was no general consensus behind Apple's refusal to unlock the phone in the FBI case: many people don't support the tech industries absolutist position here (perhaps because they don't understand the potential mass surveillance has).<p>Moreover, governments will generally not accept an answer of "you are imperfect thus should not have the law enforcement capability you want". Lawmakers understand and accept that civil servants will make mistakes or be openly abusive and only generally want to control the levels of error/abuse, not eliminate it. Certainly the sorts of positions the Obama administration is looking for would accommodate key revocation procedures if the government agencies in question somehow did screw up and their private key leaked out of their HSMs. I suspect they'd happily agree to temporarily losing their capability to restore system integrity if there was a procedure for restoring their access once a neutral third party had re-audited the relevant offices. This sort of detail isn't where lawmakers are at: they think in broad strokes rather than the details of procedures.