Slashdot Mirror
In Face of Flame Malware, Microsoft Will Revamp Windows Encryption Keys
coondoggie writes "Starting next month, updated Windows operating systems will reject encryption keys smaller than 1024 bits, which could cause problems for customer applications accessing Web sites and email platforms that use the keys. The cryptographic policy change is part of Microsoft's response to security weaknesses that came to light after Windows Update became an unwitting party to Flame Malware attacks, and affects Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2 operating systems."
Fact is, domestic and foreign govt agencies have moles working at Microsoft and apple to insert back doors or defeat encryption at the source. This is how stuff like flame happens. The only way out of this is to use an open source operating system where you can do your own code review, and where one guy doesn't have a bottle neck of control. Same goes for ios vs android.
ok, I suppose it's not quite a dupey as it could be. But still, heh.
And the second amendment means I have the right to encryption.
Tic-Tac-Toe, Global Thermonuclear War, and relationships all have the same winning move.
Why are we screwing with 1024-bit keys? Why aren't we using keys that are 1048576-bits?
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
ISPs have been rejecting CSR requests with less than 1024-bit keys for a long long time. Looks like windows is forcing a long overdue change back at the server, but I suspect providers have already forced most hands earlier.
IIRC, crypto algorithms that use keys that large qualify as munitions and are subject to ITAR export regulations. Which means a lot of people with legal licenses will be (legally, anyway) prevented from making use of any Windows feature which requires a key length of 1024 bits or more.
Maybe ... we your time machine works and they are all send back to 1997. Because, since then, it is no longer restricted by ITAR and can be freely exported...
morcego
If only there was a standards group, like NIST, that could determine what the acceptable key lengths were.
Oh yeah, NIST does have a publication on this topic and stated that 1024 bit keys were no longer acceptable back in ... 2010.
by the way, is it really 1024 bit encryption keys as stated in the article? I thought that the encryption keys were symmetric and its' the signature of the public key that's 1024 bit.
AFAIK, the problem with flame was a trust problem, not a bitstrength problem. They allowed Terminal Services certificates signed by Microsoft to be used to sign application code and the certificate chain still passed. Presumably those TS certs could have been 2048 bit or higher.
Because doubling the key length roughly increases the required time by 7. Increasing compute time by 7^20 is a little extreme, when just doubling it is good for a while.
Sorry got my maths wrong its only about about 300 million times longer.
Because RSA-2048 keys (twice the length of RSA-1024) take about four times as long to operate on (http://www.cryptopp.com/benchmarks.html). RSA-15360 (which is roughly the strength of AES-256 (http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf, page 63)) would take about (15360/1024)^3 = 3300 times as long as RSA-1024 (http://www.design-reuse.com/articles/7409/ecc-holds-key-to-next-gen-cryptography.html). This isn't a big deal for your local PC, where a single signature verification might take 250 ms rather than the sub-ms that it does with RSA-1024, but it has huge impacts on the servers that you're talking to - imagine increasing your server load by 330,000%.
And the worms ate into his brain.
Considering the largest RSA modulus ever factored is something like 750 bits, and until recently they were offering large amounts of prize money, I think 1024 is probably secure enough for your email that nobody really cares about, and 2048 will be secure for many years to come.
Posting to remind me to quote this when we're all having discussions about the need to require 16,384bit keys.
We should just go with ECC already. http://en.wikipedia.org/wiki/Elliptic_curve_cryptography
Faster than RSA1024 by a few factors, and about the strength of a 256bit symmetrical key, putting it at "universe lifes" for how long it takes to break.
I recently received news that my credit card was involved in a sizeable bank hack. The take? over $20,000 in Asia, well over the card's (previous) limit, and the bank says I'm not responsible for anything I didn't charge. Now I can prove my physical location and measely charges on the other side of the world.
If encryption is a part of this hack or any such security failures, we can't afford any more security theatre and survive financially.
Why are we screwing with 1024-bit keys?
We are not supposed to be, 2048 should be considered the minimum going forward.
Why aren't we using keys that are 1048576-bits?
It would take too long to encrypt anything, and there are diminishing margins of return when key sizes grow so large. If you are using more than 16384 bit keys, you are doing it wrong -- if you really need security that far into the future, you should be using ECC (which is more efficiently in terms of key sizes) or something that is secure even in the presence of a quantum computer like McEliece.
Also, keep in mind that such a large public key will require a larger symmetric key to even be meaningful -- 16384 bit RSA has no real advantage over 4096 bit RSA if you are using 128 bit AES. You also need to worry about the entropy available to your system, which could erase whatever advantage larger key sizes might have.
Palm trees and 8
The number does indeed refer to the length of the key, RSA-1024 is a 1024 bit key, that is the key is a "1024 digit" binary number. 2048 bits will indeed be twice as long.
I agree, but how about we stop giving out patents on number theory and revoke all previous patents on crypto? Seriously, ECC is a patent minefield, and those patents are holding back attempts at deploying more efficient crypto and crypto that can be used in innovative ways (like IBE, and yes, I am looking you Voltage Security).
Palm trees and 8
And the second amendment means I have the right to encryption.
Assuming that you mean the 2nd amendment to the US Constitution, then you are simply WRONG.
The parent post said EXPORT restrictions, so it was referring to users outside the US. Users outside the US aren't covered by the US Constitution.
It's a follow up to the so thought dupey.
If computing power advances that much in our lifetime I think anyone would be happy to eat some crow pie. it is hard to imagine computing power getting trillions of times more powerful in such a short period, but who knows.
I had to update my certs 2 years ago to meet PCI compliance. Honestly, Im shocked vendors still allow 1024 certs to be distributed.
The tin foil hat guy inside me says this is great for vendors who will get to charge fees to upgrade everyones certs....
what's wrong with shorter, cascading keys using different algorithms?
Operation Guillotine is in effect.
Actually, composing ciphers arbitrarily does not necessarily increase your security level:
http://secgroup.ext.dsi.unive.it/teaching/security-course/composition-of-ciphers/
Or if you prefer a more rigorous treatment of this topic,
http://www.cs.toronto.edu/~myers/BBCEuro.pdf
You should also be careful about composing a cipher with a compression function:
http://news.slashdot.org/story/11/05/26/1933219/Chapel-Hill-Computational-Linguists-Crack-Skype-Calls
Palm trees and 8
what's wrong with shorter, cascading keys using different algorithms?
The complexity that results adds a lot of risky unknowns. There are many tales of protocols being broken due to people looking at the various pieces in unexpected ways. Take DES, for example. Ordinary DES takes 56 bits of key material and offers 56 (OK, 55) bits of security. When DES was starting to appear fragile to brute force attacks, people looked for ways to strengthen it without replacing it. They thought of running two instances of DES, each with its own key, one after the other. How much security should this offer? The answer everyone expected was 112 bits. But someone discovered that the piecemeal approach created a meet-in-the-middle attack using storage as a trade off for computation, and it effectively only doubled the security to 57 (OK 56) bits. That's why 3DES was created. It uses three instances of DES, and when used with three unique keys provides the needed 112 bits of security. It's still not the 168 bits of key material, but it's thought to be effective against brute force attacks for the foreseeable future.
Nobody knows in advance all the complex interactions that makes these novel attacks possible; at least not until they have a reason to look for them.
John