Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Microsoft Warns Customers Away From RC4 and SHA-1

Soulskill posted about a year ago | from the avoiding-collisions dept.

Encryption 92

Trailrunner7 writes "The RC4 and SHA-1 algorithms have taken a lot of hits in recent years, with new attacks popping up on a regular basis. Many security experts and cryptographers have been recommending that vendors begin phasing the two out, and Microsoft on Tuesday said it is now recommending to developers that they deprecate RC4 and stop using the SHA-1 hash algorithm. RC4 is among the older stream cipher suites in use today, and there have been a number of practical attacks against it, including plaintext-recovery attacks. The improvements in computing power have made many of these attacks more feasible for attackers, and so Microsoft is telling developers to drop RC4 from their applications. The company also said that as of January 2016 it will no longer will validate any code signing or root certificate that uses SHA-1."

cancel ×

92 comments

Sorry! There are no comments related to the filter you selected.

In other news (-1)

Anonymous Coward | about a year ago | (#45409537)

Customers warn Microsoft to stay the fuck away from Windows 8, as it's "awful."

Pay no attention to the man behind the Back Door.. (5, Insightful)

icebike (68054) | about a year ago | (#45409547)

Why in gods name would a company that backdoored their entire crypto stack to the NSA worry that
some crypto code is weak?

Re:Pay no attention to the man behind the Back Doo (1)

AHuxley (892839) | about a year ago | (#45409617)

Its not just the codes used, its the US branded: OS, file systems, "bugs" and files sent.

Re:Pay no attention to the man behind the Back Doo (0)

Anonymous Coward | about a year ago | (#45409669)

last thing they want is you to repudiate the evidence against you

Re:Pay no attention to the man behind the Back Doo (1)

bob_super (3391281) | about a year ago | (#45409673)

Because the NSA doesn't like when someone else can get your files.
It slows them down.

Re:Pay no attention to the man behind the Back Doo (1)

LordLucless (582312) | about a year ago | (#45409761)

Because although they gave it the NSA, they still don't want the Chinese government to compromise it?

Re:Pay no attention to the man behind the Back Doo (3, Insightful)

LongearedBat (1665481) | about a year ago | (#45409813)

Because... the NSA pays MS for backdoors, whereas the Russians don't?

Because... the NSA tries to stay under the radar, whereas other malware often doesn't? (ex. adware, bot-nets. Thus damaging the MS "experience".)

Because... the NSA wants to know your secrets, whereas scammers want to use your secrets? (ex. Credit card payments. Further damaging the MS "experience".)

Just a few thoughts.

Re:Pay no attention to the man behind the Back Doo (1)

El_Muerte_TDS (592157) | about a year ago | (#45410943)

Why does the NSA want to know my secrets if they are not going to use it?

Re:Pay no attention to the man behind the Back Doo (0)

Anonymous Coward | about a year ago | (#45411025)

They're data-horders, and well they probably want to have all of the data "just in case" it becomes useful. *cough cough* Blackmail. And that's not getting into their deranged belief that they need the largest haystack possible.

Re:Pay no attention to the man behind the Back Doo (0)

Anonymous Coward | about a year ago | (#45414209)

Lately MS is damaging the "MS experience" WAY more than any hacker could do.

Re:Pay no attention to the man behind the Back Doo (0)

Anonymous Coward | about a year ago | (#45409817)

Why in gods name would a company that backdoored their entire crypto stack to the NSA worry that
some crypto code is weak?

I dunno...

Why in god's name would you worry that...
your comment might not fit on readers' monitors?

"12:15 — press Return."

Re:Pay no attention to the man behind the Back Doo (0)

ruir (2709173) | about a year ago | (#45410273)

Mod parent up please, because it is the truth, wether you like it or not.

Re:Pay no attention to the man behind the Back Doo (0)

Anonymous Coward | about a year ago | (#45410477)

Evidence?

Re:Pay no attention to the man behind the Back Doo (0)

imikem (767509) | about a year ago | (#45411305)

[clickety-clickety]

There you go. Plenty of evidence. Oh, you want to SEE the evidence? Well, there's this thing called FISA, that says you aren't allowed to. Because, well TERRORISM.

Fnord.

You, over there: Papers, please.

Re:Pay no attention to the man behind the Back Doo (0)

Anonymous Coward | about a year ago | (#45411561)

The only evidence we seem to get these days is from leaks.

All other relevant FOIA requests are stone-walled.

Re:Pay no attention to the man behind the Back Doo (1)

thisisauniqueid (825395) | about a year ago | (#45410473)

Why in gods name would a company that backdoored their entire crypto stack to the NSA worry that some crypto code is weak?

Because they now have a better back door that needs to become the default.

Re:Pay no attention to the man behind the Back Doo (1)

aaaaaaargh! (1150173) | about a year ago | (#45410673)

Why? Because the attacks on RC4 are becoming feasible for ordinary well-organized criminals, and there might be other agencies aside form the NSA who might try brute-forcing SHA1.

The NSA is mainly a danger for business outside the US - and perhaps for Megaupload-like companies within the US for which some state prosecutor could imagine and construct some criminal copyright infringement case, although it seems that the NSA doesn't habitually help out the FBI.

Re:Pay no attention to the man behind the Back Doo (1)

SuricouRaven (1897204) | about a year ago | (#45411745)

They don't admit to helping the FBI. Look up 'parallel construction.'

Re:Pay no attention to the man behind the Back Doo (1)

icebike (68054) | about a year ago | (#45415607)

They no longer deny helping the FBI, DEA, ATF, and county sheriffs.

Re:Pay no attention to the man behind the Back Doo (1)

bill_mcgonigle (4333) | about a year ago | (#45411499)

We have a real problem where the PCI scanning vendors are so freaked out about BEAST attacks (where client hardening is the correct solution) that the only cipher they'll accept (server side) that's FIPS compliant and BEAST resistant is RC4.

What they should be doing instead is scoring people down for not doing ephemeral key exchange, scoring people down for not using TLS 1.2 and stop freaking out about CBC on the server side when getting rid of it is not even a thorough solution (fear of CBC is overblown, especially when compared to post-Snowden risks).

If you look at your ciphers, even if you're negotiating ephemeral ECC with Google, you're then using RC4 as your stream cipher. RC4 isn't _so_ horrible that this is a major risk, but it's a theoretical one and it might fall eventually. Ephemeral key exchange is there to prevent against future attacks on captured streams, so RC4 may not be the best pairing for that.

So, perhaps Microsoft is doing a good thing here and putting its weight behind some pressure to move past RC4.

Re:Pay no attention to the man behind the Back Doo (1)

devman (1163205) | about a year ago | (#45412233)

RC4 is NOT FIPS compliant. Never has been. RSA has never published a spec for RC4. The code just showed up one day on a mailing list from an anonymous source.

Re:Pay no attention to the man behind the Back Doo (1)

manu0601 (2221348) | about a year ago | (#45420045)

[for BEAST] client hardening is the correct solution

Indeed. TLSv1.1 is not vulnerable, and most browsers that are still limited to TLSv1.0 are able to use the 1/n-1 split workaround to BEAST (notable exception is Safari on MacOS up to X.8). The right approach would be to detect TLSv1.0 clients that do not use 1/n-1 split and deny them access before they exchange anything sensible.

Re:Pay no attention to the man behind the Back Doo (1)

Guppy06 (410832) | about a year ago | (#45416033)

Because Microsoft doesn't deliberately open back doors for free.

Re:Pay no attention to the man behind the Back Doo (0)

Anonymous Coward | about a year ago | (#45419451)

"This is weak against one party, why not keep it weak against ALL parties?"

Perfectly sound logic.

WHAT? (-1)

Anonymous Coward | about a year ago | (#45409583)

Encryption doesn't WORK? NSA is all up in my SHIT? WHAT?

The time has come the walrus said... (0)

Anonymous Coward | about a year ago | (#45409597)

No more RC4? No more SHA1? Next they'll be telling me to patch against WMF exploits.

Re:The time has come the walrus said... (0)

Anonymous Coward | about a year ago | (#45409689)

I'm not a security guy, but I immediately recognized, just from having been reading stuff, that SHA1 was considered broken many years ago.

Re:The time has come the walrus said... (3, Informative)

cheater512 (783349) | about a year ago | (#45409963)

MD5 is broken, SHA1 has been weakened slightly but it isn't broken.

The term broken is only used when it is trivial to crack and/or forge.

Re: The time has come the walrus said... (0)

Anonymous Coward | about a year ago | (#45410291)

The definition of broken is if you can get the key (or forge the signature as is the case here) faster than brute force, and since you can; it's broken.

Re: The time has come the walrus said... (1)

cryptizard (2629853) | about a year ago | (#45411513)

If that was true then pretty much every widely-used crypto system (AES, RSA, El Gamal, etc) would be "broken".

Re: The time has come the walrus said... (1)

F.Ultra (1673484) | about a year ago | (#45412363)

There is no faster than brute force attack for AES, unless you modify the algorithm to have less rounds but then it's no longer AES.

Re: The time has come the walrus said... (0)

Anonymous Coward | about a year ago | (#45412727)

you really should check before saying something that just isn't true.

This post on Bruce Schneier's site [schneier.com] from august 2011 talks about a discovered attack that works on all three keylenghts of FULL AES. All have complexity less than brute force.

-mto

Re: The time has come the walrus said... (1)

F.Ultra (1673484) | about a year ago | (#45415429)

Sorry, forgot about that one. While it's true that AES is broken, the attack in question is currently quite impractical since it requires a 2^88 data space

Re: The time has come the walrus said... (1)

Bengie (1121981) | about a year ago | (#45414333)

AES is considered broken, but safe to keep using.

Re:The time has come the walrus said... (2)

WaffleMonster (969671) | about a year ago | (#45410325)

MD5 is broken, SHA1 has been weakened slightly but it isn't broken. The term broken is only used when it is trivial to crack and/or forge.

Sorry to nitpick it really depends on how you use the algorithm. MD5 is broke for signatures yet still perfectly acceptable for other purposes.

Re:The time has come the walrus said... (1)

swillden (191260) | about a year ago | (#45412481)

MD5 is broken, SHA1 has been weakened slightly but it isn't broken. The term broken is only used when it is trivial to crack and/or forge.

Sorry to nitpick it really depends on how you use the algorithm. MD5 is broke for signatures yet still perfectly acceptable for other purposes.

This is true of anything. All statements about security are relevant only within a given set of threat models.

Re:The time has come the walrus said... (1)

aaaaaaargh! (1150173) | about a year ago | (#45410681)

That's not the definition of "broken" that cryptographers use.

Re:The time has come the walrus said... (1)

Joce640k (829181) | about a year ago | (#45411069)

MD5 is broken, SHA1 has been weakened slightly but it isn't broken.

Same for RC4. The cypher is still OK, you just have to initialize it better (his has been known about for decades, the fact that Microsoft isn't doing it is the real news).

Re:The time has come the walrus said... (1)

Anonymous Coward | about a year ago | (#45411959)

you just have to initialize it better

Specifically, you "just" need to discard the first n bits of the keystream, and n seems to get larger every year. Do excuse me if that doesn't inspire confidence.

Look, if you absolutely need to support some legacy application that only speaks RC4, that's one thing, but there's no reason beyond that to choose it over AES-256-GCM these days.

Re:The time has come the walrus said... (4, Informative)

fatphil (181876) | about a year ago | (#45411249)

Just plain wrong.

In the field of cryptography, the term "broken" is used whenever the work factor to crack is less than that of a brute force attack. Stevens' 2^61 collision attack against SHA1 means that SHA1 is broken.

Re:The time has come the walrus said... (0)

Anonymous Coward | about a year ago | (#45411615)

Right. It's not "broken" in the sense of "practical attacks are easy" but the writing is on the wall and you should replace it now rather than waiting for it to become a real problem.

Re:The time has come the walrus said... (3, Funny)

93 Escort Wagon (326346) | about a year ago | (#45410133)

No more RC4? No more SHA1? Next they'll be telling me to patch against WMF exploits.

Thank God we can still depend on ActiveX!

Re:The time has come the walrus said... (1)

LurkerXXX (667952) | about a year ago | (#45413819)

Or that we shouldn't use WEP for our wireless encryption.

crypto is for losers (0, Funny)

Anonymous Coward | about a year ago | (#45409627)

I remember this one dude was trying to get me to encrypt all my hard drives. But dude, I said, I want to be able to read my hard drives.

If SHA-1 is a problem, what does that make MD4? (3, Insightful)

fluke11 (1160111) | about a year ago | (#45409635)

Microsoft continues to make use of MD4 for password hashing in the Security Account Management part of the registry. The authors of MD4, RSA, had recommended for a long time switching to MD5 and now recommends using MD6, Other members of the security community also recommend using a stronger hash function, combining a salt string with the password and doing multiple rounds of the hash function. Microsoft has failed to do any of these recommendations.

MS-CHAPv2 also continues to be part of Microsoft's offering as well. Support for this is included in their OS for PPTP, iSCSI and 802.1x (and possibly others). As pointed out in the article, attacking MS-CHAPv2 is now as simple as cracking a single DES key.

It is nice the Microsoft is recognizing some of the advice of the security community and taking steps to phase out SHA-1 and RC4. But I have a hard time applauding Microsoft when this is just the tip of the iceberg of weak hashing functions and protocols in popular use in their software.

Re:If SHA-1 is a problem, what does that make MD4? (0)

Anonymous Coward | about a year ago | (#45409801)

But Microsoft us motivated to mandate this change. Because their current software supports the replacement algorithms but their older products and a large number of their competitors don't support them. This can lead to new sales. There's no competition for SAM.

Re:If SHA-1 is a problem, what does that make MD4? (1)

Anonymous Coward | about a year ago | (#45410669)

This is likely the main motivation on the Microsoft move. Customers have stopped upgrading the OS from clients and servers as MS has changed both of them to the new metro-ui. But this move may backfire them, as if a customer is threatened and pissed, he can nowadays move to competitors with the same amount of employee re-training as to new MS OS's.

Re:If SHA-1 is a problem, what does that make MD4? (2, Informative)

Anonymous Coward | about a year ago | (#45409831)

Funnier (or sadder) still, NTLM v2 is unsalted rc4.

Re:If SHA-1 is a problem, what does that make MD4? (0, Troll)

Anonymous Coward | about a year ago | (#45409887)

You sir, are an armchair quarterback. A backseat driver. An individual that has no fucking idea what he is talking about. Just because Microsoft allows the mentioned protocols to be used does not mean they are recommended. Read their best practices documentation. Perhaps you think that everyone that sets up a Windows server uses the crappy defaults rather than RTFM and making the system secure. You and all the other FUD assholes make MCSEs out to be Neanderthals. Just because they make an OS for the masses doesn't mean it cannot be easily tuned to function in a hostile environment. Do not blanket the entire system just because most are not wise enough to do their fucking job. Microsoft uses their simplicity to increase sales and it works. That does not mean they do not provide the tools to make the OS actually work. You mention PPTP. Why? PPTP is not recommended by Microsoft. Do they allow it? Yes. Can you blame them? Sure. You blame them for everything even when they alert the entire fucking community not to use it, just like TFS. Sorry, I just finished a Tripwire setup and it is a PITA.

Re:If SHA-1 is a problem, what does that make MD4? (0)

Anonymous Coward | about a year ago | (#45411221)

Moron. It's easy to recommend something for others and not do it yourself. Even in Windows 8 MS ships an FTP client and no SCP.

Re:If SHA-1 is a problem, what does that make MD4? (3, Interesting)

WaffleMonster (969671) | about a year ago | (#45410225)

Microsoft continues to make use of MD4 for password hashing in the Security Account Management part of the registry.

Playing devils advocate no password hash is really secure even if you check salt, algorithm and amplification boxes unless password itself is unrealistically good. Sure all of those things help *ALOT* except still not good enough I still wouldn't trust it to protect my user database. Operating under a secure syskey mode is prudent.

MS-CHAPv2 also continues to be part of Microsoft's offering as well. Support for this is included in their OS for PPTP, iSCSI and 802.1x (and possibly others). As pointed out in the article, attacking MS-CHAPv2 is now as simple as cracking a single DES key.

Still waiting for WP8 wireless to even warn the user before completely failing to validate TLS certificates. Bad enough when a vendor makes a mistake when designing a protocol... When implementing something they KNOW to be totally insecure by *design* .. now that represents a whole new realm of incompetence.

It is nice the Microsoft is recognizing some of the advice of the security community and taking steps to phase out SHA-1 and RC4. But I have a hard time applauding Microsoft when this is just the tip of the iceberg of weak hashing functions and protocols in popular use in their software.

This is only because it is in Microsoft's best interests their signatures not be hacked as it would among other things doom the trusted platform. They don't seem to have the same level of concern about our passwords being compromised.

Worth noting even with known attacks SHA-1 is still plenty secure for signatures... For all we know SHA-1 may never see a serious exploit but SHA-2 could be broken tomorrow. (Devil you know vs the one you don't) SHA-1 at least has had some exposure to the real world for a number of years.. SHA-2 currently very little.

I think the guys who designed original TLS PRF conceptually had the solution about right XORing multiple hash algorithms such that if one fails the underlying thing is not totally doomed. Virtually impossible to quickly resign global trust hierarchy even less feasible to resign code to react to a serious breach.

Re:If SHA-1 is a problem, what does that make MD4? (0)

Anonymous Coward | about a year ago | (#45411307)

I googled hash salt and it said I should use 1 tsp. Now what?

SHA-2 (1)

DrYak (748999) | about a year ago | (#45411973)

SHA-2, more specifically its SHA256 ^2 variant, is not only used to secure messages in HMAC, but also in bitcoin for validating blocks (adding pages into the common distributed ledger), and thus also in bitcoin mining.

Given the current massive craze in bitcoin, there's been massive development around SAH256.
If SHA256 was cracked, somebody would be laughing on the way to the bank, after having mined most of the coin.
That didn't happen (current bitcoin production is still spread among the most popular mining pools, there's no single individual significantly faster than everybody else)
that's a good sign that SHA-2 won't be cracked in the near future despite how much resources the NSA, FSB and Co put at it.

Re:If SHA-1 is a problem, what does that make MD4? (1)

swillden (191260) | about a year ago | (#45412683)

Playing devils advocate no password hash is really secure even if you check salt, algorithm and amplification boxes unless password itself is unrealistically good.

Passwords have a variety of problems but being subject to brute force attacks needn't be one of them. Their security (or lack thereof) relies on exploiting the asymmetry of effort required to verify vs crack, and reasonable passwords have on the order of 30 bits of entropy. That does require that the password be fairly good, but not "unrealistically good". The key is to calibrate the computation required to verify the password so that searching is infeasible. For example, if it takes 1/10th of a CPU-second to verify the password, then it will take ~3 CPU years to search the password space. If that's not enough for your application, slow the password-verification algorithm down so it takes a second, or whatever other value is appropriate.

There are several key derivation functions (e.g. PBDKF2, bcrypt, scrypt) which allow the run-time cost of the algorithm to be adjusted as needed.

The biggest problem with passwords is password reuse. You can't realistically expect people to manage tens, much less hundreds, of reasonably good passwords. Honestly, two or three is about the limit. And all it takes is for one system to do a bad job with password hashing and storage, and then lots of accounts on lots of systems are compromised/

I think the guys who designed original TLS PRF conceptually had the solution about right XORing multiple hash algorithms such that if one fails the underlying thing is not totally doomed.

Either multiple algorithms, or a structure that allows new algorithms to be swapped in quickly, or both. One thing working in our favor is that there is usually plenty of warning before someone finds a practical collision generation algorithm. And even MD5 still doesn't have any second pre-image attacks. Arguably, MD5 is just fine for signatures even today, as long as the rest of the protocol is designed to limit the value of random collision pairs.

Re:If SHA-1 is a problem, what does that make MD4? (0)

Anonymous Coward | about a year ago | (#45413003)

Playing devils advocate no password hash is really secure even if you check salt, algorithm and amplification boxes unless password itself is unrealistically good. Sure all of those things help *ALOT* except still not good enough I still wouldn't trust it to protect my user database. Operating under a secure syskey mode is prudent.

Password strength / complexity is a user training issue combined with making sure that your system enforces the use of complex passwords when they are being set.

Don't confuse that issue with salting and hashing of passwords, which protects you against other attack vectors such as rainbow tables. Hashing + salting ensures that a break of one password does not automatically expose all of the other passwords.

Re:If SHA-1 is a problem, what does that make MD4? (1)

ruir (2709173) | about a year ago | (#45410297)

Some protocols maybe be weak, but for instance, you are not supposed to use MS-CHAPv2 on the clear, it is usually encrypted inside a PEAP or TTLS tunnel, which is the standard configuration, for instance for the worldwide academic confederation, EDUROAM.

Re:If SHA-1 is a problem, what does that make MD4? (0)

Anonymous Coward | about a year ago | (#45418267)

MS-CHAPv2 also continues to be part of Microsoft's offering as well.

yeah, the 13-year-old protocol has a vulnerability. that's why it's not enabled by default.

...popular use in their software

popular when? 2001?

people won't upgrade. (0)

Anonymous Coward | about a year ago | (#45409717)

It is quite obvious that people are lazy, and will not upgrade no matter what Microsoft says. We need a transparent solution that works in situ without any software upgrades, and so low-key that no one will even suspect the message is encrypted!

I am talking, of course, of Double ROT-13.

*sigh* ok then... (1)

Narcocide (102829) | about a year ago | (#45409723)

... what do we replace all our database password hash columns with now?

Re:*sigh* ok then... (0)

Anonymous Coward | about a year ago | (#45410019)

SHA2-512 variant, obviously.

Re:*sigh* ok then... (0)

Anonymous Coward | about a year ago | (#45414411)

Password hash using SHA2-512 with 32byte salt. Seems like overkill, but CPU is not the bottleneck, the 10gb connection is.

Re:*sigh* ok then... (2)

DavidD_CA (750156) | about a year ago | (#45410033)

Asterisks.

Re:*sigh* ok then... (0)

Anonymous Coward | about a year ago | (#45410047)

Leave those as is and issue password change advisories. Going forward use something like scrypt, bcrypt, sha2, sha3 ...

Re: *sigh* ok then... (0)

Anonymous Coward | about a year ago | (#45410209)

Do we have any doubts on whether SHA3 is similarly bugged, having been developed under the possible skewed guidance of the NIST competition?

Re:*sigh* ok then... (1)

Anonymous Coward | about a year ago | (#45410913)

Well, one possible solution would be to calculate a "double hash" where the first hashing is done with the old algorithm, and the hash produced by that is then hashed with the new algorithm. It should provide the same security as only using the new algorithm, but allows you to convert all the hashes from the old algorithm which you already have to the corresponding new hashes without the need to have the passwords.

So for example if you used MD5 hashes before, and want the security of SHA-256, you use sha256(md5(password)) as hash. Since you already have md5(password) for each password on your system, you can easily replace it with the sha256 of that value.

Note that this is specifically for passwords; for use in digital signatures the double hash would of course not be more secure than the weaker of the two algorithms.

Re:*sigh* ok then... (1)

Anonymous Coward | about a year ago | (#45411579)

Curious: why doesn't the higher strength transfer to signatures as well?

Re:*sigh* ok then... (1)

Anonymous Coward | about a year ago | (#45414499)

Because with digital signatures the attack is to generate a second text which causes the same hash value. Of course given the plain text, you certainly can generate its weak hash (so the fact that the weak hash is strong-hashed afterwards doesn't prevent you from getting the weak hash value), and if you manage to create a second, malicious text which creates the same weak hash value, then of course re-hashing that value with a strong hash doesn't help: Hashing the same value gives the same result.

The situation is different for the passwords because you obviously don't have the original text for the hash (that is, the password; if you already had that, you'd not be interested in the hash anyway). Therefore you cannot get at the hash value of the weak hash, because all you have is the weak hash's strong hash, and that one you cannot reverse.

Basically, to break the double-hashed password, you need to break both hash functions, therefore the combined hash is as secure as the stronger one. However to break the double-hashed signature, you need to break only one hash, therefore the security is the one of the weaker hash.

Of course with the signature you could, instead of chaining the two hashes, calculate both hashes in parallel. To break that you'd again have to break both hash functions in order to break the signature (because if your replacement text only matches one of the hashes, the manipulation would still be detected using the other hash). Of course that would not be a good idea for the passwords, because then you'd be able to get a much shorter candidate list from breaking the weaker hash, which you'd then be able to test against the stronger hash to find the correct choice. Indeed, in case you've used the same password elsewhere, it would even be less secure than only the weak hash, because with the weak hash alone there would be no way to determine which of the strings leading to the same hash is the correct one.

mod 0P (-1, Offtopic)

Anonymous Coward | about a year ago | (#45409821)

Consider that right percent of the *BSD Be 'very poorly name on the jar of Propaganda and the future o7 the or make loud noises consider w#orthwhile

Re:mod 0P (0)

Anonymous Coward | about a year ago | (#45409855)

WTF did you just [try to] say?

Re:mod 0P (0)

Anonymous Coward | about a year ago | (#45411261)

Well, if he was trying to say...

Consider that right percent of the *BSD Be 'very poorly name on the jar of Propaganda and the future o7 the or make loud noises consider w#orthwhile

...he succeeded.

Re:mod 0P (0)

Anonymous Coward | about a year ago | (#45413301)

There's been one of these attached to a number of articles lately. This one didn't include the word "gay" for some reason though...

f^rost( pist (-1)

Anonymous Coward | about a year ago | (#45409959)

Tossers, 3ent out About half of the has ground to a national gay niiger but many find it world. GNAA members can no longer be handy, you are free Satan's Dick And 486/66 with 8

Re:f^rost( pist (2)

philip.paradis (2580427) | about a year ago | (#45410021)

There's trolling, and then there's trolling on drugs that only got invented last week. Damn dude, whatever that new stuff is, it's no good for you.

Why the long window? (2)

thatpythonguy (1726724) | about a year ago | (#45410365)

Plenty of time between now and January 2016 when MS will reject the use of SHA1. I understand that large corporations move slowly, but we have known about SHA1 shortcomings for a while now. I would like to read more about what products are affected, possible attacks in product contexts, and reasons for the long window until retirement! Even Windows 7 mainstream support will end in 2015!

SHA1? insecure? (3, Interesting)

Luke_22 (1296823) | about a year ago | (#45410687)

I can understand RC4.

I can understand MD5.

But SHA1? right now, according to wikipedia, a full collision attack requires something like $2.77M of computing power on the cloud...
maybe a less if you have you own supercomputer, but even at $1M it sound a lot...

So why warn away from SHA1 NOW? what are we going to use? md5? md4? remember that while keccak was chosen as the SHA3, they still have to release the complete details on how it must be implemented -- number of rounds and such -- so SHA3 *NOW* is not an option.

I'll start taking microsoft seriously on this once they phase out MD4, RC4, MD5 from their existing standards and products.

Re:SHA1? insecure? (4, Insightful)

Shimbo (100005) | about a year ago | (#45410731)

So why warn away from SHA1 NOW?

If developers are using it today, then you will be next year, and the year after, when attack are more feasible.

what are we going to use?

I'm not a cryptography expert but if SHA-1 is too weak, and SHA-3 not quite there yet, why not SHA-2?

Re:SHA1? insecure? (4, Informative)

Anonymous Coward | about a year ago | (#45410853)

Specifically the 2nd SHA family are usually called SHA-224, SHA-256, SHA-384, and SHA-512

Re:SHA1? insecure? (0)

Anonymous Coward | about a year ago | (#45414709)

> I'm not a cryptography expert but if SHA-1 is too weak, and SHA-3 not quite there yet, why not SHA-2?

whoa - pretty deep number theory there bro!!

Re:SHA1? insecure? (1)

bill_mcgonigle (4333) | about a year ago | (#45411455)

remember that while keccak was chosen as the SHA3

and there's still a fight brewing over keccak rounds - NIST wants the rounds reduced to improve performance, at the same time we know that NSA has been weakening public crypto to hurt security. This may not be the case with keccak but the implications are strong enough and stock keccak good enough, that keccak, as submitted, should become SHA-3, not the reduced round version.

If that doesn't happen, we may just ignore NIST and do a community standard based on published keccak. NIST should take heed to not become irrelevant.

Re:SHA1? insecure? (1)

swillden (191260) | about a year ago | (#45412759)

I can understand RC4.

I can understand MD5.

But SHA1? right now, according to wikipedia, a full collision attack requires something like $2.77M of computing power on the cloud... maybe a less if you have you own supercomputer, but even at $1M it sound a lot...

So why warn away from SHA1 NOW? what are we going to use? md5? md4?

Because SHA1 has known weaknesses, even if they're not practically exploitable, and because attacks always get better. Would it shock you to hear tomorrow about a new attack on SHA1 that allows collisions to be generated for a few hundred dollars of computation? It wouldn't shock me. I don't expect it, but it would not be surprising.

The alternative to SHA1 right now is SHA2. Or if you want you can use Keccak as published, but you may have to change it when the final standard is released. Depending on the context that may be reasonable.

Microsoft is just repeating here what the security community has been saying for a few years now: SHA1 is okay, but new systems should be designed with SHA2, and old systems should be prepared to move if SHA1's weaknesses get much worse. As soon as SHA3 is standardized (or the community decides to pick an alternative as a standard, as bill_mcgonigle suggests), then new systems should use that.

I'll start taking microsoft seriously on this once they phase out MD4, RC4, MD5 from their existing standards and products.

Well, yes, there is that.

I should also mention that RC4 is in much the same boat as SHA1. As long as you discard enough of the initial keystream bytes, it's fine for use today and for the foreseeable future. But the cracks in its shell mean that new systems should use something better. AES is the obvious, and perfectly adequate, solution. In counter mode if you need a stream cipher.

Re:SHA1? insecure? (0)

Anonymous Coward | about a year ago | (#45417899)

I don't expect it, but it would not be surprising.

If you don't expect it, then 'surprising' is exactly what it is :)

Re:SHA1? insecure? (1)

pla (258480) | about a year ago | (#45414405)

But SHA1? right now, according to wikipedia, a full collision attack requires something like $2.77M of computing power on the cloud...

Let's say Merck has a new drug in phase 3 clinical trials, it seems to cure cancer and the common cold. They plan to publish the results of the trials tomorrow, and everyone expects great success

If you can crack RC4, you can MitM the private session between Lead Researcher Fred and the board. Whoah, this miracle drug works as advertised, except it causes permanent impotence.

Time to short Merck, and go all-in on Pfizer, and a few million up front amounts to chump-change compared to what you'll make tomorrow when the news breaks.

Re:SHA1? insecure? (1)

pla (258480) | about a year ago | (#45414429)

And even after preview, I still said RC4. Duh. SHA1. :I

Re:SHA1? insecure? (0)

Anonymous Coward | about a year ago | (#45415033)

Maybe Microsoft knows something that isn't public yet.

What about Git? (2)

markkezner (1209776) | about a year ago | (#45412197)

Git is a great system, but it relies on SHA1. If SHA1 has feasible attacks, is git going to stay on SHA1 or will it move to something more secure? Can it even do so without breaking compatibility?

Re:What about Git? (2)

tobiasly (524456) | about a year ago | (#45412639)

Git is a great system, but it relies on SHA1. If SHA1 has feasible attacks, is git going to stay on SHA1 or will it move to something more secure? Can it even do so without breaking compatibility?

SHA1 as used in Git proves that a particular commit has the contents and the ancestors that the person with the repo says it does. It prevents two different people from saying, "this is what the source looked like at this point in time". So in practice, coming up with a collision attack in that scenario wouldn't be much use because whatever you come up with to generate the collision obviously isn't source code :)

That said, replacing it with something else would essentially involve rebasing the entire repo, which would certainly be inconvenient but not insurmountable. They could probably even have a backwards-compatibility mode where it recognizes both SHA1 and some other algorithm and clients could gradually switch to the next one.

Re:What about Git? (2)

benjymouse (756774) | about a year ago | (#45413441)

So in practice, coming up with a collision attack in that scenario wouldn't be much use because whatever you come up with to generate the collision obviously isn't source code :)

You fall into the trap of trying to find reasons for how it is *not* a problem. But *every* single time a weakness is found it opens up to multiple different attacks. Just because you cannot imagine a possible attack using a vulnerability does not mean that such attack vectors do not exist.

Case in point: During the total pwnage (rootkit installed and active for the better part of a month - possibly longer) of kernel.org and multiple other Linux Foundation sites back in 2010 (we still have not seen a post mortem on that, despite promises of openness), the SHA1 digests were quoted as the reason we should not worry of compromise. A weakness where an attacker could create something else with the same digest opens up the possibility for injecting malicious code into the repo.

Assuming that SHA1 weaknesses do not affect something like Git which relies on digests in almost every operation strikes me as naive. Of course Git will have
to move off SHA1 just like everyone else. No rush just now - but it would be stupid not to start planning for it.

Re:What about Git? (1)

tangent3 (449222) | about a year ago | (#45414491)

I call BS on that "*every*"

Re:What about Git? (0)

John Allsup (987) | about a year ago | (#45418501)

Git uses SHA-1 to hash the contents of a file, then uses that hash as in internal name.  I imagine it wouldn't be too difficult to modify git to use a different hash (one of the SHA-2 ones) and then create a new repo and check the files into that.  I don't know about transferring history to a repo hashed with a new hashing algorithm, but overall a shift to a different hash would be easy enough.

Re:What about Git? (1)

KiloByte (825081) | about 10 months ago | (#45442219)

Attacks against SHA1 are still purely theoretical: it would take several million dollars of hardware+electricity to produce a single collision. To subvert a git repository, you need to be able to have a commit of your own legitimately accepted, with no modifications (like Signed-off-by: by whoever took your patch, or modifications to the file you edit), and then, you need to pwn the server holding the public repository to replace that commit with the nefarious half of your collision.

That's a MASSIVE undertaking. On the other hand, you can learn the ways of Underhanded C and try to sneak the code in some driver... Thus, I trust the kernel git repo.

Even MD5 is perfectly secure against preimage attacks, barring any sudden breakthrough, for foreseable future.

Re:What about Git? (1)

lhunath (1280798) | about 10 months ago | (#45454817)

There's a difference between using SHA1 for verifying integrity and using SHA1 for cryptographic purposes.

I don't think it's GIT's intent to cryptographically prove that nobody has injected a modified commit in your history while going through extreme effort to mask that single-commit modification.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?