Hacker News Reader

Comment by gluczywo | Hacker News Reader

"the fundamental reality of encryption (...) is that the person who is using encryption (...) cannot read it either unless the key is put in some point. (...) Even when your phone is encrypted locally, when you are looking at the secret picture, if the picture is visible to you it's because that picture is decrypted. (...) What this means is that even heavily encrypted communication is vulnerable to traditional means of investigation."

I'm a strong believer in crypto as the liberating technology, but this quote is a wonderful Devil's Advocate argument that dispels hackers crypto dreams.

View on HN

> a wonderful Devil's Advocate argument that dispels hackers crypto dreams

I think most hackers understand this. Turned around, it's the basic argument against DRM - that for the 'consumer' to access the content it must be unlocked.

Yeah the most restrictive form of DRM in the world means nothing if I can just record a video of it / transcribe it

Well it involves a generation loss

Until recently that was the norm and usually the information survives such copying for several generations before it becomes unusable.

And furthermore, most content businesses is facing a reality where they are having a hard time getting users to pay more for higher quality versions, yet the higher quality versions exists. If users have to settle for "only" DVD quality rips of content ripped from Bluray, for example, most wouldn't care.

That problem is going to make DRM increasingly pointless with pushes for 4K and beyond.

This has always been acknowledged by the hacker community as the Analog hole: http://en.wikipedia.org/wiki/Analog_hole

Also: https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis

It's good to see the concept was named. Having a name for idea empowers.

While the hypothetical defense (in the privacy protection context, not DRM) to close the Analog Hole would be to train human brain to make it consume encrypted stream and decrypt inside the skull, I'm disappointed to see that the trend is reverse. It's a pity that the above term is not brought about when discussing keepass/lastpass kind of tools that IMO do a disservice to personal security. They perversely expose your entire secret space to be vulnerable to Analog Hole.

I know it sounds like dangerously off topic but I feel that the "Snowden case" begs the call for action. Snowden's response on "how to defend yourself" in June 2013 was: strong cryptography. Today his stance is less optimistic since encryption is never really end-to-end. That's why secret management seems to be the paramount issue of individual protection against totalitarian state.

Convenience-over-security services don't make a good job here.

You may be getting hung up on this concept a little too much.

Of course, using a password manager increases the attack surface in that if the encrypted passwords are stored on a server and the encryption wasn't good enough you're in trouble. But what you're talking about, where the plaintext password must be inserted into the web form, doesn't strike me as a vulnerability that would not exist without the password manager. If you simply memorized it you would still have to type it in. Moreover, keeping the password secret is not an end in itself, it's a tool to keep your actual secrets secret. If you login to some sort of account, and then access those secrets on your computer there's the analog hole again.

If you don't have a computer on which it's safe to type in a password you don't have one on which it is safe to read or view your secrets.

CALEA, the Stored Communications Act and Section 215 of the Patriot Act all compel corporations (via the Department of Commerce) to build data and key escrow services into their products.

For example on modern Windows systems bitlocker keys are automatically uploaded to the (automatically created for you) Onedrive account associated with the Microsoft Account created during your install and Onedrive is on PRISM.

Searching for 380/286 classification patents in the US is one way to figure out some escrow mechanisms and companies, though it is not exhaustive nor does it only include federally-inspired escrow.

All of this is remnants of the Clinton Administration and alternatives to the failed Clipper Chip, then increased in scope by the Bush and then Obama administration. There's a decently history that only captures the broad strokes up until the late '90s here:

http://www.foia.cia.gov/sites/default/files/DOC_0006231614.p...

CALEA does not require key escrow, nor, so far as I know, does PATRIOT s.215.

From my work I'm personally aware of more than one major corporate effort to cryptographically protect user data for which key escrow was not only not implemented, but countermeasures above and beyond basic cryptographic best practices were implemented to mitigate likely user errors. None of these projects would seem to me to be possible if it were the case that the USG was requiring private companies to implement key escrow.

In ~10 years of software security work performed for many of the largest companies in the world, I was never once asked to review a system that performed key escrow or anything like it (I would not work on such a system, nor would I or will I work on software security for the USG).

Not only that, but having come into contact with source code, design documents, backend systems, and similar intimate technical details, I have never --- that I can recall --- even seen something like the backdoor you alluded to.

Occam's Razor suggests to me that the popular idea that big tech companies spy on their users for the USG is fallacious.

I've never looked at Bitlocker, though, so maybe I'm wrong.

CALEA requires a guarantee that customer traffic can be decrypted.

S215 of the Patriot Act extends the larger body of the act and prior Acts to include "other artifacts". Though not specified, this presumably extends outside telecommunications. The Stored Communications Act similarly requires key (or data) escrow mechanisms.

Here is a Microsoft Cloud Key Escrow system that

"Once a request comes in from a third party (e.g. a user, a business, a legal entity or governmental entity, etc.) to access user's data, the data storage system may send..."

https://www.google.com/patents/US20120321086

Please cite the portion of CALEA that requires commercial enterprises to subvert encryption in any way, key escrow or otherwise.

Let's try Title 47, Chapter 9, Subchapter I, § 1002. The whole subsection is good but calling attention to (b)(3):

"(3) Encryption

A telecommunications carrier shall not be responsible for decrypting, or ensuring the government’s ability to decrypt, any communication encrypted by a subscriber or customer, unless the encryption was provided by the carrier and the carrier possesses the information necessary to decrypt the communication."

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

Here's the Wikipedia article:

"The Communications Assistance for Law Enforcement Act (CALEA) is a United States wiretapping law passed in 1994, during the presidency of Bill Clinton (Pub. L. No. 103-414, 108 Stat. 4279, codified at 47 USC 1001-1010). CALEA's purpose is to enhance the ability of law enforcement agencies to conduct electronic surveillance by requiring that telecommunications carriers and manufacturers of telecommunications equipment modify and design their equipment, facilities, and services to ensure that they have built-in surveillance capabilities, allowing federal agencies to monitor all telephone, broadband internet, and VoIP traffic."

https://en.wikipedia.org/wiki/Communications_Assistance_for_...

Here's a checklist for CALEA:

