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.

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.

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.

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.

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.

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.

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

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

I for one would be shocked.

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.

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.

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.

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?

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.

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.

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.

"(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%...

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 law simply does not require Google, Microsoft, &c to implement key escrow, and so far as I can tell, those companies don't.

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.

"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.

CALEA does not apply.

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."

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 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.

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...

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...

"Give me links as proof"

[Downvote them and not reply]

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

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.

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 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.

> 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.

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! ;)

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.

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.

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.

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.

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."

* 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.

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."

Please.

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

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

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

Keyword: might.

"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.

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 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.

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.

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

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

We get it.

Key escrow can be key escrow for everyone.

Grandma gets her copy and so does Big Brother.

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.

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.

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

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. :)

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.

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

The stated reason was FIPS compliance.

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?

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.

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).

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.

* 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.

> 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.

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/bswum0iz8ggfheo/Screenshot%202014-...

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.

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

Maybe you could reply to the others.

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

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.

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