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

Comments

Moles at Microsoft and apple

[noh8rz5]

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.

Re:Moles at Microsoft and apple

[rsmith-mac]

That's a pretty serious "fact". And not to sound like a smart-ass Wikipedia editor, but some kind of citation would be great.

One can certainly believe there are moles at Microsoft/Apple. One can even reasonably assume that the United States Government has the power to compel Microsoft/Apple to do things that are in the U.S.'s best interests. However for a foreign mole to be able to insert back doors into the Windows source code - which I would add is fairly well vetted since most governments and educational institutions have read access to the source - would be quite remarkable to the point of being unbelievable.

Re:Moles at Microsoft and apple

[lightknight]

Indeed. Why have a mole try to alter the code, and run the risk of being discovered, when you have a copy of the source, and can find existing bugs to use?

Re:Moles at Microsoft and apple

[ozduo]

Fact is, domestic and foreign govt agencies have moles working at Microsoft and apple.

Don't know about moles but there are a few Turkeys working there

Re:Moles at Microsoft and apple

[nzac]

Yes but if the key length is sufficiently large they lose plausible deniability.
No ones going to believe that anyone bruteforced a 2048 cert key but if you start mentioning MD5 and less and 1024 then it could be anyone.

Re:Moles at Microsoft and apple

[drinkypoo]

Citation: my contacts at Microsoft and apple. Obviously I can't name names.

Obviously you can't be taken seriously, either. It's not that I don't believe you, it's that I can't ever cite you.

Re:Moles at Microsoft and apple

[bipbop]

I don't believe them. I'm not saying they're wrong, but I don't believe their assertion has any connection to the facts, one way or the other.

Re:Moles at Microsoft and apple

[gmanterry]

Long live TrueCrypt!

Re:Moles at Microsoft and apple

[Anonymous Coward]

Others have come to the same conclusion as noh8rz5. http://www.pcpro.co.uk/news/security/375169/could-us-cyberspies-have-moles-inside-microsoft

Given the amount of disinformation we'll be seeing in MSM and here, I'd say we'll need to wait for a Wikileaks style whistleblower before we know for sure.

Re:Moles at Microsoft and apple

[The Snowman]

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.

Yes and no. Open source doesn't guarantee security. For example, BIND had a long history of bugs (many of which involved security) due to poor design prior to version 9. You didn't need a mole or any malicious intent when the software was so full of big holes you could drive your car through them. OpenBSD had an alleged FBI back door in the news a couple years ago that had lain unnoticed for years.

Then again, there are examples of open source uncovering security issues. A quick google search uncovered this old one and this more recent one. By the way, if it sounds like I'm picking on BSD, I was searching for that FBI link. The other stuff just popped up. I know the various BSDs have a reputation for stability and security.

Re:Moles at Microsoft and apple

[ozmanjusri]

True, but as ITWorld's Kevin Fogarty says;

Still, the assumption seems to be true metaphorically, if not physically, so it's safer to assume Microsoft and its software have both been compromised. Given the track record of Stuxnet, Duqu and Flame for compromising everything they're aimed at, that assumption isn't even much of a stretch.

http://www.itworld.com/security/281553/researcher-warns-stuxnet-flame-show-microsoft-may-have-been-infiltrated-nsa-cia

Personally, I use Linux because it's lower maintenance and less overhead, and gets out of my way when I'm working, but if I was a business lead, I'd certainly be avoiding Windows for anything requiring data security. The wonder is that we're not seeing users suing over compromised data/systems.

Re:Moles at Microsoft and apple

[drinkypoo]

Others have come to the same conclusion as noh8rz5

Well, I know this is one of those things annoying people say to be annoying, but the plural of anecdote is not data. I have come to the same conclusion, too, but I don't state it as fact, because there's no citable evidence.

Re:Moles at Microsoft and apple

[SpaceLifeForm]

Even if true, it is just a convenience.

NSA can break the encryption anyway if they put the effort to the task.

Re:Moles at Microsoft and apple

