Hacker News Reader

Roughly paraphrased: "We don't care what kind of lock you build, so long as you build one that you can always unlock for us. We're not mandating any particular design, but you have to unlock it on demand."

That's not really a lock, then, is it?

To be fair, it's exactly a lock, well understood and easy to circumvent (like the keys to your house).

And just like the keys to my house, it requires an actual live physical human being to transport itself through meatspace at a non-relativistic speed in order to perform said circumvention, right? Oh, it doesn't? Hmmm.

This is why I'm hoping we can ultimately just let go of all these analogies for encryption. Analogies are training wheels, and if we leave them on for too long, we risk propagating the idea that all bikes have four wheels.

All models are wrong. Some models are useful.

Analogies are models.

Analogies are pretty much precisely how we convey novel ideas. The problem is finding one which doesn't melt when pushed too hard.

I keep having to explain to my father that deleting data from storage doesn't speed up computers. Nor does leaking it. His response when I mentioned that the Panama Papers leaks were 2.6 terabytes of data was "well, that must have made their systems a lot faster" (because they were no longer bogged down by having 2.6 TB of data on them). That's wrong at least two ways: data-on-disk doesn't slow down computers, and leaking data (making a copy) doesn't remove it from the source.

And this is a reasonably intelligent human being. Who's used computers for many decades.

What do you mean "deleting data from storage doesn't speed up computers?" Deleting old files certainly makes file searches faster.

The context was of speeding other computer operations by removing data.

With a sufficiently robust indexing system, file search time is independent of corpus size. E.g., Google isn't scanning the Internet each time you submit a search query. Time to build an index increases, but not searches against it.

You are technically correct, but the comment is irrelevant to the discussion.

It's the crypto equivalent of the TSA-approved locks.

And just like TSA locks, the bittings will leak, rendering the lock useless to all but the laziest adversaries.

What do you mean 'will leak'? You can find pictures of the master keys online today.

I think the TSA locks are a great example of why backdoors are completely idiotic.

That was exactly my point. The TSA lock bittings are available and the back door keys will be available shortly after instituted.

Think about the threat model for a lock on a suitcase. The adversary must have your bag in their possession. It's the perfect example of something that's only to keep honest people honest. Also, they make sure that your bag stays closed.

Does anyone actually use a suitcase that while locked with any padlock can't be opened with a pen?

Unless the lock is secured to something other than the zipper you can resecure it invisibly too.

It's a TSA-approved lock for encryption instead of luggage.

And just like with TSA locks, there will be leaks and compromised systems that only hurt the general public.

It worked for the TSA.

And as a result, the TSA destroyed a hot sauce boxed set I had in my luggage.

I learned my lesson; now I just buy new clothes/toiletries/etc. at my destination rather than take anything at all with me.

Another option is to start flying with something that qualifies as a 'firearm' in your luggage. Such requires actual proper locks that only you can open. There was a talk on this at DEFCON 17 https://www.youtube.com/watch?v=KfqtYfaILHw

Obviously, this only works in the US. Other countries will have different laws on the ownership and transport of firearms.

Only in the USA does taking a gun with you make the airport easier.

Pro tip: pack the gun at home.

The other complications surrounding that would make this option more trouble than it's worth for me. I'll stick with the no-luggage route!

It seems consistent with statements by Clinton and other government officials, "Maybe the back door isn't the right door, and I understand what Apple and others are saying about that. I just think there's got to be a way, and I would hope that our tech companies would work with government to figure that out." They create the requirement and tech companies have to find the least bad way to comply.

I wonder what that means for software like Google Chrome. Chrome would need to send the parameters of every SSL session to Google on the chance that the FBI requires Google to decrypt it.

Think what it does for all the creditcard companies. The TLS stream contains also those nice back-of-the-card control numbers that card processors are not allowed to store.

Subsection (c) says it must be possible to comply with subsection (a). That subsection requires companies either to decrypt or to help decrypt. Technically, you don't have to successfully decrypt so long as you can help try. That's almost certainly not what they me at to write, but that's what the draft says. It's a badly drafted bill for more than technical reasons.

> Technically, you don't have to successfully decrypt so long as you can help try.

Which raises the question of whether a vendor could build a system they cannot themselves break into, and then "help" by providing the documentation showing how they've built the system (which they should post publicly anyway).

Still a bad bill for numerous reasons, of course.

> a provider of remote computing services to the public shall ensure such products are capable of complying with a court order to decrypt.

I'm not well-versed in these things at all, but I wonder what implications this would have on VM providers like Amazon (EC2) or Google (GCE)? Does this mean they somehow have to magically ensure that you didn't install sshd on your Linux VM? Surely that can't be the intention (?), but the broad language is scary.

And here's a Tesseract+corrected transcript: https://lin.noblejury.com/burr.txt

Cleaned up: http://pastebin.com/raw/PrXTrc2N

You slightly misquoted (b) - it says that nothing in this act may be construed to authorize any government officer to require or prohibit any specific design or operating system. I think it's meant to avoid a situation where regulators would have lists of specific software that is required or prohibited, as opposed to the government suing companies on a case by case basis if their software didn't comply with (c).

It appears to be based on a clause from CALEA, which refers to "any law enforcement agency or officer" - see (b) (1) in:

https://www.law.cornell.edu/uscode/text/47/1002

I almost want this to happen, simply because it only applies to "remote computing services".

It would provide a major incentive to move anything security-relevant back to the endpoints where it should be in the first place.

This bill covers anyone who does things with data or makes something that touches data.

If you make paper shredders, you are covered under this bill.

If you handle data, you need to make sure things like your fire suppression system doesn't damage it.

The bill does not care how the data is rendered unreadable to law enforcement. It only cares that you provide them with a readable copy if it was rendered unreadable by anything even remotely in your control.