http://transition.fcc.gov/bureaus/pshs/services/calea/CALEA%...

"unless... the carrier possesses the information necessary to decrypt the communication."

That is, if a company is running a key escrow, then it is required to decrypt information for the government. But it's not already running a key escrow, there's nothing in the section you cited that requires it to.

The parent comment asked about "subvert encryption in any way, key escrow or otherwise".

CALEA relies on voluntary key escrow which essentially all major information providers have been willing to provide (see Snowden leaks).

Voluntary only exists where incentives allow a full reasoned decision to be made by corporations.

Look at the fines that Yahoo was forced to face on a daily basis for not providing the information requested by the government. Look at how QWest was unraveled.

Soft power, financial leverage, standards manipulation, other laws and legal requirements (law praxis) - including those mentioned in the parent comments (ignored thus far by downvote brigade), executive orders and others effectively require key escrow. All major telecommunications carriers have been onboarded to 'voluntary escrow' in this regard.

The presumed 'big news' being that Apple and Google providing escrow-less cryptography directly implies that there was key escrow before (there was encryption present before, but no law enforcement condemnation).

I encourage readers of these comments to chase the provided links and information, as well as the fully body of knowledge leaked by Binney, Snowden and others, to bear on the 'truthiness' of this comment thread.

The "big news" wasn't that they are "providing escrow-less cryptography" but that iOS 8 added full-disk encryption and that Android 5 turned full disk encryption on by default. They never had access to the encryption keys. On iOS 7 and earlier, Apple could extract data from native apps "for which the data is not encrypted using the passcode." http://images.apple.com/privacy/docs/legal-process-guideline...

Nah that's not right at all.

The big news was in fact that they would be providing end-to-end encryption with the claim that they 'do not have a key and so can not comply with key requests.' Find me some articles that don't center around the issue of law enforcement getting keys.

Encryption, including by default and including FDE existed before this year. That's not the news.

Any HN reader reading this can confirm this is the case with a few quick searches around the use of full disk encryption and encryption in general in Google and Apple.

I've read this comment three times and I can't find anywhere inside of it any testable claim. You started this thread very authoritatively, but at this point instead of providing evidence or even authoritative cites, you're asking people to search the trade press to confirm your arguments.

Your claim at the top of this thread was that companies like Microsoft (presumably also Google, Dropbox, Apple, Stripe, Mozilla, Facebook, LinkedIn, Samsung, &c) were legally compelled to implement --- your words --- key escrow. Even if we charitably defocus that argument to cover not just literally key escrow but any cryptographic or security UX property meant to reduce security or provide lawful intercept capabilities, I know that claim to be false.

I'm eagerly awaiting actual evidence from you to back your claim up, because if you're right, I'm profoundly wrong about something. I doubt you're right, but the risk/reward on wasting my time versus a life-changing revelation work out for me to keep participating in this discussion.

> I know that claim to be false.

Bollocks. But let me ask you this: have other incentives - non-legal ones, even personal whim - enticed any of these companies to provide key escrow for the US government? What is the current policy climate with this regard? Is there a voluntary key escrow program? How many companies are on board it? Is there a single telecommunications provider that -isn't- providing key escrow?

I can't find a testable claim anywhere in your comment. That's not a ding, it's merely the usual nature of HN comments. It is a sort of foul play to selectively apply criteria.

Here's a testable claim. If a HN participant does independent research on the Apple and Google encryption news recently (not you or me or lern_too_spel), that participant will find that encryption is not new nor the thing that law enforcement are critical about. They will find that there is a long history of FDE on Android and on Apple and on other products. They will find that both Apple and Google declared that they would provide encryption mechanisms that they would not have access to decryption keys for. They will find that this causes a ruckus at the FBI and other law enforcement.

This is a testable claim. Not testable by you or by me. But it is testable by other readers. They should do it for themselves.

The quality of my posts are not in question. I highly encourage readers to wade through my comment history (and that of 'xnull' as well) to links interesting and relevant to the current state of cybercontrol.

Yeah, OK. I think I understand the dynamics of this thread now.

I don't think that's fair as I could say (and refrained from) saying the same thing earlier.

The facts stand on their own.

I encourage anyone who makes it to this comment-leaf to investigate the facts for yourselves. Neither I nor Tptacek are pseudonyms you can trust.

I think you can trust that my name is actually Thomas Ptacek.

And that mine is not actually Xavier Null.

I pointed you to a primary source for Apple. Here's a secondary source for Android: http://www.washingtonpost.com/blogs/the-switch/wp/2014/09/18.... Once they push the new release to the public git repository, I can give you a zeroary source by pointing you to the actual commit. You don't even have a secondary source to back up your fantastic claim.

I see I've interacted with you before with the same result. I'll give you the same ultimatum I gave you then. Provide a source now, or stop repeating this nonsense.

I'll reply the same way as before (likely to end with the same result). Here is a much, much better source.

Apple's announcement itself:

"Unlike our competitors, Apple cannot bypass your passcode and therefore cannot access this data. So it's not technically feasible for us to respond to government warrants for the extraction of this data from devices in their possession running iOS 8."

https://www.apple.com/privacy/government-information-request...

"Specifically, Apple has radically improved the way that data on those devices is encrypted. Once users set a passcode, Apple will no longer be able to unlock your device—even if ordered to do so by a court."

http://www.slate.com/articles/technology/future_tense/2014/0...

"To get started, it's worth pointing out that disk encryption is hardly new with iOS 8. In fact, Apple's operating system has enabled some form of encryption since before iOS 7. What's happened in the latest update is that Apple has decided to protect much more of the interesting data on the device under the user's passcode.

...

So to a large extent the 'new' feature Apple is touting in iOS 8 is simply that they're encrypting more data. But it's also worth pointing out that newer iOS devices ... also add substantial hardware protections to thwart device cracking.

In the rest of this post I'm going to talk about how these protections may work and how Apple can realistically claim not to possess a back door."

http://blog.cryptographyengineering.com/2014/10/why-cant-app...

None of your quotes from Apple support your claim that they were able to decrypt encrypted data before. And in fact, I gave you a source right from Apple that said they couldn't -- the very document they give to law enforcement.