[cavreader]

Why do people assume there is a large group of developers that actually understand OS source code and are capable of locating and correcting any problems found? Most of the people with the necessary skills to do this are already busy working for companies that actually pay them for their services. The vast majority of security issues are discovered by companies and individuals who specialize in this area and expect payment for their services. OS troubleshooting and development also requires well stocked labs to test all of the different permutations of hardware and software behaviors. The low hanging fruit has already been grabbed which forces deeper analysis of the OS code to locate potential issues and determine the impact their proposed changes will have. Just because someone is half way competent in Application development does not mean they have the skills needed to understand OS development. OS development is quite different than Application development. Just downloading the OS source code and building it can be a gigantic pain in the ass when trying to sort out all of the dependencies and compiler configurations for a particular environment.

I you want a secure system you are better off making sure the system administrators and application developers are doing their jobs. Some of most harmful security issues have exploited known issues that were corrected way before someone started exploited them. And those happens because system administrators failed to stay current on their security related service packs.

Re:Moles at Microsoft and apple

[Billly Gates]

It took $200,000 worth of equipment to crack the cert key according to www.arstechnica.com.

The government does have super computers as well and many that are listed in the top 500 are classified. I wonder how long it would take a modern cray or a cluster of 1,000 computers to crack a 2048 cert? It does sound like something the government would not mind spending.

I doubt the russian mobfia would invest that much but maybe they can afford to do just that for a single piece of malware that will be useless once AV software detects it. It sounds too risk and far fetched

Re:Moles at Microsoft and apple

[marcosdumay]

They can do that at their 2k qbit quantum computer?

Re:Moles at Microsoft and apple

[Anpheus]

The Flame certificate's key was replaced with a shorter RSA key due to bad usage of crypto by Microsoft.

The estimated computational ability to crack a 1024-bit RSA is quite large (but maybe, maybe feasible if you can devote large amounts of computational time to it.) But 2048-bit RSA? No, not unless a three letter agency has figured out a new way to factor integers.

Re:Moles at Microsoft and apple

[marcosdumay]

I wonder how long it would take a modern cray or a cluster of 1,000 computers to crack a 2048 cert?

With current (non secret) algorithms? Well, they could do it fast (in geological terms), but they'll need a star thousands of times larger than our Sun powering a computer running near to the optimum efficiency.

Somehow I doubt the NSA has such infrastructure.

Re:Moles at Microsoft and apple

[betterunixthanunix]

The only way out of this is to use an open source operating system where you can do your own code review

Have you ever tried to do this? I have tried, and trust me, no single person can review all of the software that runs on their system. There are a lot of places where a back door could be hiding, especially if you are talking about cryptography. Even something as seemingly innocuous as the default environment variables that programs see could be part of a back door (in case anyone does not know, the length of the environment variables can affect the alignment of memory, which can affect cache misses and potentially amplify a side channel).

Have you reviewed the millions of lines in the Linux kernel? Have you reviewed OpenSSL? Have you reviewed GnuPG? Have you reviewed glibc, libstdc++, ld, bash, gcc, your python interpreter, your X server, your email client, your web browser, etc?

Re:Moles at Microsoft and apple

[DMUTPeregrine]

It's far more reasonable to believe that there are moles at Intel/AMD. Their designs are not nearly as well vetted, since most governments and educational institutions don't have access to the source. It's also the smart place to put a backdoor, since it's MUCH harder for the target to remove it if found.

Re:Moles at Microsoft and apple

[betterunixthanunix]

Well, until MS explains what the NSAKey does, I'll just assume the worst.

http://web.archive.org/web/20000520001558/http://www.microsoft.com/security/bulletins/backdoor.asp

You could have stopped assuming the worst over a decade ago. If you really think that the NSA would allow its back door to carry such an obvious name, then you need to get your head checked. Here is the sort of back door I might be willing to attribute to the NSA, but even this seems a little too obvious:

http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115

Re:Moles at Microsoft and apple

[icebike]

Well said.

