Slashdot Mirror
Microsoft Drops Aging Encryption Schemes
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."
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.
Blah blah sig blah blah blah irony blah blah
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
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.
Not completely correct. You sign a document by hashing it and then encrypting the hash with your secret key. So everyone else can check that you signed it by decrypting the hash, hashing the document themselves and comparing the two hashes.
Unfortunately it's not that simple. The way the US government sees it, if you do business in the US, you're covered by their laws; and so if your company does business in the US, and also sells encryption software to Cuba or Iran, you can bet your life your US office will be prosecuted, whether your HQ is in Brazil or Belize.
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.
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.
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. 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 to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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!
MD5 is used in VeriSign, I think, for adding the digital signature to your software so you know it is "secure"
" That doesn't sound right to me. The whole point of keypair encryption is that anyone with the public key can encrypt, but only the people with the private key can decrypt."
Not quite.
Whilst it is true that any data encrypted with a public key can be decrypted only with a private key, the converse is also true. Any data encrypted with a private key can be decrypted only with the public key. This means that whoever encrypted it must have had access to the private key and thus it gives confidence in where it originated.
It does not provide any confidentiality - but it's not supposed to, it is supposed to provide Integrity and message origin authentication.
This is the corner stone of digital signatures.
This has already been done.
/etc/shadow. If the passwords start with $1$ that means it's MD5, if it says $2$ that's blowfish.
In case you're curious here's some info on the redhat mailing list about it.
Note that this message is from 2003, but still not a lot has been done.
It is possible though... you can check if your system uses md5 or blowfish by looking in
Well, they are actually not that different. Any block cipher (like AES) can easily be used as a hashing algorithm (using the last block as the "digest") with fixed key/IV. It can be used as a MAC the same way by varying the key.
Hashing algorithms can as well be used as stream ciphers. Since they have the property that they are "cryptographically secure" - ie. their output could as well have been random for all you care - they can be used to create a stream of pseudo-random bytes that you can XOR your message with.
The real difference between hashing algorithms and "real" two-way encryption is efficiency! Hashing algorithms are also commonly called one-way encryption schemes.
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.
- Convert the password to unicode
- Calculate the MD4 hash of the unicode password
- Null-pad the 16-byte hash to 21 bytes
- Split this into three 7-byte DES keys
- DES-encrypt the 8-byte challenge from the server with each key
- Concatenate the three ciphertexts into the 24-byte NTLM response
SIDs do not play a role in NTLM authentication (or any of the variants); they are used for authorization (rather than authentication).The SAM stores both the LM hash (although this can be disabled) and the NTLM hash (which is the MD4 of the unicode password). The NTLMv2 hash is the HMAC-MD5 of the uppercase unicode username + uppercase unicode authentication domain, using the NTLM hash as the key. As it can be derived from the NTLM hash, the NTLMv2 hash is not stored separately.
There are several attacks to recover the password from the old LM hash; all of which are practically irrelevant. If you have access to the raw hashes themselves (LM, NTLM, or NTLMv2), you can impersonate the user over the network (as the response to the server's challenge is calculated using the hash, not the plaintext password). The hash is effectively a plaintext equivalent.