http://i.i.cbsi.com/cnwk.1d/i/tim/2012/04/02/police.apple.pn...

http://www.cnet.com/news/apple-deluged-by-police-demands-to-...

http://www.cnet.com/news/how-apple-and-google-help-police-by...

http://boingboing.net/2013/05/12/apple-can-decrypt-iphones-f...

http://www.theguardian.com/world/2013/jun/06/us-tech-giants-...

http://hbpub.vo.llnwd.net/o16/video/olmk/holt/greenwald/NoPl...

Haha, same thing as last time.

"Give me links as proof"

[Downvote them and not reply]

It's okay. Other HN readers know what's up.

I didn't downvote them. You can verify that I don't have enough karma to do that.

If I had to guess why you've been downvoted, I'd guess it was because you keep posting links that don't support your claim, wasting everyone's time.

Also, this is much different from last time. Last time, you didn't bother to post any links at all, even links irrelevant to your claim.

How is an article titled "Apple can decrypt iPhones for cops; Google can remotely "reset password" for Android devices" a waste of people's time? What sort of proof do you want exactly? Are you looking for a PR statement from Apple that says "we regularly decrypt your data and have backdoors build in and escrow worked out so that we can comply with law enforcement?"

You aren't going to get a nice first party source, although Apple has essentially admitted to it.

Apple says that "For all devices running iOS 8.0 and later versions, Apple will no longer be performing iOS data extractions as the data sought will be encrypted and Apple will not possess the encryption key."

You're going to interpret that as "oh hah, well some of the data wasn't encrypted before". But I included links earlier showing how Apple's (and Google's) announcement centered around the use of new technology that would not allow Apple to have a copy of the key. And if you look at the data they were pulling off, there was data that was 'encrypted' before but had engineered circumvention - 'active data' being one.

Apple will (currently) decrypt data it has in iCloud for a device. It is engineered to be very difficult to not store data in iCloud [1]. Apple's own list of information that may be in iCloud include "stored photos, documents, contacts, calendars, bookmarks and iOS device backups. iOS device backups may include photos and videos in the users’ camera roll, device settings, app data, iMessage, SMS, and MMS messages and voicemail."

https://news.ycombinator.com/item?id=8522316 for more.

Re: last time. I pointed to other areas of the thread, where plenty of sources were given.

[1] http://mjtsai.com/blog/2014/10/26/yosemite-uploads-unsaved-d...

The second part of your post shows you're starting to understand that Apple doesn't do key escrow and can't decrypt data encrypted with the passcode today or ever before. You go off tilting at windmills to show that they can get data stored in iCloud. That was never in doubt. This whole thread has been about whether they have the keys to decrypt encrypted data on the device. They don't.

> Apple ... can't decrypt data encrypted with the passcode ... today or ever before.

The passcode of 12 bits...

Apple can and will provide ciphertexts, will hand over copies of the large amounts of data customers are encouraged and sometimes forced to upload.

> This whole thread has been about whether they have the keys to decrypt encrypted data on the device. They don't.

From the top of the post: "CALEA, the Stored Communications Act and Section 215 of the Patriot Act all compel corporations (via the Department of Commerce) to build DATA AND key escrow services into their products."

What you're saying is that they don't provide key escrow specifically (while wholly ignoring data escrow). What I'm saying is that by design the crypto doesn't matter in practice and the system had been (still is) architected to allow for data intercept.

When you argue the 'no key escrow!' case you are implicitly condoning 'they won't hand over your data!'.

Not true. It was the case and _still is_ the case that Apple and its manufacturers will give access to your private communications, metadata and data.

We've focused on Apple but Google is not different.

Look up what "condoning" means. It does not mean what you think it means.

> The passcode of 12 bits...

Even the weakest passcode option is more than 13 bits, but neither Apple nor Google restricts you to such short passcodes.

> [CALEA nonsense]

How many times do people have to tell you that CALEA doesn't apply in this case? Don't you find it suspicious that Apple and Google are essentially claiming to be flouting your imaginary version of CALEA, and nobody has called them on it except you?

> Google is no different.

Exactly. They don't provide the government with decryption keys either.

It's been fun, but you'll have to argue about imaginary laws, black helicopters, chemtrails, and ice bullets with your fellow conspiracy theorists. If you won't trust primary sources and common sense, there's nothing more I can do.

> Look up what "condoning" means. It does not mean what you think it means.

Whoops typo. Care to respond to the spirit of the argument, rather than its letter?

> Even the weakest passcode option is more than 13 bits, but neither Apple nor Google restricts you to such short passcodes.

Care to break down the entropy of user supplied passcodes? Does it surpass 80 bits? No. 12, 13, 14, 24, 50? At that complexity it's all the same to law enforcement.

> > [CALEA nonsense]

Nah, I was quoting the top of the thread and capitalizing "DATA AND key escrow" in response to "This whole thread has been about whether they have the keys to decrypt encrypted data on the device. They don't." It hasn't been wholly about whether they have the keys, but whether they can get the data. Keys are one way to do this. Brute forceable keys are another. Data backups are another. Broken crypto is another. Etc.

The thread has not been about whether they have the keys - but whether they work with law enforcement to create systems can be subverted, either by creating ineffective crypto, crypto with low entropy or controlled keys, key escrow or direct data escrow.

The other point was to remind you that the topic is about more than CALEA, but in fact other laws (and interpretations thereof). You're the one who has tried to make the focus about CALEA in isolation.

> > Google is no different.

> Exactly. They don't provide the government with decryption keys either.

Right, but they do provide _data escrow_ and mechanisms to defeat in place on-device crypto (such as access to data backups stored in the cloud).

> It's been fun, but you'll have to argue about imaginary laws, black helicopters, chemtrails, and ice bullets with your fellow conspiracy theorists. If you won't trust primary sources and common sense, there's nothing more I can do.

Straw men. All of it.

I directly quoted (this is just one example) from primary sources the policies in place today that provide data escrow. I also discussed the backdoorable design of the Secure Enclave using primary documents.

Common sense is something every man thinks he has a monopoly on. It is for neither of us to decide if the other has it (for I would be prone to say the same).

