Fox-IT Completes the Picture On the Factored RSA-512 Keys 38
An anonymous reader sends in this excerpt from the Fox-IT blog:
"During recent weeks we have observed several interesting publications which have a direct relation to an investigation we worked on recently. On one hand there was a Certificate Authority being revoked by Mozilla, Microsoft and Google (Chrome), on the other hand there was the disclosure of a malware attack by Mikko Hypponen (FSecure) using a government issued certificate signed by the same Certificate Authority. That case, however, is not self-contained, and a whole range of malicious software had been signed with valid certificates. The malicious software involved was used in targeted attacks focused on governments, political organizations and the defense industry. The big question is, of course, what happened, and how did the attackers obtain access to these certificates? We will explain here in detail how the attackers have used known techniques to bypass the Microsoft Windows code signing security model."
so how many of my accounts have been compromised? (Score:1)
security fail (Score:4, Funny)
The big question is, of course, what happened, and how did the attackers obtain access to these certificates?
The same thing that always happens, Pinky: Someone did a stupid thing. He or she was probably in management, since engineers are generally more careful (unless it's revision 2. Revision 2 is always evil)
Hopefully this shuts up the certificate freaks. (Score:5, Insightful)
For years now there have been some very vocal "security experts" who repeatedly trumpet how certificates and digital signatures somehow solve all security woes. Of course this isn't true, and we've tried to tell them this, but they refuse to listen.
Hopefully these recent incidents will shut them up once and for all. Certificates are nothing more than yet another tool in our security toolbox. To elevate them beyond this is a stupid thing to do, as these incidents rightfully show.
At the very least, I hope it makes these certificate freaks think twice before they recommend using certificates to solve some sort of a security problem.
Re:Hopefully this shuts up the certificate freaks. (Score:5, Funny)
For years now there have been some very vocal "security experts" who repeatedly trumpet how certificates and digital signatures somehow solve all security woes.
Funny I've never seen any of them in these here parts. We know how to handle dem security experts when they come 'round. Don't need none of that fancy ADP anti-viral intrusion penetration stuff. We don't download no screensavers or run javascript on every website, and we got big duke over there (He's our firewall dog). It's been good enough for us.
Re: (Score:2)
For years now there have been some very vocal "security experts" who repeatedly trumpet how certificates and digital signatures somehow solve all security woes.
In practice you'll find that very few "security experts" have any faith in PKI. It's more something you roll your eyes at or joke about than take seriously. The only people who "trumpet" certificates are (a) academics teaching about certificates based on an abstract theoretical model of how they work (which hardly counts as "trumpeting" them) and (b) people selling PKI products and services.
Short answer (Score:5, Insightful)
Re: (Score:2, Redundant)
Fox-It is based in the Netherlands. This makes it likely that the author's native language is not English.
Would you be able to form a coherent thought in Dutch that a native speaker wouldn't find awkward?
Re: (Score:3)
Fox-It is based in the Netherlands. This makes it likely that the author's native language is not English.
Would you be able to form a coherent thought in Dutch that a native speaker wouldn't find awkward?
Onze visie op de eigen slagkracht van de overheid.
Re:Short answer (Score:5, Funny)
"Onze visie op de eigen slagkracht van de overheid" ...which translates to:
"Drink more Ovaltine".
Re: (Score:3)
Onze visie op de eigen slagkracht van de overheid.
Ewige Schlangenkraft! Ewige Overheid!
Re: (Score:3)
Unless parent's job is to write in Dutch, I don't see how is that relevant.
Re: (Score:2)
Um, it's a blog. That's not the same as a "job"...
Re: (Score:2)
It's a corporate blog, not personal. Regardless of whether he gets paid to write or not, he's still posting on the Fox-IT blog under the title of "Principal Security Expert at Fox-IT", and the company shouldn't let someone without a good grasp on the English language write in their name.
Re: (Score:1)
Re:Short answer (Score:4, Interesting)
Also consider that RSA-768 took an estimated $100,000 USD worth of electricity to factorize in 2008 (plus intelligent folks to write the software). So, you should not even use RSA-768 unless the secret you are protecting is worth much less than $100,000.
By comparison, RSA-512 security is a complete joke in 2011, and can be factorized for less than $250 if you don't know what you are doing, or for under $50 if you do. Implementing RSA-512 correctly in your application will cost more than it will take to break it.
Conservatively, RSA-1024 would need about 1000 times the resources to factorize as RSA-768 used, so should be safe to use as long as your secrets aren't worth more than a few million dollars and only need to be protected for a few years.
That means RSA-1024 is a huge bargain for the user -- significant improvement in short-term security for the user compared to using RSA-512, for only 2x the amount of CPU resources.
Re: (Score:3)
So, why not use 4 times the CPU resources and go with 2048 already? It should be safe for anything that is cheaper than creating a couple of stars...
Re: (Score:2)
Does CPU usage really matter for certificates? They're only used sign things or encrypt session keys so you only need to do one encryption per session.
Re:Short answer (Score:5, Insightful)
That means RSA-1024 is a huge bargain for the user -- significant improvement in short-term security for the user compared to using RSA-512, for only 2x the amount of CPU resources.
Shame on whoever modded this up. The main calculation in RSA is a^b mod n, with n being the 512/1024 bit integer. Most implementations will scale with O(n^2), certainly never O(n). That said, even a 2048 bit key should be done in a few microseconds and there's no real reason not to do it proper. Remember that you generally you make a digest and just do one RSA operation to sign/verify it. When used for SSL you encrypt/decrypt a symmetric key then use AES for bulk encryption, again doing just one RSA operation. Of course if you got hundreds or thousands of connections per second that might be an issue, but normally it should not be.
Re:Short answer (Score:5, Informative)
I agree with you, Kjella.
The 48 MHz, ARM-7-like processor in our ASIC can do an RSA-2048 operation in 3-4 seconds. The 3000 MHz, 64-bit, OOE, multi-issue, TLA-up-the-Wazoo processor in the average $400 laptop should be able to do it in 3-4 milliseconds (http://www.cryptopp.com/benchmarks.html).
There is no reason not to be using RSA-2048 on the desktop. On a Webserver getting hit by millions, the 6-8x increase in CPU times is going to start getting noticeable. /frank
Re: (Score:1)
The main calculation in RSA is a^b mod n, with n being the 512/1024 bit integer. Most implementations will scale with O(n^2), certainly never O(n).
To be even more precise, general modular exponentiation algorithms scale worse than O(n^2) but faster than O(n^3). The reason is that they execute a linear (O(n)) number of multiplications in the size of inputs with subquadratic but superlinear complexity (O(n^k), 1 k 2). Recall however that most implementations have a fixed short encryption exponent (e = 65537, for example) requiring a constant number of multiplications. So, one could argue that RSA encryption has superlinear but subquadratic complexity.
Re: (Score:2)
Recall however that most implementations have a fixed short encryption exponent (e = 65537, for example) requiring a constant number of multiplications. So, one could argue that RSA encryption has superlinear but subquadratic complexity.
I didn't go into that much detail but performance is asymmetric as well. Encryption and verification is cheap, decryption and signing is expensive. I'll just quote from this table: http://www.cryptopp.com/benchmarks.html [cryptopp.com] (time in ms):
RSA 1024 Encryption 0.08
RSA 1024 Decryption 1.46
RSA 2048 Encryption 0.16
RSA 2048 Decryption 6.08
RSA 1024 Signature 1.48
RSA 1024 Verification 0.07
RSA 2048 Signature 6.05
RSA 2048 Verification 0.16
For the most common case of a secure web server, the client
Government certificates (Score:3)
should I check my Firefox Certificates? (Score:3)
I see DigiNotar and DigiCert Authorities in Firefox's Certificate Manager.
Should I be concerned about these?
Is there a revocation list I need to know about?
Using Firefox 8.0 on Ubuntu, for what it's worth...
Re:should I check my Firefox Certificates? (Score:5, Interesting)
I see DigiNotar and DigiCert Authorities in Firefox's Certificate Manager. Should I be concerned about these?
Since the situation with DigiNotar and others isn't, by definition, allowed to happen in PKI, there's no way of dealing with it when it does. So the only way to handle it is for Mozilla to create fake certs for those CAs and add them to the FF cert store, effectively cache-poisoning themselves so that the fake certs, which aren't trusted, get used by FF instead of the real ones. Since they're not trusted, you get a verification failure when you try and use them.
(See my earlier comment in the other thread about PKI being treated as something to roll your eyes at and/or joke about by security experts).
Re: (Score:2)
Thanks for your reply!
Can't CA's be revoked? Or only certificates? I was thinking, though could be wrong, that DigiNotar could've revoked ... something ... before generating a new CA (or going broke).
Ik hep het al geleezen. (Ouc
Re: (Score:2)
Can't CA's be revoked? Or only certificates? I was thinking, though could be wrong, that DigiNotar could've revoked ... something ... before generating a new CA (or going broke).
Uhh... how long do you want the answer to this one to be? In effect trusted root certs can't be revoked, for other certs they can, in theory, be revoked, but the revocation system is so broken that you can't really rely on it, which is why the Mozilla guys used the somewhat unusual approach described above (and other browser vendors took equivalent action, hardcoding in the certs they wanted gone rather than relying on CRLs and OCSP).
I kinda thought PKI was pretty solid, so your earlier comment kinda burst my bubble. What's the alternative?
That would require an even longer reply... a short summary is to do what
Re: (Score:2)
What part of long time don't you understand? It was mostly phonetically spelled anyway.
Biggest problem these days is not putting Cantonese words in when trying to think Dutch.
A quick search finds lots of hits for geleezen and gelezen.
-1 Not Insightful for your failure to offer the correct current spelling.
Marginalize CAs (Score:3)
Big sites which can afford the $$$ can get a CA signature which is meaningfully secure and trustworthy. Which is great for them but not so good for the vast bulk of sites which might like to use encryption but don't because obtaining and maintaining a cert is a huge pain in the ass. So they continue with plaintext. And if we look at those big sites, surely a Toys R Us would find more worth in a cert which was signed by Lego, Microsoft, Visa, Mastercard and so on than by some obscure CA? Companies whom the visitor is likely to recognize and would have some kind of reciprocal business relationship.
So instead of a rigid CA signature it seems to me a lot better to implement a web of trust. Google could host a key signing party and get Microsoft, Amazon, PayPal, Mozilla to attend. Each in turn might hold some satellite key signing parties to sign more keys and keep going out until the top 500 or so sites are covered by each. Every signatory signs with an email address and puts their public key up on a well defined location on that domain, e.g. the public key for security@keys.google.com might be at keys.google.com/security. A browser is preloaded with public keys for the major sites and is capable of caching any it doesn't have. There would also be some kind of revocation model. Trust could be graded anywhere from ultimate to weak. When a browser visits a site it validates the site's signatories and their trust to the ones in its list and poses an appropriate form of information or error to the user depending on what it finds.
The point is that web of trust would allow sites to make their own trust in a manner that suits them and their visitors. And it doesn't stop CAs from selling their own signatures as part of the web of trust either much like some already do for PGP, or through the more rigid CA model. But what it does do is stop CAs being a mandatory part of the equation. People will be able to generating certs in an adhoc fashion. That to me is a far better model, and one which would stand a good chance of making security the default rather than an after thought that some sites practice and not others.
Not an attack by Mikko (Score:2)
No, there was the disclosure by Mikko Hypponen of a malware attack using a government issued certificate. Mikko did not perform the attack.