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."
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.
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?
I am John Hurt.
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.
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.
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.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
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.
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.
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.
24 beers in a case, 24 hours in a day. Coincidence? I think not!
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.
"I've got more toys than Teruhisa Kitahara."
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.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
They can do that at their 2k qbit quantum computer?
Rethinking email
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?
Palm trees and 8
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.
Not a sentence!
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
Palm trees and 8
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.
Sig Battery depleted. Reverting to safe mode.
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.
Is there any evidence at all? Really wondering.
Also, I seriously doubt a 'contact' at Apple or Microsoft is going to know about spies.
"First they came for the slanderers and i said nothing."
Not to mention:
http://www.schneier.com/crypto-gram-9909.html#NSAKeyinMicrosoftCryptoAPI
If you need web hosting, you could do worse than here
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.
"His name was James Damore."
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.
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?
ACs don't waste your time replying, your posts are never seen by me.
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.
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?
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.
"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.
We`re all equal
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?
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*