Nothing compels you to run Microsoft's encryption APIs either. They are convenient, and well documented, so most programmers do use them, but you can write or bring your own from any platform you trust. If your platform is backdoored none of this will help you much.

The assertion that there are backdoors in spite of no one finding it and every single person in the chain of knowledge for the last 20+ years keeping their mouth shut right into the grave.

Re:Moles at Microsoft and apple

[nzac]

I wonder how long it would take a modern cray or a cluster of 1,000 computers to crack a 2048 cert?

Throwing 1000 computer instances at the problem does not make the difference you think it does.

Re:Moles at Microsoft and apple

[phantomfive]

Is there any evidence at all? Really wondering.

Also, I seriously doubt a 'contact' at Apple or Microsoft is going to know about spies.

Re:Moles at Microsoft and apple

[Anonymous Coward]

On mere speculation and cynicism, I'd go even farther and say that they are in bed with them with some shadow department in Microsoft. Lest we forget the NSA_Key debacle in Windows NT?

Re:Moles at Microsoft and apple

[detritus.]

Somehow I doubt the NSA has such infrastucture.

If they don't yet, they sure as hell will soon

Re:Moles at Microsoft and apple

[stanlyb]

Do you happen to now how COM/DCOM is working? By design? And how easy was some 10 years ago to "sniff" your IE without any trace? Don't bother, it is not a fish.

Re:Moles at Microsoft and apple

[stanlyb]

Helloooo, have you heard of WAKEUP WHILE POWER DOWN feature of all the newest Intel CPUs? No? Really? Where are coming from? The Moon?

Re:Moles at Microsoft and apple

[man_of_mr_e]

Not to mention:

http://www.schneier.com/crypto-gram-9909.html#NSAKeyinMicrosoftCryptoAPI

Re:Moles at Microsoft and apple

[Rockoon]

Which part of the cracking problem requiring the power of a star thousands of times larger than our sun that confuses you?

Better yet.. dont answer that.. instead simply explain why your 4-digit slashdot ID isn't backed up by someone aware?

Re:Moles at Microsoft and apple

[Rockoon]

The problem is that..

Even if you know that its the square of the power required to crack 1024 bit certs, which themselves are the square of the power to crack 512 bit certs, which are themselves the square of the power to crack 256 bit certs.. when you are ignorant of how much power THAT is, you are still just guessing.

No organization on earth considers the breaking of 256 bit hashes/encryption trivial. Thats a 1 followed by a whopping 77 zeros. Thats only about 3 zeros away from the number of baryons in the entire visible universe.

Re:Moles at Microsoft and apple

[nzac]

What are you on about? 1024 bit RSA is reasonable to crack in the next 10 years.
This is RSA, its not as strong as AES for the same bit length.
http://en.wikipedia.org/wiki/Key_size#Asymmetric_algorithm_key_lengths
According to Wikipedia approximation you need about 4 billion times the compute instances to calculate 2048 compared to 1024.

Re:Moles at Microsoft and apple

[Anonymous Coward]

Well - there are reason for that.

At first - the EULA especially gives no guarantee your data will be preserved, uncompromised or protected. Yes that's right - the end user has no guarantee the software he/she/it uses is safe, and Microsoft is not responsible for anything. Great hm?
Now - nothing is guaranteed with Linux either, but at least every end user can go trough the sourcecode to discover faults. Most end users will not do that or are not capable to do that, but at least the chances of discovery are better than closed source software.

And secondly - most company's will not admit there is a data breach (or try to wave the importance of this), because they want to look trustworthy to the consumer. I guarantee the amount of data breaches is much higher in reality than the general public ever is going to hear.

And thirdly - a lot of data breaches are just not known by the end user, because they have no way to discover it. If your closed software says everything is fine, you have to trust it because there is no way to check if this is correct (until the software manufacturer admits something is wrong or you get the extreme privilege take a glimpse at the source code).

