Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Security Microsoft Programming IT Technology

Microsoft Drops Aging Encryption Schemes 199

christchurch wrote to mention an Eweek column about Microsoft's decision to stop using DES, MD4, and MD5 for encryption in Vista. From the article: "All three algorithms show signs of 'extreme weakness' and have been banned, Howard said. Microsoft is recommending using the Secure Hash Algorithm (SHA)256 encryption algorithm and AES (Advanced Encryption Standard) cipher instead, he said. The change is part of a semi-yearly update to Microsoft's Secure Development Lifecycle policies by engineers within Microsoft's Security Business & Technology Unit."
This discussion has been archived. No new comments can be posted.

Microsoft Drops Aging Encryption Schemes

Comments Filter:
  • ROT13 (Score:5, Funny)

    by Anonymous Coward on Friday September 16, 2005 @07:37AM (#13574994)
    Presumably they haven't banned ROT13 then.
    • Re:ROT13 (Score:5, Funny)

      by wertarbyte ( 811674 ) on Friday September 16, 2005 @07:52AM (#13575084) Homepage
      Funny enough, IIRC Outlook Express is still not able to encrypt messages with ROT13. It just has the ability to decode them.
    • Re:ROT13 (Score:5, Interesting)

      by Anonymous Coward on Friday September 16, 2005 @08:04AM (#13575165)
      It wasn't banned for XP. Check out HKEY_CURRENT_USER\Software\Microsoft\Windows\Curre ntVersion\Explorer\UserAssist to see for yourself.
      • Check out HKEY_CURRENT_USER\Software\Microsoft\Windows\Curre ntVersion\Explorer\UserAssist to see for yourself.

        Interesting indeed.

        (note: go into the subdirectories -- for me, the second one has TONS of stuff rot13'ed)
  • by Anonymous Coward on Friday September 16, 2005 @07:37AM (#13574999)

    i thought they where just one way hashing algos

    • by iamplasma ( 189832 ) on Friday September 16, 2005 @08:00AM (#13575135) Homepage
      Well, it is true that they're hashes, not encryption methods but they can be used in a quasi-encryption manner. In particular, when it comes to hashing passwords to store an "encrypted" password, it is to a large extent the same as trying to break a known encrypted document where the key is the password. In fact, that's exactly how older unices store passwords, DES encrypting a blank document with the password as a key. So while it's true that MD5 isn't an encryption method, for the purposes of password authentication is it practically identical.
      • by MoogMan ( 442253 ) on Friday September 16, 2005 @08:32AM (#13575338)
        No. no. no. Encryption is reversible. Hashing is not. These are definitions, please stick to them. Encryption != Hashing. Once again, for brevity (as lots of people get this wrong): Hashing is NOT Encryption.

        There is some correctness in your comment, however: Authentication. Hashing is indeed for Authentication (Is someone who they say they are?). Encryption is for keeping data confidential (I only want foo and bar to be able to read this). Please do not mix these up!
        • by Urusai ( 865560 )
          You can always just take your favorite symmetric key encryption algorithm and XOR successive blocks to produce a hash. This may have weaknesses for particular algorithms (IANAC).

          A hashing algorithm, as we all know, is just a many-to-one function (not reversible in general). f(x)=0 is such a hash function. It exhibits disappointing collision characteristics, though. f(x)=x avoids this complication, although it is reversible. Uh oh, now Microsoft's gonna steal and patent my elite hashing algorithms.
          • You can always just take your favorite symmetric key encryption algorithm and XOR successive blocks to produce a hash.

            And you can always embed your favorite hashing algorithm in a Feistel network to create a block cipher. Not that it's a good idea.

        • I don't understand.

          When you configure a Cryptographic Provider for a Certificate Server, you're asked to specify your choice of hashing algorithm (MD2, MD4, MD5, SHA-1). What's that for?
    • by Anonymous Coward
      Actually, MD5 can be (ab)used to act as a stream ciper. Roughly, MD5 can generate a pseudo-random stream of bits, by running it in a feedback loop primed with a secret key. This stream is then XORed with the data to provide encryption. The receoved uses the same feedback loop with the same key to XOR the ciphertext with the stream to recover the plaintext.

      Cisco TACACS+ is an example where MD5 encrypts a session.
    • You are correct, MD4 and MD5 are hashing functions. and hashing functions are one-way. Hashing is typically used within encryption - say to generate reasonable keys from pass-phrases. You could use them as an "encryption mode" (a method of using different keys per block) by hashing the prior unencrypted block and using the result as the new key.

      Well, there is ONE possible exception to this. You can use hashes for error-correction. If you have enough hashes over enough slices of the data, you could actually

  • Teamwork (Score:3, Funny)

    by Ruie ( 30480 ) on Friday September 16, 2005 @07:37AM (#13575002) Homepage
    The change is part of a semi-yearly update to Microsoft's Secure Development Lifecycle policies by engineers within Microsoft's Security Business & Technology Unit

    As opposed to the quarterly update by managers ?

  • by cryptoz ( 878581 ) <jns@jacobsheehy.com> on Friday September 16, 2005 @07:38AM (#13575005) Homepage Journal
    Even if Vista and related products use higher encryption, Windows' obsessive temp file creation, along with swap files, seems to minimize the effect that using encryption has, right?

    I mean, sure, it'll be much harder to brute force any MS encryption now, but did people do it that way before? Weren't there always other workarounds that will still be present?
    • Re: (Score:3, Insightful)

      Comment removed based on user account deletion
      • by cpeikert ( 9457 )
        As far as I am aware, predicting a md5 collision has not been done.

        I don't know what you mean by "predicting," but yes, concrete MD5 collisions exist. I.e., two files, with different contents, that have the same MD5 hash (and the same size, to boot). They are printed in the paper that first announced the MD5 break. Further work has shown that additional collisions can be generated at will in minutes on a common laptop computer.
    • This change has nothing to do with security.
      It's all about buzzword-compliancy. It's managers who decide on a company's spending; the managers read overhyped news about "SHA1 getting broken" while the only thing the recent papers provided was a very expensive method to brute-force a hash collision -- [b]any[/b] collision, not a message that matches a given hash. In the managers' minds, those encryption algorithms are worthless now -- and it's a very well-known fact that managers never accept being correct
      • by amodm ( 876842 )
        While I agree with your "securing a million dollar tank with a clothesline peg" statement, the actual discard of the older algos might make a lot of sense from a decision making perspective.

        This is going to be a major (debatable) release for Microsoft after a long long time. Typically the time gap between major releases is huge for microsoft. In this time gap, all kinds of new attacks against crypto algos are discovered (http://it.slashdot.org/article.pl?sid=05/08/18/22 47245&tid=93&tid=172 [slashdot.org]).

        If they
      • your "weakest link" argument makes an interesting point ...

        however, I'd like to point out two things:

        (1) Attacks get better. The Sha-1 attacks are improving. They're at least 64 times faster now than the initial publication, which is itself about 2000 times better than a brute force attack. This is drawing near the range of computability now. Sure, not like WEP or LanMan computability, but it's still broken.

        (2) Which is better? Continuing to support and enforce weak, fragile, or downright broken standa
      • by Fahrenheit 450 ( 765492 ) on Friday September 16, 2005 @10:27AM (#13576294)
        I was going to mod you Overrated, but I decided to post instead.

        This is not about buzzword compliance. The three algorithms that they are banning should have been done away with years ago. DES has been fairly easily crackable via burute force for nearly a decade now, and MD4 has had issues for just about as long. And now that collisions can be found for MD4 essentially by hand, it shouldn't be used for anything of any importance.

        Hell, even NIST is recommending that people start figuring out ways to phase out their use of SHA-1, which is still practically secure, but starting to show cracks. And if there ever was an orginization free of buzzwords, it's NIST (I dare you to read some of their FIPS documents without passing out).

        This is a good move that nedeed to be done. It's a step in the right direction -- now they need to get on with shoring up the other holes in their codebase.
    • by amodm ( 876842 ) on Friday September 16, 2005 @07:52AM (#13575083)
      Add to it the fact that they didn't use to clear off the clear text passwd (as entered by user) from the memory.

      As a result of this, people could easily do a memory scan of lsass.exe to get the passwds of last few users who had logged on.

      See http://www.cr0.net:8040/misc/cachedump.html [cr0.net]
    • by RealityMogul ( 663835 ) on Friday September 16, 2005 @07:56AM (#13575115)
      I wonder if they're still going to support the LANMAN hashes in Vista. Nothing is quite as smart as storing the easily cracked hash right next to the more secure one.
    • Indeed, but what is interesting is that this may cause some challenges to *nix-windows interoperability. Many installed linux servers will have been using the "older" encryption bases for domain logons and samba shares. These are not unovercomeable but may prove to be challenging on the implementation side.
  • Great... yet another reason to upgrade hardware when planning for a Vista install.

    Gotta add more cycles to the those brute-force attack teams!
  • by LiquidCoooled ( 634315 ) on Friday September 16, 2005 @07:41AM (#13575019) Homepage Journal
    Developers who use one of the banned cryptographic functions in new code will have it flagged by automated code scanning tools and will be asked to update the function to something more secure, Howard said.

    C:\ > make windows.vista
    ERROR: Insecure code found.
    Please upgrade code to Linux.
    • After not being able to see source code, more strict DRM management, and monitoring of incoming/outgoing connections, yet another freedom that goes away: the one to code wtf-ing algo you want (oh, sorry: I forgot software patents, of course).

      Instead of investing in informing developers that those algorithms aren't really secure, and letting university CS courses around the world to do their job, Microsoft just forbids you to use them.

      Btw, how can you write an application that has to retain compatibility wit
  • Allowed by US Gov? (Score:4, Interesting)

    by guruevi ( 827432 ) on Friday September 16, 2005 @07:42AM (#13575028)
    Is that even allowed by US Gov. to export that to other countries? I thought that there was a limit of encryption and everything above ...bits was banned from exporting (remembering 56-bits encryption Windows NT).
    • by Xiph ( 723935 )
      well, if the people writing the encryption are in china, they're not exporting it but importing it.
      which is yet another reason to offshore if you're multinational.

      so imposing an export ban on software is kinda hard. seeing as it's hard to determine where it originates, without accessing the machines it was made on, - even that can be faked.
    • It's called Export Control. Usually it falls under products that are developed by Government Contracting companies that sell their products to the Government. For example, if Lockheed Martin develops a new propulsion technology for rockets and sells it to the US Government, it would be Export Controlled and Lockheed would not be allowed to sell or even share details about that technology to customers/vendors outside of the US. Doing so, is an export violation and subject to fines and penalties under US L
    • by Antique Geekmeister ( 740220 ) on Friday September 16, 2005 @08:06AM (#13575180)
      It's more complex than that. There used to be a regulation in the US Customs department that forbade exporting encryption tools, classifying them as a "munition" or material of war. The result was that OS vendors would put the encryption tools on a separate tape or CD, to be shipped only if you swore on a stack of Constitutions that you were allowed to receive it. For years, the only way to be sure of getting your copy of PGP source code was to download it from Finland, which had no such silly laws.

      This got fought in court for years, and was eventually ruled unconstitutional, so the regulation was immediately transferred to the Commerce department, where it is fighting its way through the courts !!!again!!!. In the meantime, the departments involved have relented enough to permit big corporate campaign contributors, like Microsoft and the other OS vendors, to include basic encryption capabilities.

      But the US government still would strongly prefer that all such tools have some form of backdoor. That's why they developed the Clipper chip for use in cell phones, which was dropped when it turned out to work well but could be reprogrammed with a genuinely private key with a bit of work, and why the "Trusted Computing" initiative by Microsoft and their peers keeps the master encryption keys in the hands of "authorized distributors", mostly Microsoft. This means you can't use the Trusted Computing chips without someone signing off on your keys because the system won't accept unsigned keys, and that means handing over money to buy a key and identifying yourself so that law enforcement can find you if your key turns up anywhere they don't like it. It also gives a convenient central location to serve with a subpoena to get your keys, without your ever being notified of the subpoena.

      Various computer companies are willing to accept the centralized key and subpoena burdens in order to actually get robust encryption and authentication for their tools, but we need to be aware of the little details and their potential for abuse. Trusted Computing won't change the US regulations, but since they're regulations and not law, it's easy for the government to turn a blind eye at its own whim to its export, especially to prevent the general use of more robust or subpoena-safe encryption.
      • "...but since they're regulations and not law..."

        Regulations are laws. (Yes, IAAL.) So no, it's not "easy for the government to turn a blind eye" to violations.

        Makes me wonder how much more of your confidently penned reply is factually based.

    • The law was loosened up quite a bit when someone (I cant remember who and google isnt turning up any usefull links) went to challenge the export regulations in the courts (AFAIK it was under freedom of speech where they wanted to be able to share source code for encryption and discuss algorithims and such but were not allowed to by the export regs).

      So, presumably the government saw that rather than risk loosing control over encryption completly because of a supreme court decision or something, they decided
    • by swillden ( 191260 ) * <shawn-ds@willden.org> on Friday September 16, 2005 @08:13AM (#13575205) Journal

      I thought that there was a limit of encryption and everything above ...bits was banned from exporting

      That has changed. Back in the days of Windows NT 4, cryptographic algorithms were classified as munitions under ITAR [wikipedia.org]. In the late 90s the law was changed, removing this classification. These days, there are still some export controls on crypto, but it's fairly easy to get a permit to export anything that uses a standard, well-known algorithm, pretty much independent of key size.

    • Note the widespread availability of AES. While not developed by US researchers, the actual AES standard is the US government's new offical standard for symetric key encryption. It's authorized for use in both secret and top secret applications.

      This was a major change in operation, as it used to be that the algorithms used for secret encryption were themselves secret.

      What seems to have happened is the government has been made to realise that strong crypto exists all over the world. Thus to restrict is artifi
  • by bigtallmofo ( 695287 ) on Friday September 16, 2005 @07:45AM (#13575041)
    DES, MD4, MD5 and, in some cases, the SHA1 encryption algorithm, which are "way too complicated to understand," said Michael Howard, senior security program manager at the company. "Instead, our R&D lab is doing great things with sophisticated XOR encryption that should be enough security for just about anyone."

    • I actually think the real reason could be pure marketing.

      Windows no longer uses the insecure encryption that certain other OS' use, upgrade your security now, upgrade to Vista.

      A classic quote to appeal to the PHB's and their ilk.
      • Except that linux, apache, mozilla etc, have supported 256-bit aes for years, and only support weaker ciphers in order to maintain compatibility with microsoft systems, the current versions of which don`t support anything stronger than 128-bit rc4.
    • by scruffy ( 29773 ) on Friday September 16, 2005 @08:01AM (#13575143)
      In addition, Microsoft doesn't hold any patents on those algorithms, and they have open specifications.
    • I was about to say -- I wonder if they'll be dropping that ultra-secure XOR encryption option from Excel password protection!

      (Note: working from home right now, with three-year-old Office X -- don't know if current versions of Office still have the XOR option.)

  • by myukew ( 823565 ) on Friday September 16, 2005 @07:45AM (#13575042) Homepage
    this post is rot13 encrypted. twice. to improve security.
  • I'm not sure but.... (Score:5, Interesting)

    by amodm ( 876842 ) on Friday September 16, 2005 @07:46AM (#13575045)
    wasn't NTLM slightly based on/uses DES ? If thats the case, then does it mean that they are changing the algo used in SAM too ?
  • by Anonymous Coward on Friday September 16, 2005 @07:53AM (#13575092)
    If this is true then LM hashes, which use DES, are on their way out finally. It's going to break some backwards compatibility, but it will go a long way in fixing some of the most obvious, http://www.antsight.com/zsl/rainbowcrack/ [antsight.com], privelage escalation problems.
  • by dAzED1 ( 33635 ) on Friday September 16, 2005 @08:03AM (#13575159) Journal
    Anyone that disagrees that removing these "encryption" methods is bad, is obviously just a troll. /sarcasm

    Ok, question: what does Windows use hashes for, other than the updater (if even that)? Can't the updater just change what it supports, and leave the other hash tools alone?

    How about some real security enhancements, Gates?
    • All the passwords are stored/transmitted as hashes.

      Switching to SHA1 hashes only will break compatibility with everything earlier than XP.. which is probably what MS really want - force everyone to upgrade.
  • Doh ... (Score:3, Interesting)

    by BlueTrin ( 683373 ) on Friday September 16, 2005 @08:06AM (#13575177) Homepage Journal
    Anyway they can use whichever algorithm they want ... bad implementation/planning is the cause of their security holes.

    Soon in Vista, 120xDES and AES implemented as default algorithms but windows media player will run any command sent remotely ...
  • by Rob T Firefly ( 844560 ) on Friday September 16, 2005 @08:09AM (#13575188) Homepage Journal
    Microsoft has promised additional encryption schemes for power users, including ig-pay atin-lay, leaving out every third word, and Navajo code talkers.
  • Yeah, but Microsoft continues to use RC4 in protocols such as SSL and RDP...

    Isn't it time to abandon RC4 too while they are at it?
  • Has any major distro changed or announced plans to change their password hash format in /etc/shadow?
  • by Bert64 ( 520050 ) <bertNO@SPAMslashdot.firenzee.com> on Friday September 16, 2005 @08:25AM (#13575291) Homepage
    Firefox and other mozilla based browsers already support 256-bit AES encryption for ssl websites, as does apache..
    On the other hand, IIS and IE support nothing stronger than 128-bit RC4.. so be dropping RC4 they will lose compatibility with older versions of their own products, but maintain compatibility with their competitors.
  • by mjh ( 57755 ) <mark@hoCURIErnclan.com minus physicist> on Friday September 16, 2005 @08:28AM (#13575311) Homepage Journal
    These are newcomers. Shouldn't that give us some pause as to how much we should rely on them? Yes they've been well studied. But compare AES with DES. It's been around forever and the only weakness that we know of is keylength. Do we really have enough exposure to the "new guys" to put confidence in them to switch everything to them?
    • There's already a crack for AES.. check the archives.

      Any encryption will be broken given enough time... for most people it really isn't an issue - for example your browser communication only needs to be 'secure' for about 10 seconds to do a transaction.
    • Bwahahah. One of the stupidest post i've ever seen to get modded up to 5.
    • AES & SHA256 are young. These are newcomers.

      If you know of an exploitable, real-world weakness in AES, there's a doctorate degree from any university in the world and a high six-figure salary with your name on it. The U. S. Government, in particular, would be interested in learning of a weakness in AES, since it uses AES for many secret and top secret-classified transactions.
    • AES has been evaluated and weighed in on by lots of heavyweights, including major universities, the NSA, and so on. They all claim it's secure. What's more, the US government has authorized its use for encrypting secret and top secret data. Presumably they wouldn't do so if they weren't confident in its security.

      Do remember that AES was around long before it became AES. It was orignally Rijndael, which was first published in 1998. True, that's not the same as DES's multi-decade legacy, but it's still a long
  • I wonder if Microsoft sees new products as a fresh start and a chance to completely redeem themselves from prior flaws. I would expect them to have a series of meetings to say, "Where did we go wrong last time" and vow to eliminate those issues. Let's hope they use this opportunity to release something solid and stable from the beginning. We can't expect perfection, but they can definitely do better than they have in the past.
  • by hritcu ( 871613 ) on Friday September 16, 2005 @08:38AM (#13575386) Homepage
    Well ... I know that these criptography standards are begining to be dated, and it is very likely that we will see more successful brute force atacks on them in the following years. However, I wonder if changing them will have a noticeable positive effect on the security of Vista. How many of the many exploitable holes in Windows XP are due to bad criptography, and how many are due to bad design and policies?
  • HTTP Digest (Score:5, Interesting)

    by hey ( 83763 ) on Friday September 16, 2005 @08:41AM (#13575402) Journal
    MD5 is used in the HTTP digest authenticattion.
    I hope they'll still support that!
    • Presumably not.

      The opportunity to break compatibility with all 3rd party browsers? MS will jump at the chance.

      I'm guessing it'll be kerberos auth only.
    • Re:HTTP Digest (Score:3, Interesting)

      by HermanAB ( 661181 )
      Only flagged in new code.

      Presumably MS hasn't changed that part of IE since version 1 and it will stay that way.
    • (Putting on pointy-hair wig)

      MD5 is deprecated, but every web server still supports basic authentication, which uses Base64. Hmm.

      64 is much bigger than 5, so it must be better.

      Yup. No more digest authentication, only basic will be supported! Another security problem averted; quick: call the press!
  • by Anonymous Coward
    I checked and it looks like MD5 has the same problems any hashing function would. Namely that you can't take infiniti and squeeze it into a jar of fixnum bytes without more than one number between 0 and infiniti resulting in the same value for F.
    • The problem is that collisions, i.e. two inputs that hash to the same value, can be found in much less time than wold be expected (a couple of hours instead of the expected couple thousand years).

      And while this doesn't allow a lot of interesting attacks (though we have already seen where one can use these collisions to create two postscript documents or TIFF images that display different contents, but hash to the same value), it is still a major weakness with the algorithm that may lead to further more
    • Yes, the only "solution" is to keep making the jar bigger. which is why they go with SHA256.
      • Yes, the only "solution" is to keep making the jar bigger. which is why they go with SHA256.

        Not even close.

        The ideal hash function has an equal probability of all possible results for any given input. Let's look at a non-ideal one: h(x) = 1. Now, any input results in the same hash value. Is that email signature valid? Sure: it has the expected hash! Did that ISO come through intact? Sure: the hash matches! Wouldn't be very useful, would it? In this simplified example, returning a 1024-bit hash v

  • Microsoft Drops Aging Encryption Schemes

    In other words, Microsoft Drops AES?
    Man, I'm so confused now. :-p

    ...

    OK, you can stop throwing /tomatoe?s/ now.

  • by boatboy ( 549643 ) on Friday September 16, 2005 @09:38AM (#13575827) Homepage
    The article is in plain English. I haven't seen it on MSDN yet, but I imagine this is the gist in developer-speak:

    Microsoft will be marking the DES, MD4, MD5 and SHA1 encryption provider classes obselete in upcoming versions of the .NET framework. While not completely insecure, these algorithms have documented vulnerabilities which mean they can be cracked or exploited in certain scenarios. FxCop will warn you when it finds these classes in use, and provide a suggested fix. Typically, this will simply envolve switching the provider you are using with the more secure SHA256 or AES providers.
  • Expired SHA (Score:2, Interesting)

    by Anonymous Coward
    Could this been due to the patent on SHA has expired? And NSA wants to keep control of all things being crypted?
  • It doesnt make much difference if they're going to use better encryption-- when the plain-text is so vulnerable to trojans, phishes, BHO's and viruses.
  • Heh heh...

    If Microsoft is kind enough to continue using TEA encryption in the Xbox 360 for the bootstrap initialization, perhaps it will not be so unhackable.

    Probably not, but my personal belief is that MS would be dumb to make it unhackable, as mod chips have probably been responsible for a lot of console sales, and in turn, a lot of good word-of-mouth PR in the trenches.
  • by richg74 ( 650636 ) on Friday September 16, 2005 @09:58AM (#13576024) Homepage
    I hope that Microsoft can pay more attention to implementing the cryptographic functions correctly than they have at times in the past. Bruce Schneier has a note in his Crypto-Gram newsletter [schneier.com] for February 2005 on a flaw in MS's implementation of RC4:
    One of the most important rules of stream ciphers is to never use the same keystream to encrypt two different documents. If someone does, you can break the encryption by XORing the two ciphertext streams together. The keystream drops out, and you end up with plaintext XORed with plaintext -- and you can easily recover the two plaintexts using letter frequency analysis and other basic techniques.

    ...
    Microsoft uses the RC4 stream cipher in both Word and Excel. And they make this mistake. ...
    He cites a paper [iacr.org] by Hongjun Wu, as well as a report [bindview.com] of an earlier (1999) MS crypto vulnerability.
  • RC4 is a stream cipher which has been on shaky ground for a long time. There are two problems with RC4. The first is that the data is not as random as it could be, at the beginning. The way RC4 works, you put in a key and then it generates a string of random bytes which you XOR with your plaintext to encrypt. But there are weaknesses in the randomness of the first part of RC4's key stream. To fix this experts recommend throwing away the first N bytes. The problem is that nobody can agree on what N should be
  • by szyzyg ( 7313 ) on Friday September 16, 2005 @11:57AM (#13577240)
    Right now you can generate SHA256 hashes, but you can't sign anything using SHA256 because it's not supported. Mono of course handles this without any problem.

...there can be no public or private virtue unless the foundation of action is the practice of truth. - George Jacob Holyoake

Working...