Yes. More specifically, encrypted data cannot be decrypted without the key.

So your choices are:

1. Only the user has their key

2. Someone else has the user's key

If a company, law enforcement, or anybody else has a trove of everyone's keys, that trove will be extremely valuable to hackers, organized crime, domestic and foreign intelligence, etc, and it will be stolen. Whether we'll know it's been stolen is another question.

The debate typically continues along the government's right to compel the holder to reveal the key, or to reveal the decrypted message, as a loose analogue of rights of governments, where exists, to compel physical writings or access to a strongbox.

If we accept that mechanisms in common use, like warrantful search of physical belongings under the Fourth Amendment of the US Constitution, are legitimate and rightful functions of government, then warrantful key disclosure is a logical compromise that protects the individual's privacy, except when the government compels them with good cause to reveal information. Balancing this with protections against self-incrimination is one complication that's currently playing out.

This may be nitpicky, but I don't think we should use the phrase "rights of the government." It implies that the government has some innate justification for those actions, and I think it leads to a slippery slope whereby we create rights of the collective. For example, if the government has the right to jail people, the jail is there to protect all of us. As a society, that gives us the right to beg for anyone to be thrown into jail "for the good of society." It also gives legitimacy to any government action: if they have a right to throw people in jail, you can't really complain about it when they do so even if they're clearly in the wrong.

My proposal for this, which I doubt either side would support, I call the "piggybank protocol". It has four key elements:

- hardware key storage, iphone/TPM style

- mechanism for the manufacturer to authorise key release from a device

- important 1: this process should be irreversibly tamper-evident, such as IC "fuses" or one-time PROM. This should be permanently visible in the UI, so it cannot be applied invisibly.

- important 2: an obligation on the state to pay for replacement devices which have been compromised in the previous step but not used in court. This is to prevent it being routineised.

How would tamper evidence help if the device is stolen?

If nobody but me has the device encryption key, and my device is stolen, I can be sure that nobody will have access to whatever data it contains. If anybody else has the device encryption key, however, and the device is stolen, I can no longer know whether anybody else had access to the data, no matter how much tamper evidence the device has.

In general, I agree. However, as a mild counterpoint, I present Dual_EC_DRBG, where the NSA inserted a private kleptographic backdoor into the standard via the conveniently provided P and Q points.

Brilliantly awful.

You realize, of course, that, of your two choices, the DOJ would probably choose the former (i.e. general insecurity).

Dual_EC_DRBG was demonstrated not to be secure, so it does not support your point.

Again, any government backdoor = security failure and there is no way around this.

First off, I agree that, in principle, a backdoor is a backdoor, and vulnerable is vulnerable, period. However, there's A5/3 weak, where everyone can hack it, and there's Dual_EC_DRBG, where the right secret is necessary.

What was interesting about Dual_EC_DRBG was that the default points served as sort of a secret master key to generator state leakage. It was harder than usual for another party to gain illicit access, leaving the vulnerability largely in the hands of the NSA.

It was some pretty interesting math, harder for unintended (by the NSA) people to take advantage of, and still, of course, a crippling vulnerability.

At this point, I'd be hard pressed to trust the NSA with anything security related, as they have demonstrated different priorities.

How was it demonstrated not to be secure?

DUAL_EC is also a bad example, as demonstrated by the Juniper ScreenOS incident

Yes, and it appears that our government has chosen #1 for us.

That's wrong. Encrypt all necessary data with government-controlled public key. Government can get in, but hackers can't.

That’s an insecure system. All Eve needs to do is get hold of that third-party key. It’s like requiring all homes to be master keyed with a key held by the police - you need to find an officer willing to take a photo of the key for a few thousand dollars and now you can get in to any house.

Any plan that relies on NOBUS ("NObody But US") information - like a global private key - is a brittle design that will fail catastrophically when the keys become public (either Snowden-style, or accidentally disclosed like the TSA master keys[1]). Why should we ignore prior experience and assume such an important, linchpin secret will somehow stay known to "nobody but us" this time?

[1] https://boingboing.net/2015/08/21/make-your-own-tsa-universa...

Google HTTP security relies on Google TLS private key. Does it make a brittle design? Keys are supposed to be protected. In this case key could be assembled by a few subkeys with different people holding control over it, so they should come to an agreement before deciphering anything.

Yes it relies on Google keeping their key (or keys - there's nothing wrong with having multiple valid certificates for a domain, especially if you're the registrar) private. Google keep their key private, Amazon keep their key, Stripe keep their key. If you want to attack any provider you have to recover that provider's key.

Now if you mandate everyone use a government key or escrow their key with the government there's now a single place to attack. Also this place is affected by government whims, staff pay freezes, cutbacks, layoffs. All you need is one disgruntled employee or contractor with access and you now have access to _everything_.

Even assuming this is possible, which it isn’t, whose government would hold whose keys? It’s not like there’s one government and there isn’t international crime

US for US companies, China for Chinese companies. May be some kind of union.

So what happens when a chinese company hack into an american company, steal some industrial secrets and save them on their encrypted servers?

This isn’t some hypothetical scenario either http://time.com/106319/heres-what-chinese-hackers-actually-s...

What about multinationals? What about subsidiaries, like a Brazilian company which is fully owned by a USA company? Who would get the key, Brazil or the USA?

That's wrong. Insiders can leak the private key, or hackers can take it.

Or a contractor can take it home, against policy of course, and then it gets submitted to an online anti-virus scan.

Or it gets left on a USB key in a taxi

Or it gets left on an un-scrubbed laptop that's put up for government auction.

Or any of the other which-ways that humans get around policy limitations that don't have technical barriers, or socially-engineered to get around the technical barriers.

Or the government can leave it behind their remote servers along with their cyber weapons for anyone to wander by.

Or anyone who is willing to spend enough computational power now only needs to crack one key instead of millions of different ones.

If there's anyone who can have enough computation power to break key, then that key is weak and its size should be increased.

One can only make keys so large to be useful—my point is the same, still, that one would only have to break/find/buy/steal a single key instead of millions.

Everyone can leak the private key. That's not a concern of secure protocol. Of course there should be means to migrate to new key if that happens. Important keys are unlikely to be leaked.

>Important keys are unlikely to be leaked.

The more important the key, the more sought after it will be by hackers, especially one which could theoretically decrypt an entire countries communications. It's only a matter of time.

Decss again