I'm sorry to hear that you are done contributing - there's so much left in the thread that was never challenged. I found the conversation very valuable as it has provided (at least me) a good opportunity to dig up additional sources and has provided a stage for dissemination of information to broader eyes.

I'm very glad that the discussion is in public record, and that other HN readers can access this information, do their own research, and decide for themselves.

See you around the next Snowden thread! ;)

From your own document.

"For all devices running iOS 8.0 and later versions, Apple will no longer be performing iOS data extractions as the data sought will be encrypted and Apple will not possess the encryption key.

For iOS devices running iOS versions earlier than iOS 8.0, upon receipt of a valid search warrant issued upon a showing of probable cause, Apple can extract certain categories of active data from passcode locked iOS devices. Specifically, the user generated active files on an iOS device that are contained in Apple’s native apps and for which the data is not encrypted using the passcode (“user generated active files”), can be extracted and provided to law enforcement on external media.

Apple can perform this data extraction process on iOS devices running iOS 4 through iOS 7. Please note the only categories of user generated active files that can be provided to law enforcement, pursuant to a valid search warrant, are: SMS, iMessage, MMS, photos, videos, contacts, audio recording, and call history. Apple cannot provide: email, calendar entries, or any third-party app data."

I can see how you read this. I read it another way. There was encryption on the device, but it was circumvented in iOS4 through iOS7 (so called "active data") so that law enforcement could access it (over snailmail). The implication is that 'active data' persists longer than the alivetime of the device.

"It is further ordered that, to the extent that data on the Device is encrypted, Apple may provide a copy of the encrypted data to law enforcement but Apple is not required to attempt to decrypt, or otherwise enable law enforcement's attempts to access any encrypted data."

I can see how you read this. I read it another way. Many of the CALEA programs allow businesses to 'volunteer' data or to volunteer to decrypt information. They've been bullied into doing this. Apple says that it will take a stand, but I don't have very much trust in them because them ultimately is a board of directors chasing profits.

"iCloud only stores content for the services that the subscriber has elected to maintain in the account while the subscriber’s account remains active. Apple does not retain deleted content once it is cleared from Apple’s servers. iCloud content may include stored photos, documents, contacts, calendars, bookmarks and iOS device backups. iOS device backups may include photos and videos in the users’ camera roll, device settings, app data, iMessage, SMS, and MMS messages and voicemail. iCloud content may be provided in response to a search warrant issued upon a showing of probable cause."

iCloud data syncs by default. That is, they've added data encryption to singular devices but placed the data by default into their cloud, where they offer decryption for law enforcement.

You've read it in a nonsense way. Prior to iOS 8, only certain data was encrypted on the device. Apple did not have the keys to decrypt that data, nor did law enforcement. After iOS 8, they implemented full disk encryption like Android and continued to not have the keys to decrypt encrypted data.

CALEA does not apply.

Prior to the "Secure Enclave", only a very small amount of certain data was encrypted on the device (past the alive-time of the device and where data _could have been encrypted_), the encryption keys were based on information about the device that Apple knew or were accessible through access to the device (which Apple would provide) in tandem with ~12 bits of entropy provided by the user, and Apple served up encrypted data as well as unlocked the device and provided unencrypted data for law enforcement.

Now that Apple does not have access to the UIDs built into the "secure enclave" they can not provide decrypted content directly. However they will still hand over encrypted data and manufacturers do have these UIDs. The user can still provide ~12 bits of key entropy.

Apple currently makes it extremely difficult not to store most information on iCloud, sets the default to store data on iCloud, and this data is provided to law enforcement. This data is encrypted but Apple will decrypt it for law enforcement.

CALEA (and others, as discussed in the thread) _do__ apply. It's why Apple needs to claim that they don't have the keys "unless ... the carrier possesses the information necessary to decrypt the communication."

CALEA does not apply to Apple. When you read a US law, you should start with the "Definitions" section. The definitions in a law are binding.

CALEA also doesn't apply to software companies; the law explicitly distinguishes between "telecommunications carriers" and entities providing "information services."

The law simply does not require Google, Microsoft, &c to implement key escrow, and so far as I can tell, those companies don't.

What you are citing actually supports tptacek's claim that there is no law requiring key escrow or other means of circumventing encryption. That appears to be true.

But it makes it all the more surprising that none of these companies supports user-controlled keys, convenient and trustworthy key exchange, and end-to-end encryption for their storage and communications products.