So suing wont get you very far, because you signed the EULA (saying the software manufacturer is not held responsible for anything), and the software manufacturer always can hide behind the closed source and say external factors are the course of the data breach. You cannot prove anything without the complete source code (and not only the relevant part, because the fault can be "hidden" in something seemly unrelated).

Re:Moles at Microsoft and apple

[Anonymous Coward]

so you compiled the kernel and encryption libraries on your android phone yourself? really? yeah, i didn't think so. eat a dick, kid.

Re:Moles at Microsoft and apple

[hairyfeet]

You mean like BSD which got backdoored by the FBI? I hate to break the news to ya pal, but if a three letter agency wants to pwn a FOSS project? it would be just as easy if not easier than any proprietary OS.

You should look at some of the entries of the obfuscated C contest to see how damned easy it is to hide nasties in large amounts of code, and those are for bits of code where you KNOW there is a nasty. Now imagine, how many projects are out there with only a handful of guys working on it? How happy would they be to have a highly skilled coder volunteer to help? Have YOU looked at every line of code in the apps popularly packaged in your average distro, hmm? Well if you haven't what proof do you have that anybody else has? Just because you have access to the code does NOT mean anybody that can actually read it and more importantly can spot obfuscated malware has read it line by line you know.

Even reading the apps one at a time wouldn't work since a three letter agency could easily pay for guys to work at multiple projects. Just as we have malware today that simply drops a payload I could easily see program Foo not doing anything by itself but checking to see if you have program Bar and Boned and if all three are present the combination opened a door. After all who is gonna notice dependencies? Those are SOP in FOSS OSes, programs having dependencies really aren't rare ya know.

In the end FOSS is no more a "magic bullet" than painting a cross on the box to ward off evil. there is simply too many millions of lines of code in your average distro for anyone, even Linus himself, to be able to tell you with 100% certainty every single interaction when a program is called. Sure if you were to DIY starting with the kernel it would be more secure, but how many actually do that?

Re:Moles at Microsoft and apple

[Anonymous Coward]

Well, until MS explains what the NSAKey does, I'll just assume the worst

Logic fail.

