Like I said before guys, start using end-to-end encryption. Stop talking and start sticking it to the man. If a company cooperates with the government, then don't use their products or services.
The man wants you use end-to-end encryption. NIST has been trying to tell you how to do it for years. They even published Suite B to try to get us to use modern crypto instead of the '90s stuff we're using today.
Take, for instance, Skype. It has end-to-end encryption, and call are damn hard to intercept due to p2p routing.
Instead of rejoicing, the man forced MS to build a backdoor into it.
The man is glad if your valuable communication can't be stolen by some Chinese spies. But you are a good citizen and have nothing to hide from your own government, right?
In Russian there's a semi-joking term 'thermorectal cryptanalysys', inspired by a number of gangster stories and movies, which involves a hot soldering iron and... yes, you guessed right.
Beats a compute cluster hands down.
This is why encryption is good against a foreign government, but not as good against your own.
i.e. "the equities issue", which has been debated at NSA for decades. Is it better to strengthen the US civilian infrastructure from foreign attack, or to keep systems weak for (primarily) international intelligence purposes (since they use off-the-shelf US products like Windows and Android), and to a lesser extent, monitoring within the US (for NSA, of foreign entities, although I'm sure they also care slightly for domestic law enforcement's concerns, especially post-9/11 since terrorism within the US blurs the division somewhat)
NSA has a duty to protect American commerce. For example, it is in their best interests that companies like Boeing, Google, and Goldman Sachs are using encryption the Chinese, French, and others can't beat.
If NSA is trying to retard cryptography, why are they getting people to migrate from RSA-1024 to ECC? Can you find a cryptographer that believes RSA is the future?
ECC is a minefield of patents, making it basically impossible to deploy; pushing for ECC does little to advance cryptography in practice. ECC also does not address concerns about quantum computers. In terms of mathematics, ECC is based on a problem that is in the intersection of NP and coNP, the same complexity class as the RSA assumption; there are more modern constructions based on NP-hard lattice problems.
Really, if you want to point to the NSA/NIST helping to advance the state of cryptography, point to the AES contest.
That was true 10 years ago. It is not at all true today. Meanwhile, RSA and simple prime-field DL crypto are the subject of serious progress, while whole avenues of attacks seem to be precluded for the ECDL problem.
"Meanwhile, RSA and simple prime-field DL crypto are the subject of serious progress, while whole avenues of attacks seem to be precluded for the ECDL problem."
When last I checked, the 20-year-old GNFS algorithm was the most efficient way to attack RSA. Yes, this is faster than the best known attacks on ECDLP, but ECDLP attacks are still subexponential. Nothing has changed in the past ten years about the complexity class of ECDLP (it is still both in NP and in coNP).
Really, the future of cryptography is not elliptic curves, it is systems based on lattices, hidden linear codes, and hard learning problems (these are all related). You can do some interesting things with ECC, but there are far more interesting lattice cryptosystems being developed by researchers.
"ECC is increasingly common in commercial systems. Who's asserting patents against those systems?"
Really though, Dan Bernstein is not a lawyer, and I would not trust his analysis if I had a business to run. Even if he is right, that does not change the fact that ECC deployment is lagging because of fears about patent suits. The NSA's response to concerns about patents was to get a special license, specifically for government uses of ECC; they did nothing at all to encourage ECC deployment elsewhere, and they did not demonstrate that such deployment was a priority.
I've never seen anyone use McEliece, NTRU, &c commercially. Unlike ECC, these schemes aren't on the horizon for TLS.
ECC goes back to Lenstra and Koblitz in the mid-80's. I'm not wading into the validity of the patents the way DJB does, just saying, we're coming to the end of their lifespan.
You know darn well your question points to a strawman. It's pretty standard patent theory anymore to wait a little while, until there is lots of infringement, then to get a patent troll involved.
Generally, anything that's easy for the NSA to crack is also easy for its Chinese, Russian, European, etc. counterparts to crack. They want to read everything foreigners use, but want foreigners to not be able to read US citizens' (and corporations') communications.
There's a logic and motive to state intelligence organizations, it's not just a blind "everything must be readable!"
If you encrypt the data coming from the client all the way to the database or any other persistence mechanism, then it doesn't matter if the company is obliged to forward your data to a gov database. It would be encrypted, hence not easily readable.
In my case, as a service provider, we are encrypting as much as we can, so that we can't even read the data even if obliged to. It becomes troublesome for some pieces of data because we need to decrypt it so that it can be displayed in the website. So if we can decrypt it, as a provider, then we would be obliged to decrypt it for government agencies.
It would be interesting to see what can we do as a provider, to protect our own customers without breaking the law.
You can't do anything. The complete system is corrupted to the bone. If you are a successful company someday somebody with very deep pockets or a huge bank credit will show and buy you up. A few days later the encryption will start to disappear (e.g. Skype). If you don't sell your competitor will get the money and drive you out of business by the sheer force of money - pay higher salaries and get better ppl, better locations, more ads, etc.
The voluntarily part is also shaky. Eventually not 'volunteering' to do it will be too costly. The systems, rewards, costs will be rigged so that volunteering is the only way to play, but not required.
Also, the so called protections that it must be a cyber-security threat also hold little check and balance, how about an attack just happening when an agency needs information, or waiting for an attack by baiting it, any protection against creating honeypots to bait certain services? Probably not. Everyday servers and systems are attacked, so it is pretty much open season for getting information. There are no checks and balances and 'volunteering' means nothing. Try getting a gov't contract or deflecting problems without volunteering.
I am glad all these freedom giving up people have nothing to hide such as their business ideas, sites they visit, downloads, emails etc will all be tracked now. I am sure they have something to hide from then. All of this will now be stored not only on their computers and their services, but at the ISP and the NSA now as well. Lots more chances, especially at the ISP level, of identity theft and threats.
If possible, you, the provider, can claim zero knowledge and walk away free.
For instance, SpiderOak makes a point of not knowing what their clients store on their servers, because all encryption happens on the client side, and the key never reaches the server side.
If the algorithm is correctly implemented, Javascript encryption is no worse than any other.
The problem with JS is that the browser may be not good enough, failing to prevent certain attacks from other tabs.
The OS may be compromised, too, so that the data is available before encryption, or the key phrase gets stolen and siphoned out by a keylogger. However good your software is, you can't fight against it.
As memory is getting cheaper, running each domain in a different process in a different container or VM becomes more feasible (see Qubes OS). In a well-insulated environment, JS encryption should be as safe as any other.
True. But if what you say is true, that the encryption in javascript is good enough or comparable to their desktop counterparts, then it is a step in the right direction.
Nothing is 100% secure, specially in the web, but anything is better that what we have today.
I will start doing some research on the solutions to this. We are going to do for our clients, what I expect my providers do for me.
"We got two models for you: either you continue running your site as you see fit, which of course will mean tons of take-down orders, NSLs and other harassment - OR you could OPT IN to our new system which necessitates no further action on your part, as long as you install our little black box here next to your server. Your call."
There is immunity for sharing information "in good faith" under CISPA. CISPA is not a blanket authorization to share data.
If an ISP suffers a breach and coughs up huge amounts of PII that they handled negligently, they are absolutely still liable after CISPA becomes a law.
I did mean within the context of security and handing it over to authorities without due process, but it can easily extend to contradict your proposed scenario. If they claim that said negligence was even tangentially related to some other good faith effort to facilitate anything security related, they get a pass.
User-to-user encryption is really not feasible/possible for public forums, social media, blogging, photo sharing, or web search. It's hard enough to do where it actually is feasible, such as message interchange - especially considering the fact that we now all have multiple auto-synched devices.