Why does that surprise you? Virtually nobody who uses these products wants to use user-controlled keys. Corroborating evidence: compare the success of web-based encrypted chat products (which people who pay attention know don't actually work) to native encrypted clients that do provide end-to-end security. Or compare the adoption of WhatsApp to that of, say, TextSecure or ChatSecure.

You have a point regarding real-time communication. As long as users can be confident ephemeral keys can't be compromised, they are far easier to use. But what about store and forward communication, and storage?

But you could also say that ephemeral keys are user controlled to the extent they are exchanged end-to-end and the conversation can't be evesdropped.

Your objection amounts to saying "We don't have easy, trustworthy key exchange backed by a web of trust."

There are three keying regimes I can see in common use:

* Key continuity (a la SSH)

* Web of trust (a la PGP Keyservers)

* PKI (a la SSL CAs)

Of these three, only key continuity appears to work in practice.

I'm eagerly awaiting the UX invention that somehow merges continuity and web-of-trust to make the latter tractable.

I'm definitely not complaining that there's no web-of-trust, since I don't believe in it as a workable UX solution for normal people.

Those are very fair points regarding UX.

I believe the mainstream Web services hold the key (no pun intended) to UX for web-of-trust key exchange. Their users have access to real time communication which would make subverting key exchange and key signing hard, and building a Web of trust convenient, including key replacement, etc. The secure specialty services don't have that capability, and so they remain privacy-for-wonks.

I'm certainly willing to consider that I could be wrong about that. But with trust in short supply, someone should be tempted to build products that say "Trust no central authority, trust this math and the open code that implements it."

The commenter may be referring to CALEA loosely and referring to the secret interpretation of S215 of the Patriot Act.

If PATRIOT compels commercial enterprises to subvert cryptography, how is it possible that huge companies have built sturdy end-to-end encryption systems without key escrow? Are some of the largest companies in technology simply flouting the law?

I wasn't personally suggesting that PATRIOT specifically compelled commercial enterprises to subvert cryptography, and we know from what's been leaked about BULLRUN that at least some of the times that those activities occur, it's probably been upstream during (for example) standards development.

It may, however, still be the case that PATRIOT creates a legal authority from which multiples agencies might ask companies to undermine some of the goals of cryptography--depending on your politics and your vantage point--to be able to profile lawful intercept capabilities, e.g. by offering unmonitored access through something like Google's eDiscovery portal or just by complying with legal requests.

I'm not commenting to defend NSA or, for that matter, cryptographic standards efforts. So: much of this comment is unresponsive to mine.

What I'm interested in is, what's an example of some authority of PATRIOT compelling a commercial enterprise to weaken or subvert their cryptography or, as you put it, the goals of their cryptography? Be specific, please. This thread lead off with a truly wacky and false claim about compulsory key escrow. I'd prefer not to see it rehabilitated by a flight to abstraction and appeals to our shared dislike of NSA.

I tend to think you're right and that we live in a world where key disclosure and various other methods of obtaining information from companies would be much more common than key escrow, especially key escrow implemented in response to a specific government request. I believe affected companies/people are typically gagged from discussing or even acknowledging the existence of--for example--an NSL demanding user data in the context of PATRIOT.

My understanding was that the government--typically the FBI--could send NSLs to tech companies to secretly demand a broad range of user information, and short of being Tahoe-LAFS and it being impossible to fulfill such a request or being Lavabit and asking for money to build in a backdoor to fulfill such a request, companies had to find a way to comply.

In other words, my understanding was more that PATRIOT created a legal authority that allowed the government to secretly demand user information in ways that made requests difficult to challenge in court or disclose to affected users, and that the technical and other specifics of how to satisfy those requests was typically up to the companies.

I'm not aware of compelled key escrow (but also wouldn't necessarily expect to be given the role of gag orders), but Lavabit might be considered an example of compelled key disclosure. At least technically, that's a very different beast.

> Are some of the largest companies in technology simply flouting the law?

I for one would be shocked.

I walked into that one.

;-)

>huge companies have built sturdy end-to-end encryption systems without key escrow?

I would say that they haven't.

_RSA_, whose only product is sturdy crypto, subverted their products.

I would say that this sentence amounts to an unverified assumption. I can't actually think of an example - can you?

That RSA's only product is sturdy crypto would be news to RSA, which began as a two-factor token company (called SDTI), later purchased the RSA brand, and now sells a gigantic suite of enterprise security and compliance products, along with their flagship multi-factor products. I would be surprised to discover (but have not looked into it) that BSAFE --- the RSA product you're referring to --- was even a rounding error for RSA's revenue.

If the closest you can come to arguing that all commercial tech enterprises are "voluntold" to build key escrow is a crypto library used by virtually no end-user encrypted communications systems, I'm suddenly a lot less interested in this discussion.

I think Dual-EC probably was a backdoor. I think any commercial product that adopted Dual-EC is worthy of suspicion. Fortunately, so far as I can tell, virtually nothing that matters ever used Dual-EC.

Re: RSA having security and compliance products. This comment does nothing to dispel the thesis. RSAs primary business is secure software solutions, a major component of which is sound cryptography.

If the financial kickback to RSA was 'small' (care to post an analysis) then they added the backdoor to BSAFE for other reasons. Therefore I don't think that argument addresses the thesis.

Here are a list of suites NIST validated with DUAL_EC.

http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval....

Plenty of products relied on BSAFE including enterprise security products like McAfee.

https://lwn.net/Articles/566329/

But practical impact aside, you haven't addressed the primary thesis.

Sound cryptography is a tiny, tiny portion of software security. Most software security --- in fact, most information security in general --- doesn't touch on cryptography at all. Certainly most enterprise security and compliance products don't.

Indeed, many random enterprise security products did use BSAFE. Most of them did so because during the mid/late '90s, a BSAFE license was how you shipped certificate-based public key features, because RSA was enforcing their patent. Many of those products include BSAFE on their manifest but use OpenSSL and Microsoft SChannel instead. And the features we're talking about are things like login pages or agent/server communications for things running on 10-net addresses.

How many of those enterprise security products did end users rely on to protect their secrets from the USG? I'm going to go out on a limb and suggest that number is zero.

We are in mostly full agreement on this comment. (I do not think it challenges the thesis.)

Given your reputation and experience, don't you think is it possible that you never saw one because people would know better than to include you in the types of project that include such backdoors?

No.