I wonder how brain damaged people like you actually manage to function in society. :(

Re:Moles at Microsoft and apple

[Anonymous Coward]

While I could believe they have tech exponentially more powerful than available to others the sheer processing power required to break a 2048 bit key is in the order of billions of years of processing time. from memory the calculation is that if you started processing this with current computing power at the beginning of the universe you would still only be a fraciton of the way through it. Any breaking of the keys this long requires alternative algorithms or flawes in the algorithm itself.

Re:Moles at Microsoft and apple

[WaffleMonster]

Personally, I use Linux because it's lower maintenance and less overhead, and gets out of my way when I'm working, but if I was a business lead, I'd certainly be avoiding Windows for anything requiring data security. The wonder is that we're not seeing users suing over compromised data/systems.

I know right... What are the chances out of the bazillion open source projects that go into your average linux distribution any of them could be be infiltrated by a three letter agency from this or any other nation... Impossible.... totally ...utterly..... impossible... ..right...?

I know some people will say well its open source others would have the code and just know. Just like they knew about that Debian "SSL patch"... Or any of hundreds of "innocent" security bugs having later been discovered by attackers.

How long was kernel.org compromised? Without anyone knowing?

Re:Moles at Microsoft and apple

[houghi]

The wonder is that we're not seeing users suing over compromised data/systems.

They clicked OK during the installation and everybody knows that that is waterproof and airtight contract binding. So they do not have a case to go to court with.

Re:Moles at Microsoft and apple

[Anonymous Coward]

I think the question that GP hinted at was if you can not do code review, can it ever be secure. Code that is closed source only leaves one method to measure security, and that’s past performance. Based on past performance, you can make an educated guess over how secure something is. In that sense, new products and new market actors with closed software should never, ever, be trusted in anything requiring security. Without a past performance track record there is a complete lack of evidence to provide trust. Open software on other hand can be trusted even if there is a lack of past performance, simply because one can do code review and verify the security independently.

Re:Moles at Microsoft and apple

[Richard_at_work]

Except the OpenBsd back door claim was never proven and dismissed by basically everyone - subsequent audits of code and checkins haven't revealed anything suspicious.

It was basically someone who wanted to get their name in the papers, that's all.

Re:Moles at Microsoft and apple

[Joce640k]

However for a foreign mole to be able to insert back doors into the Windows source code - which I would add is fairly well vetted since most governments and educational institutions have read access to the source - would be quite remarkable to the point of being unbelievable.

Yep. Anything that totally compromises the system would have been discovered by now. There's a lot of people interested in finding such things.

Re:Moles at Microsoft and apple

[Anonymous Coward]

You are confusing pre-placed key security with the public key length vs complexity issues

Re:Moles at Microsoft and apple

[gnasher719]

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.

If that rabid nonsense that you are posting about Microsoft and Apple were true, what makes you think that the Linux code that you look at is the Linux code that gets compiled and shipped?

Re:Moles at Microsoft and apple

[gnasher719]

Have you reviewed the millions of lines in the Linux kernel? Have you reviewed OpenSSL? Have you reviewed GnuPG? Have you reviewed glibc, libstdc++, ld, bash, gcc, your python interpreter, your X server, your email client, your web browser, etc?

There was a story a while ago with some reasonable mathematics that showed that if your CPU delivers a predictable incorrect result for _one_ 64x64 bit multiplication then this could be used to crack certain encryption. And that would be totally undetectable.

Re:Moles at Microsoft and apple

[AdmV0rl0n]

"but at least every end user can go trough the sourcecode to discover faults"

Yes, sure they can. And every user has such ability, and kernel level hacking skills. And each and every individual and company should employ people to do this.

Yessss, right. While this is philosophically a nice point, I have to say that the real world aspect is delusional. And I'll add another point. Its open source. If Governments can insert code into MS codebases, they can do so with any open source. The fact is they might only be caught out by exceptional code audits looking for it.

Re:Moles at Microsoft and apple

[WuphonsReach]

The time to crack a 128-bit hash is not the same as 128-bit of symmetrical ciphers which is not the same as 128-bits of public/private key encryption. They are very different beasts (although a lot of modern hash algorithms are derived from symmetrical ciphers).

Symmetrical ciphers like AES are secure at short key lengths like 128-256 bits. For asymmetric ciphers like public/private key encryption, you need to go up to 1024 or 2048 bits in order to get the same level of protection (same approximate resistance to various attacks).

Re:Moles at Microsoft and apple

[Jumperalex]

You mean his FIVE-digit slashdot ID right? Or did you find a fancy new factoring algorithm ?

Re:Moles at Microsoft and apple

[Eskarel]

This is only true if you're compiler hasn't been compromised, or the that compiled it, or the one that compiled that one, and on and on.

The reality is that no matter how clever you are, how long you spend reading the source code for your favorite operating system, or how well you understand the results of that reading, you have to trust someone some time.

Even aside from that, the number of people who truly understand the source and design of any given OS completely could probably be counted without resorting to toes. A Debian maintainer neutered their SSL library for years getting rid of a compiler warning. The days of Mel's are long gone and when you get into the deep magic, most folks, myself included, are way out of our depth.

Open Source has a lot of advantages to it, but the idea that someone is going to stick something in a proprietary OS which is simple enough for even most programmers to actually catch without it getting detected is pretty close to nil. Many eyes only helps if the back door is simple enough for the many to recognize.

Re:Moles at Microsoft and apple

[Anonymous Coward]

Do you use selinux? You know the NSA produced that correct? Have you done a thorough code review?

Re:Moles at Microsoft and apple

[Eythian]

Well no, you can't just insert code just because something is open source. Trusted people and other reviewers look it over first.

Re:Moles at Microsoft and apple

[benjymouse]

How long was kernel.org compromised? Without anyone knowing?

We don't know. At least 17 days was the initial assessment, but kernel.org has - despite claims about openness - never got around to write up a post mortem.

Many of us would like to know what the attack vector was. How a compromised *user* account could lead to the kernel being rooted. How a relatively amateurish infection (phalanx is a old, known and pretty trivial rootkit) could penetrate so deeply into infrastructure run by the people most knowledgeable on Linux *in the world*.

Was the actual attack which resulted in the infection a walk-over or was it more sophisticated than what the use of phalanx rootkit suggests?

Re:Moles at Microsoft and apple

[PedroV100]

when you have a copy of the source, and can find existing bugs to use?

..how about paying to deliberately place in a couple of such bugs?
--
“Forget Jesus. The stars died so you could be born.”

Re:Moles at Microsoft and apple

[thetoadwarrior]

I'm sure MS give them what they want. What's the worst thing that happens here? You've have to buy newer products as MS changes something to look like they're on your side. I'm sure that's keeping people at MS awake at night.

Re:Moles at Microsoft and apple

[Anonymous Coward]

He meant to say that there are "moles" that infiltrated kernel hacking community - the 1000 or so people that write the kernel

Re:Moles at Microsoft and apple

[Anonymous Coward]

did none get that this was a joke? How can this be rated as troll? Either that or Slashdot gives out rating point to UNFUNNY people. That's right you haters, you're unfunny.

Re:Moles at Microsoft and apple

[Eythian]

That doesn't make it any more right however. How many of those have direct commit access to the main kernel tree?

Re:Moles at Microsoft and apple

[lightknight]

How many need it? Submit a patch that fixes a known issue, and quietly creates a new one. Who is going to know, off-hand, that the code causes a hardware glitch at regular intervals on Intel / AMD processors that causes the kernel to check a memory location and execute any code found there?

It's not like someone is going to submit a patch that looks like "LOL. if(username == "w00t!") { privilegeescalationcode(); fork(); } "; they aren't even going to do "code that patches something(); code for a completely unrelated area that introduces a backdoor()"; they're going to introduce some code that fixes a known problem that also introduces privilege escalation if you had access to the UV mask at the foundries, and traced the pathways manually to find a bug that even Intel / AMD are unaware of; remember, plausible deniability is where it's at. Hands up the number of people who knew about the hidden debug mode found in AMD processors, and reported on /. a while back?

Re:Moles at Microsoft and apple

[lightknight]

Because it's difficult to place bugs in the Source code that won't be discovered during quality testing (laugh with me, but yes, some companies do do it) or by your fellow developers.

Er, export restrictions?

[girlintraining]

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.

This also begs the question of why they allowed shorter keys to begin with... o_o

Re:Er, export restrictions?

[oodaloop]

And the second amendment means I have the right to encryption.

Re:Er, export restrictions?

[TheRealMindChild]

Why are we screwing with 1024-bit keys? Why aren't we using keys that are 1048576-bits?

Re:Er, export restrictions?

[morcego]

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

Re:Er, export restrictions?

[Anonymous Coward]

Maybe if we lived in the 20th century. The laws have been greatly relaxed.

Re:Er, export restrictions?

[nzac]

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.

Re:Er, export restrictions?

[nzac]

Sorry got my maths wrong its only about about 300 million times longer.

Re:Er, export restrictions?

[FrankSchwab]

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

Re:Er, export restrictions?

[Bengie]

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.

Re:Er, export restrictions?

[Anonymous Coward]

Because RSA-2048 keys (twice the length of RSA-1024) ...

Actually, RSA-1025 bit would be twice the length of 1024 bit. 2048 is just twice the number, not the complexity. Remember, every bit you add doubles the number of permutations.

Re:Er, export restrictions?

[betterunixthanunix]

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.

Re:Er, export restrictions?

[Anpheus]

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.

Re:Er, export restrictions?

[Anonymous Coward]

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.

Re:Er, export restrictions?

[Anonymous Coward]

Java still ships with a max 128bit key restriction by default though due to some countries import restrictions (or so they say, but I'm sure some countries have more strict import restrictions than "anything less than 128bit is fine!"), gotta download additional files from their site if you don't want that restriction.

Re:Er, export restrictions?

[Tastecicles]

what's wrong with shorter, cascading keys using different algorithms?

Re:Er, export restrictions?

[betterunixthanunix]

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

Re:Er, export restrictions?

[plover]

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.

Seriously? Dupe already? heh

[_Shorty-dammit]

http://it.slashdot.org/story/12/07/10/2122220/microsoft-revokes-trust-in-28-of-its-own-certificates

Re:Seriously? Dupe already? heh

[_Shorty-dammit]

ok, I suppose it's not quite a dupey as it could be. But still, heh.

ISPs have been rejecting CSR requests

[Anonymous Coward]

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.

Re:ISPs have been rejecting CSR requests

[sapgau]

Wrong, ISP as in Internet Service Providers don't care what you are doing with your bits... It's the CAs (Certificate Authorities) who are not issuing certificates with CSRs of 1024 bits in length.

Well at least they're making a change

[joeflies]

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.

Re:Well at least they're making a change

[Goaway]

Those are also encryption keys. They are most often used for signing, or for encrypting a symmetric key, but they are encryption keys.

Re:Well at least they're making a change

[Anonymous Coward]

Correct... sort of.

For secure email, the sender encrypts with a 1024 bit public key. The recipient used the matching private key to decrypt. Only holders of that key can do so.

For signing, the signer encrypts with a 1024 bit private key. The verifier used the public key to decrypt. If the verifier can do that and the hashes match, it's a legit signature. Anything encrypted with the private key is by definition signed. The 1024 bit public key isn't the signature - it's the key used to verify the message was encrypted with the matching private key as only holders of the private key can make messages decrypt-able by the public key. There is no separate 'signature' so to speak - only messages that have been encrypted with your private key. The 'signature' part comes from the idea that the message was encrypted with your private key and that only you have it.

When you send a CSR to be signed by say Verisign, you are sending your public key. They use one of their private keys to sign your public key. Anyone can use Verisign's public key to recover your public key which is then used to send encrypted messages to you. You know Verisign vouches that your public key is really your public key so everyone knows only you will have the private key.

In theory anyway...

For SSL sessions, the following happens (in essence - the basic idea holds though I may be wrong on some specifics):
1.) You get the site's signed (encrypted with Verisign's private key) public key (1024, year or two validity).
2.) You decrypt the signed key with (Verisign's) public key (much longer length and validity) obtaining the site public key and proof of identity of the site.
4.) Algorithms, protocols and such are negotiated - highest common denominator for all parties.
5.) You generate symmetric session keys (RC4, 128 bit perhaps) and encrypt them with site's public key and send them along.
6.) Site decrypts your message with their private key to obtain the session keys.
7.) Session keys are used for traffic for the remainder of the session.

1024 bit is used in one way or the other in all case. It is not used exclusively in all cases.

Re:Well at least they're making a change

[Anonymous Coward]

Since you're being pedantic as it is, they're actually used to sign a hash function's output or to encrypt a symmetric key.

1024?

[Anonymous Coward]

The basic minimum should be at least 4096. 1024 was so 1999.

Re:1024?

[cryptizard]

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.

Re:1024?

[ebob9]

Posting to remind me to quote this when we're all having discussions about the need to require 16,384bit keys.

Re:1024?

[bloodhawk]

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.

How does that help?

[Anonymous Coward]

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.

Re:How does that help?

[Anonymous Coward]

Flame took advantage of multiple vulnerabilities, of which the enabled code-signing was just one of them.

financial implosion

[harvey the nerd]

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.

Get rid of crypto patents

[betterunixthanunix]

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

Re:Seriously? Dupe already? heh

[sapgau]

It's a follow up to the so thought dupey.

What about 802.1x?

[Anonymous Coward]

There are still a shit ton of people using 1024 bit keys for wireless authentication who are going to be quite grumpy when their shit stops working.

PCI Compliance

[Sprouticus]

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