5 ms·
This is really damaging. Not only will this cause other countries to put up barriers against US (and UK) services and products, it's going to affect uptake of
by tc 13y ago
This is really damaging.
Not only will this cause other countries to put up barriers against US (and UK) services and products, it's going to affect uptake of standards developed here.
On the lighter side, a treasure hunt was just announced. Can you find one of these vulnerabilities, or evidence of the NSA having attacked a particular system to steal keys?
----
[Edit 1] Some speculation:
By careful hardware design -- and lots of it -- the NSA may be able to find keys large enough that we would be mildly surprised but not shocked. It's not well known that searching for many keys in parallel amortizes well -- it's much cheaper than finding all the keys individually. DJB has a great paper about this:
http://cr.yp.to/snuffle/bruteforce-20050425.pdf http://cr.yp.to/snuffle/bruteforce-20050425.pdf
If I were looking for subverted hardware, I'd be really interested in reverse engineering Ethernet chips and BMCs. The CPU would be an obvious choice as well -- could there be some sequence of instructions that enables privilege escalation?
On protocols, the best sort of vulnerability for the NSA would be the kind that is still somewhat difficult and expensive to exploit. They want the security lowered just far enough that they can get the plaintext, but not so far that our adversaries can.
There is some history with not taking timing attacks seriously enough. Perhaps careful timing observation, which the NSA is well positioned to do, could give more of an edge than we suspect. Or perhaps you could push vendors to make their products susceptible to this kind of attack, secure in the belief that it may be difficult for others to detect.
[Edit 2]
I gave a talk that discussed what I think we as engineers should do here:
https://www.youtube.com/watch?v=c7oK59DZwR4#t=1m46s https://www.youtube.com/watch?v=c7oK59DZwR4#t=1m46s
And Phil Zimmermann and I discussed a number of these issues in a Q&A session:
https://www.youtube.com/watch?v=W42i8zCEizI#t=49m55s https://www.youtube.com/watch?v=W42i8zCEizI#t=49m55s
- kamjam 13y agoImagine this is proved in France, this would add some weight to the investigation and case against the US, esp if they can prove personal encryptyed information was stolen! http://www.reuters.com/article/2013/08/28/us-usa-security-france-idUSBRE97R0WE20130828 http://www.reuters.com/article/2013/08/28/us-usa-security-fr...
- lambda 13y agoOne of the vulnerabilities was already discovered by researchers in 2007: http://rump2007.cr.yp.to/15-shumow.pdf http://rump2007.cr.yp.to/15-shumow.pdf At the time, it wasn't clear if this was a deliberate backdoor or an accident, but it was proven that there there was a possibility that there was a secret key that would allow someone to predict future values of a pseudo random number generator based on previous values. Now it looks pretty clear that it was a deliberate backdoor. This really reduces trust in US based cryptographic standards. And US based cryptographic hardware, as they mention in the article that they convinced hardware manufacturers to insert backdoors for hardware shipped overseas.
- tptacek 13y agoThis is almost definitely not "one of the vulnerabilities" implicated in the story today, because nobody uses CSPRNGs based on Elliptic Curve.
- andrewcooke 13y agoso what was the vulnerability found by ms in 2007 that they are referring to? (search for 2007 in single page version at http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html?_r=0&pagewanted=all http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet...) edit: reading in more detail around there, i am pretty sure that section of the article is referring to the CSPRNG vulnerability above. the article covers a lot of ground and not all of it is about problems with ssl. that particular section seems to be arguing that the nsa is trying to put backdoors into standards wherever it can.
- tptacek 13y agoI don't know. I'm just saying, weakening a CSPRNG design that nobody uses or is ever likely to use (it's extremely expensive) is not a particularly meaningful action.
- stingraycharles 13y ago
- tptacek 13y agoI would not be at all surprised to learn that the major advance these disclosures refer to is an on-demand RSA-1024 factoring capability. RSA-1024 is already known to be unsafe (Eran Tromer estimates a 7 figure cost for a dedicated hardware cracker, which is approximately the threshold DES was at in the late '90s, when nobody believed DES was secure). On-demand offline RSA-1024 attacks would have major implications, would be a huge advance in the state of the art, but also seems feasible given an effectively unlimited budget.
- TheCondor 13y agoThat makes sense. I think it unlikely they've discovered an actual break through. They do have their own fab, how many chips do you need to build to Mae that worthwhile? It's the US government after all, a machine with 10million specialized RSA chips doesn't seem impossibly difficult, just expensive.
- ballard 13y agoGovernments are big, dumb animals, so make whatever you're trying to protect very expensive ($20-50 Billion range) to brute-force within usability constraints. Btw... apart from Scrypt paper, has anyone put together a practical guide on crypto parameter brute force costs? (say volume pricing of gear and asics in huge qty)
- mrb 13y agoI think we know very well which encryption has been foiled by the NSA. This is not speculation, but quasi-certainty: 1024-bit RSA. - Crytographers all acknowledge 1024-bit RSA is dead [1]. - Attack cost 10 years ago was estimated to be a few million USD to build a device able to crack a 1024-bit key every 12 months [2]. - "Much of" the "secure" HTTPS websites use such weak key sizes [3]. - NSA had a budget of 10.8 billion USD in 2013. Drawing a conclusion is not very hard. [1] http://arstechnica.com/uncategorized/2007/05/researchers-307-digit-key-crack-endangers-1024-bit-rsa/ http://arstechnica.com/uncategorized/2007/05/researchers-307... [2] http://www.cs.tau.ac.il/~tromer/twirl/ http://www.cs.tau.ac.il/~tromer/twirl/ [3] https://www.eff.org/pages/howto-using-ssl-observatory-cloud https://www.eff.org/pages/howto-using-ssl-observatory-cloud
- leokun 13y agoSome popular browsers still do not support newer versions. We tried turning this on with a newer, more secure key and ended up having downtime for some customers.
- trafficlight 13y agoWhich browsers in particular?
- leokun 13y agoAndroid Browser on Google TV, and Java libraries hitting our APIs. Google TV and Android browsers are critical to our business.
- mrb 13y agoI have written lots of Java code accessing HTTPS sites with 2048 or 3072-bit RSA. This is perfectly supported. You do not even need the Unlimited Strength Jurisdiction Policy Files to use such RSA key sizes (other algorithms are restricted). I can't comment on Android Browser on Google TV, but I very highly doubt it fails to support 2048-bit RSA keys. If that was the case, half the HTTPS websites would be unbrowsable(!) [1] [1] Per the EFF SSL observatory dataset, roughly 1 in 2 websites uses key lengths strictly higher than 1024 bits.
- grecy 13y ago> but not so far that our adversaries can. Please clarify what you mean by "our". Please clarify what you mean by "adversaries".
- hextalib 13y agoCome now, we know enough about the NSA at this point to know that our, adversaries = America, !America right?
- unreal37 13y agoIn this context, an adversary is any encrypted data they want to be able to decrypt. Anything.
- eli_gottlieb 13y agoAdversary in security means anyone you don't want reading your data.
- hershel 13y agoIn this pdf[1] , they discuss security issues in intel chips.They mention strange responses from intel. Also it's possible, but very hard to exploit those issues , which is optimal in this case. 1[]http://pavlinux.ru/jr/Software_Attacks_on_Intel_VT-d.pdf http://pavlinux.ru/jr/Software_Attacks_on_Intel_VT-d.pdf
- voltagex_ 13y agoForgive me if I don't open a PDF from a .ru domain. (and yes, I know how silly that response is)
- slacka 13y agoIf you were actually interested in the content, there are countless ways to open a PDF safely. * Open the PDF in a non-adobe reader such as Foxit and Sumatra w/ JavaScript disabled * Both FF and Chromes internal PDF viewers ignore JS * You can preview a PDF in Google drive * Open the PDF in a sandboxed VM. Guessing for your history of spammming 1 line pointless comments, you probably already know this.
- voltagex_ 13y agoYou are right. I didn't know that PDF.js in Firefox was somewhat safer, though.