The difference between "big tech companies spy on their users for the USG" and "big tech companies spy on their users....and then the USG obtains those data through any number of means, legal and otherwise" may not be so sharp and bright outside a comment about the technical details of key escrow (which you're right about, just to be clear).

Being clear on what the technical details of key escrow systems actually are is valuable, but may miss the crux of Snowden's arguments in this conversation with Lessig. Whether the Lavabit case should be construed as a law enforcement request for a mechanism that achieves many of the same goals as key escrow or should be construed as key disclosure points to the same sort of issue.

CALEA is one of many tools to be used and perhaps misused... mass surveillance conducted by eavesdroppers with a legal backing is just as morally wrong as mass surveillance conducted by eavesdroppers without one. Sometimes the scandal is what's legal, and sometimes the scandal is what can obtained without building key escrow systems directly into big tech companies' systems.

Welp tptacek has never seen anything like this so it must be made up!

Obviously tptacek is smarter than the entire NSA. You heard it on HN folks! Nothing to worry about.

No, these people wouldn't know better or no, it's not possible?

> CALEA does not require key escrow, nor, so far as I know, does PATRIOT s.215.

As far as is publicly known, this is correct.

> Occam's Razor suggests to me that the popular idea that big tech companies spy on their users for the USG is fallacious.

But that the second part doesn't, at all, follow from the first.

For example, telcos have spied on Americans for the government since there were telcos. At best, you could argue that the heavy lifting is done in NSA equipment in terms of DPI and word-spotting, etc. But there are plenty of technology companies that are ass-deep in spying on the American people.

I suppose you mean that it isn't obvious that Google and other companies with a strong reputation for being careful with customer data are spying on Americans. OK, it isn't obvious, but let's go back to the first premise: CALEA doesn't require companies to break encryption to make surveillance possible. IF there isn't some hidden agreement about that, why are there exactly zero major services that provide user-controlled keys, end-to-end encryption, and web-of-trust key exchange?

All of these companies could get past any suspicion of surveillance by providing the means to be truly private. None have done so.

Intentionally or, I presume! not, you're "spreading" the debate. It was not my claim that telecom companies didn't help the USG spy on their users. It was not my claim that the controlling interpretation of every security law was public. It was not my claim that NSA is working in good faith with technology.

The claim I was responding to is that CALEA and PATRIOT have the effect of compelling all major US technology companies to implement key escrow or, more generously, some cryptographic or UX compromise with the same effect, in order to effectuate SIGINT.

I know this claim to be false. I said so, and, within the limits of my ability (for obvious reasons), provided my evidence.

If you want to keep talking about how you don't trust tech companies, that's fine by me. We don't have a live argument on that issue; I'm not interested in it.

Well, we know quite well that if a person were to be only interested in the letter of the law - never the spirit, its interpretation, how it is practices, or how it interacts with other laws - and not interested in any channel of information that isn't blessed by a government representative, that there would be a reductionist bias that misses the broader strokes important to understanding current policy.

For those reading it should be clear that the US 'voluntells' US corporations to provide access to information and keys and to build in key escrow mechanisms through regulatory and financial leverage, through partnerships, contracts and kickbacks, legal pressure, and otherwise.

Tap and trace laws force telecommunications companies to subvert over-the-wire encryption - they can not subvert end-to-end encryption because they do not provide it. However Bush era interpretations of tap-and-trace and pen register laws expanded analog and phone communications to digital media. Skype, for example was fully and willingully subverted (Snowden docs, again) - the end-to-end crypto removed from the original versions of the product.

If one enters into these conversations only wanting to examine single sentences of law and not the legal process/architecture, one fundamentally introduce a bias. That's okay (freedom of speech). But readers beware that they aren't going to be able to get a full story from legal reductionism.

> If you want to keep talking about how you don't trust tech companies...

Do you trust all of them? I doubt it. Of course some companies are more trustworthy than others.

My point is that in a time when trust is in crisis, NONE of the major tech companies is providing users with strong tools for privacy that can't be circumvented for law enforcement or spying.

Yeah, this is one of the reasons it's not an interesting discussion for me: it's practically a valance issue. Everyone has a tech company they don't trust.

>For example on modern Windows systems bitlocker keys are automatically uploaded to the (automatically created for you) Onedrive account associated with the Microsoft Account created during your install and Onedrive is on PRISM.

Please.

http://cdn8.howtogeek.com/wp-content/uploads/2014/07/bitlock...

The link you provide is just the manual backup you make. Windows automatically uploads the key to OneDrive. Check it on the link below under "If your PC isn’t connected to a domain" in "How can I get my Bitlocker Recovery key?"

http://windows.microsoft.com/en-us/windows-8/bitlocker-recov...

From that link:

>There are several locations in which your BitLocker recovery key might have been saved.

Keyword: might.

For personal use this is most certainly the case. Here are quotes and links from both Microsoft Technet and tech media coverage.

"Unlike a standard BitLocker implementation, device encryption is enabled automatically so that the device is always protected. The following list outlines the way this is accomplished:

* When a clean install of Windows 8.1 is completed the computer is prepared for first use. As part of this preparation, device encryption is initialized on the operating system drive and fixed data drives on the computer with a clear key (this is the equivalent of standard BitLocker suspended state).

* If the device is not domain-joined a Microsoft Account that has been granted administrative privileges on the device is required. When the administrator uses a Microsoft account to sign in, the clear key is removed, a recovery key is uploaded to online Microsoft account and TPM protector is created. Should a device require the recovery key, the user will be guided to use an alternate device and navigate to a recovery key access URL to retrieve the recovery key using their Microsoft Account credentials."

http://technet.microsoft.com/en-us/library/dn306081.aspx

"... because the recovery key is automatically stored in SkyDrive for you."

http://www.zdnet.com/surface-bitlocker-and-the-future-of-enc...

"BitLocker provides support for device encryption on x86 and x64-based computers with a TPM that supports connected stand-by. Previously this form of encryption was only available on Windows RT devices."

http://technet.microsoft.com/en-us/library/dn306081.aspx#BKM...

Device Encryption is supported by Bitlocker for all major skews including Windows Server 2012 R2.

That isn't Bit Locker, it's device encryption which is supported in 8.1 (Home) and Windows RT where naive users are more likely to forget to backup the key and hence lose data.

BitLocker is only available in the professional,enterprise and ultimate versions of Windows 8.1 and it does not automatically backup the key to an MS account.

http://technet.microsoft.com/en-us/library/dn306081.aspx

Device Encryption is supported by Bitlocker for all major skews including Windows Server 2012 R2.

They have also backported Device Encryption to 8.

Edit: Per your comment below you recognize that it is enabled automatically on PCs - and this is supported by the documentation provided. The grandma argument doesn't stack up with the fact that OneDrive/SkyDrive is enrolled in PRISM.

The big difference is that it's automatic on RT, Phone and 8.1 if the hardware supports it. Think Grandma's PC. Do you really want her to see the option window about where to store a recovery key? For the other SKUs, an option window pops up when you enable BitLocker asking about backup location.

>Edit: Per your comment below you recognize that it is enabled automatically on PCs - and this is supported by the documentation provided. The grandma argument doesn't stack up with the fact that OneDrive/SkyDrive is enrolled in PRISM.

The encryption is automatic, hence it makes sense that the backup is forced. Given that many Windows user get confused when their icons are moved, it would be hard to expect them to manage decryption keys. A significant percentage could lose their data. This is still better than earlier versions of personal use Windows where the data wasn't encrypted at all and all one had to do is to connect the hard drive on a different computer. On Professional and Enterprise versions, when you choose to encrypt, the dialog box with the choice does appear, I just tried.

It does not matter whether a dialog box appears. Have you confirmed that the keys are not pushed into OneDrive? (That's the thing to check.)

So what you are saying is that bitlocker keys are automatically uploaded to OneDrive and OneDrive is PRISM, but this isn't key escrow for government.

The backup can both be for Grandma and Federal Law Enforcement. They are not mutually exclusive.

My original point stands. Modern Windows Bitlocker keys are automatically placed into a location where TLAs can request them.

BitLocker is not the same as Device Encryption. Please stop confusing the two. Also you have been unable to say what you want Microsoft to do in grandma's case.

http://technet.microsoft.com/en-us/library/dn306081.aspx

They are not the same. Agreed. Sorry about the confusion.

Anyway, it's true that modern Windows Operating Systems, even on non-RT devices, upload bitlocker keys automatically and transparently to the cloud, where the data is indexed for the PRISM program. They do this with Device Encryption, which is supported by Bitlocker on x86 and x64-based computers with a TPM that supports connected stand-by.

Edit: Regarding Grandma. Keys can be stored on a non-boot internal drive. Keys can be shown on the screen as a QR code (and the screen can tell Grandma to take a picture). Grandma's keys can be printed out on a small detachable USB or SD/MicroSD device with a kilobyte of space. The machine can provide provisional encryption until Grandma's computer can connect to a printer (where it gets printed). Grandma's computer could send the key over USB/Bluetooth/Wifi to a trusted computer friend after pairing (such as a 'tech savvy' niece/nephew). There are plenty of options.

The 'grandma clause' is not mutually exclusive with key escrow. OneDrive is a nice place for grandma AND a nice place for the FBI.

No it doesn't. The key could be automatically saved in the TPM - locally. Yet Microsoft chooses to save it in its own cloud.

And you could make the same argument against Android 5 and iOS 8 encryption, too. That users won't be able to "recover" their data. Tough luck. Google and Apple did it anyway, and it seems to be a successful move.

Microsoft is now the only one of the three major platforms who doesn't provide secure automatic encryption with locally stored keys.

>No it doesn't. The key could be automatically saved in the TPM - locally.

And how does grandma retrieve it if she forgets her password?

Also, does Apple do this for OS X or just iOS?

Grandma recieves it from the same place law enforcement does.

We get it.

Key escrow can be key escrow for everyone.

Grandma gets her copy and so does Big Brother.

via matthew green recently: So per @justintroutman and now confirmed, Microsoft has substantially weakened its disk encryption in Windows 8. Now uses plain CBC mode.

Yup, the diffuser was removed years ago. The designer of the diffuser removed was Neils Ferguson, the cryptographer who called out DUAL_EC as a backdoor in 2004.

The stated reason was FIPS compliance.

Do you understand what the "diffuser" in Bitlocker was intended to do? Virtually every other mainstream FDE scheme uses XTS, which is also not authenticated; XTS is literally the ECB mode of tweakable block ciphers.

> Do you understand what the "diffuser" in Bitlocker was intended to do?

Yes.

> Virtually every other mainstream FDE scheme uses XTS, which is also not authenticated; XTS is literally the ECB mode of tweakable block ciphers.

Not really relevant?

If you think the point I made about XTS isn't really relevant, I'm going to timidly suggest that you don't actually understand Elephant. I apologize in advance for saying that, but I think it's more productive to be honest than tactful in this case.

AES CBC + Elephant != XTS

Elephant 'mixes' the blocks on a sector level to limit CBC block modification attacks. It does not limit the maximum size to align to sectors. It is not XTS.

Nor is my claim that Elephant is what you want or need. Merely that it was removed, that Ferguson designed it, and that FIPS compliance was the underlying justification.

I didn't say Elephant was XTS. I said that neither XTS --- the industry standard sector-level construction --- nor Elephant actually authenticated sectors.

All three of AES-CBC, Elephant, and XTS fail to authenticate data. This isn't my point; it's Rogaway's, and the opinion of several other people during the XTS standardization process, including Ferguson.

So it's a stretch to talk about how Microsoft "weakened" Bitlocker by removing the idiosyncratic Elephant construction. None of the design alternatives Microsoft had available provided real authentication, and all of them provide adequate confidentiality (to the extent that's possible with sector-level crypto, which is itself just a bad idea).

Couldn't it both be true that Microsoft weakened Bitlocker by removing Elephant AND that AES-CBC + Elephant isn't good enough (e.g. lack of integrity)?

We might discuss how to best design FDE, or whether FDE is what we want.

But that conversation is orthogonal to the fact that AES-CBC is weaker than AES-CBC + Elephant, which is what we are talking about here.

Your criticism comes down to: "CBC + Elephant may be stronger than CBC, but neither are strong enough for me". I agree with this.

Not quite. My high level response to this thread, which opened with a subtextual claim that Microsoft removed Elephant in yet another example of a big vendor being coerced by NSA into weakening end-user crypto, is twofold:

* First, that Elephant does not provide meaningful (and certainly not provable) security improvements, and, put in the context of FDE in general, does not give/remove a Bitlocker capability that other mainstream FDE systems actually have.

* Second, that the clunky feature Elephant tries to provide (Ferguson calls it "poor man's authentication") is in fact not at all relevant to the NSA threat model; to wit: if your adversary has an (a) continuous and (b) active vantage point to hit you from, no FDE solution can help you. FDE is exclusively valuable in the case where your disk is irrevocably and totally compromised, despite the folklore that says otherwise.

Popping up a level further on the stack: I'm rebutting the claim that NSA coerced MSFT into removing Elephant. It was a marginal implementation of a marginal countermeasure that wasn't relevant to NSA.

Popping up a level further on the stack: I do not believe that NSA has within the last decade coerced Microsoft into doing anything cryptographic.

The security improvements due to Elephant certainly are not proveable (what in crypto truly is?). I argue that there is meaningful security added by Elephant, clunky though it certainly is - because it does make block modification attacks (which could be used to thwart "Secure Boot") and in that 'poor man's authentication' is better than no man's authentication. Here the perfect very well may be the enemy of the good. Of course I would be happier with something even better.

> Popping up a level further on the stack: I'm rebutting the claim that NSA coerced MSFT into removing Elephant. It was a marginal implementation of a marginal countermeasure that wasn't relevant to NSA.

Not sure whether this is strong enough evidence to be considered a rebuttal. I do not know and will not claim that it was the NSA (or other) coercing MSFT.

> Popping up a level further on the stack: I do not believe that NSA has within the last decade coerced Microsoft into doing anything cryptographic.

Not the NSA key? Not the removal of end-to-end crypto from Skype and then onboarding of Skype to PRISM? Not the SEA hacking of FBI request documents? Not bitlocker keys automatically uploaded to OneDrive, and OneDrive onboarded to PRISM? Not TPM 2.0 support - not Germany's leak of TPM backdoors - not China's following ban of TPM 2.0 and Windows 8.1 - not Microsoft's then downport of TPM 2.0 support to Windows 8?Not the cloud key escrow patent?

"Once a request comes in from a third party (e.g. a user, a business, a legal entity or governmental entity, etc.) to access user's data, the data storage system may send..."

https://www.google.com/patents/US20120321086

"MS, working with the FBI, developed a surveillance capability to deal with the new SSL... went live Dec 2012" - Snowden docs

http://hbpub.vo.llnwd.net/o16/video/olmk/holt/greenwald/NoPl... (30)

You probably think Microsoft did these things without NSA/TLA coercion.

"What in crypto truly is provable" is where I get off this train.

Hey I love (and defend) crypto but ultimately it relies on (sometimes standard) assumptions like the one-way hardness of discrete logarithms. Symmetric systems hardly have underlying information theoretic garuntees - usually symmetric constructs are based on reductions under random oracle models (which have has its own methodological problems). Furthermore implementations are hardly the same as mathematical constructs, which gives rise to side channels.

These are not controversial views - they are common knowledge among cryptographers.

It is thus an injustice to knock Elephant on 'provability' grounds. The papers for Elephant (and Lion before it) follow standards for peer reviewed work in cryptography.

It is a shame you will not reply to any of the examples in the remainder of the comment.

But other HN readers will see them.

Tiniest violin playing for the loss of another pointless discussion about NSAKEY.

https://www.schneier.com/crypto-gram-9909.html

And the others? Do I get an ORCHESTRA?

Maybe you could reply to the others. Agreed NSAKEY is old news.

NSAKEY isn't "old news". It's a bullshit conspiracy theory. It doesn't even make sense as news.

I understand how you feel about NSAKEY.

Maybe you could reply to the others.

The crypto bit is perfectly reasonable in this context as Elephant meets the standards for crypto publication in this regard. You excuse leaks water.

Where you can no longer reasonably hold your position is where you got off the train.

You've downvoted the content rather than replying to it.

I'll repeat it again, for the benefit of the larger HN community (and you can get you jollies downvoting again).

"MS, working with the FBI, developed a surveillance capability to deal with the new SSL... went live Dec 2012" - Snowden docs

http://hbpub.vo.llnwd.net/o16/video/olmk/holt/greenwald/NoPl... (30)

Microsoft stripped security from newly deployed TLS, worked to undermine TPMs, store copies of your Bitlocker keys for law enforcement, hand cloud data to law enforcement and stripped crypto from Skype.

They either did this all on their own voluntarily, were encouraged or pressured, or where forced. Choose your demon.

https://www.dropbox.com/s/pqy5un1vzcho6a4/Screenshot%202014-...

https://www.dropbox.com/s/bswum0iz8ggfheo/Screenshot%202014-...

Not that you're implying this, but just to be clear: I haven't ever hinted or suggested the NSA had a hand in this. I don't think they did. I can't think of a reason it would make sense. Lastly, I do not think Niels would silently let this happen; he was adamant about this when allegations arose in 2006. Elephant was somewhat of an "edge", even if only a slight one.

What does CBC mode have to do with the security of Bitlocker? Do you think CBC mode is weak because of that god-awful Wikipedia article on full disk encryption? Because that article is god-awful.

I've never used or studied BitLocker and don't have much relevant expertise when it comes to FDE...just was reading comments and was reminded of a tweet that seemed relevant.

It would be really cool to hear what you think of using CBC mode for FDE, though.

I think neither CBC mode nor XTS mode is a great tool for encrypting disks, but rather than restating all my thoughts, I'll just link back to what I wrote about it a few months ago:

http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

But, apropos this thread: the specific claim Wikipedia makes about the insecurity of CBC mode for FDE was debunked by Phil Rogaway, who --- much as I like Justin Troutman --- trumps Justin Troutman. :)

this was an excellent read--thank you

i may have to do some wikipedia editing later today ;-)

I'm okay with being trumped by Phil; that's fair. :)

I'm largely in agreement with you, and I enjoyed your article on XTS. My general thought towards Elephant's contribution to CBC is that it forced coarse-grained manipulation, which is probably a lot more likely to crash a system as opposed to allowing meaningful attacks.

To risk a new design like Elephant implies that they found the attack model worth consideration; we know the rationale for including it, but we don't know the rationale for removing it. Perhaps knowing this would tell us something useful about current perceptions on disk encryption.

Lastly, I echo your disdain for sector-level encryption.

The claim is correct. Bitlocker does this.

CALEA doesn't force tech companies to build backdoors. It forces telecoms to allow for wiretaps. That's why the FBI is pushing so hard for CALEA 2 - to allow backdoors in tech companies' products.

Whether they've already convinced some like Microsoft or Apple or Google to build backdoors for them, that's en entirely different matter. But they are not forced to do it.

I agree with this entire comment, though I would add that the Bush administration expanded telecommunications to include communications over digital switches.

The other thing I would suggest is that convincing rather than forcing is NOT an entirely different matter, as the amount of leverage the United States Government has is insanely high. In practice companies are forced to by overwhelming incentives - legal, financial, and otherwise.

If you are going to provide a wiretap you are going to provide it in the clear. That is a backdoor.

https://en.wikipedia.org/wiki/Third-party_doctrine

I've thought about this a little bit - I guess the security of the system depends on what you consider to be the channel, source, and destination.

The argument is that

|device|-------->network--------->|device|

may be secure, but that doesn't mean

is secure!

Obligatory (somewhat related) XKCD: https://xkcd.com/538/

Reply on news.ycombinator.com