Deprecation of MD5 and SHA1 -- Just in Time? (threatpost.com)

mitcheli writes: If you're hanging on to the theory that collision attacks against SHA-1 and MD5 aren't yet practical, two researchers from INRIA, the French Institute for Research in Computer Science and Automation, have provided reason for urgency. They demonstrated a new series of transcript collision attacks centered on the SHA-1 and MD5 implementations in TLS 1.1, 1.2 and 1.3, along with IKEv1 and v2, and SSH 2. They say, "Our main conclusion is that the continued use of MD5 and SHA1 in mainstream cryptographic protocols significantly reduces their security and, in some cases, leads to practical attacks on key protocol mechanisms (PDF)." Of course, Mozilla officially began rejecting new SHA-1 certificates as of the first of the year. And as promised, there have been some usability issues. Mozilla said on Wednesday that various security scanners and antivirus products are keeping some users from reaching HTTPS websites.

Comments

You shouldn't use one hash.

[queazocotal]

hashmd5(data) is weak.
hashsha1(data) is weak.
hashsha1(hashmd5(data)) is strong, and unlikely to be attacked successfully unless your key data is too short.

Re:You shouldn't use one hash.

[cc1984_]

hashmd5(data) is weak.
hashsha1(data) is weak.
hashsha1(hashmd5(data)) is strong, and unlikely to be attacked successfully unless your key data is too short.

hashsha1(data) . hashmd5(data) could possibly be better, but what your suggesting sounds worse to me.

Re:You shouldn't use one hash.

[Anonymous Coward]

You shouldn't let amateurs design cryptographic systems either...

Re:You shouldn't use one hash.

[WhiteKnight07]

Actually concatenating hashes together doesn't do much for security at all. In fact it does almost nothing. See: http://link.springer.com/chapt...

Re:You shouldn't use one hash.

[Anonymous Coward]

hashsha1(hashmd5(data)) is strong, and unlikely to be attacked successfully unless your key data is too short.

This is not widely believed by crypto-security folks to be more secure.

See e.g. https://crypto.stanford.edu/~xb/crypto06b/blackboxhash.pdf ---

We studied the problem of combining multiple hash functions into a single function
that is collision resistant whenever at least one of the original functions is.
The hope was that, given a number of plausibly secure hash constructions (e.g.,
SHA-512 and Whirlpool), one might be able to hedge one’s bet and build a new
function that is at least as secure as the strongest of them. The combination
should be space efficient in that the final output should be smaller than the
concatenation of all hashes.

We showed that no such efficient black-box combination is possible assuming each hash function is evaluated once

Re:You shouldn't use one hash.

[Anonymous Coward]

hashsha1(data) . hashmd5(data) could possibly be better, but what your suggesting sounds worse to me.

Sounds pretty dumb.

Then I'll just split the concatenated hash and find a hash collision in either one of em.

Re:You shouldn't use one hash.

[Anonymous Coward]

hashmd5(data) is weak.
hashsha1(data) is weak.
hashsha1(hashmd5(data)) is strong, and unlikely to be attacked successfully unless your key data is too short.

<YODA>The fail is strong in this one.</YODA>

Umm, no.

Re:You shouldn't use one hash.

[Anonymous Coward]

RTFA. It talks specifically about this. And it says you are wrong.

Re:You shouldn't use one hash.

[Anonymous Coward]

salt = newuuid();
final = salt + hashsha1(data + salt);

For storing hashes of data, this is a no-brainer. It also makes the second hash function unnecessary, providing a small, but measurable, performance boost.

Re:You shouldn't use one hash.

[castionsosa]

If I had to deal with "n" hash algorithms, I'd probably just do the easy way -- take, store, and sign with each hashing algorithm. Of course, this does add computation steps, not to mention more space for hashes to be stored. However, if one wants parallel chain links for top security, this is the surest bet.

If I wanted to guess and assume I'd have -some- protection, I'd store the size of the file, and the hashes XOR-ed together. However, like the parent poster stated, there isn't a function that guarantees that combined hashes will be as strong as the strongest hash... but it would be stronger than a single, broken hash algorithm.

Re:You shouldn't use one hash.

[queazocotal]

I have not fully read the above paper, but the initial summary seemed to be investigating the results of 'compressing' the concatenated results of the two hashes of the data, without investigating the properties of hashing the result of one algorithm hashing the others hash of the data.

Re:You shouldn't use one hash.

[Anonymous Coward]

hashmd5(data) is weak.
hashsha1(data) is weak.
hashsha1(hashmd5(data)) is strong, and unlikely to be attacked successfully unless your key data is too short.

It is trivial to see that any weakness of hashmd5(data) will propagate to hashsha1(hashmd5(data)).
Cascading several hashes is equivalent to using the innermost.
Best case is that you reduce the hash size in a way that is better than cropping.

Re:You shouldn't use one hash.

[cc1984_]

What would you do with the one hash collision if the other one doesn't match?

Re:You shouldn't use one hash.

[Anonymous Coward]

So what if you find a collision for one of them? Run it thru the other hash function and it's unlikely to be same as original. Sure, if your "collision" is actually the original data, then they will be same, but that's not a collision. Collision requires that two different inputs produce same result.

Re:You shouldn't use one hash.

[Anonymous Coward]

this is wrong and dangerous. you should feel ashamed for posting this.

Re:You shouldn't use one hash.

[Bengie]

Even Better, although I used SHA512 myself.

salt = cryptorand.getbbytes(64);
final = salt +HMACSHA1(data,salt);

Re:You shouldn't use one hash.

[Anonymous Coward]

Seems like it's talking about concatenating hashes that are a result from same hash function with different data, not different hash functions with same data.

Re:You shouldn't use one hash.

[Orgasmatron]

If the first function is breakable, the whole chain is breakable because hashes are deterministic.

Always use input constraints. Most (all?) hash breaks involve the ability to shovel arbitrary garbage into the hash function. For example, if you want to forge an HTML document with the same MD5 as another HTML document, you embed your carefully crafted junk in a HTML comment, so that it isn't a visible part of the document. If your electronic policies disallow invisible HTML elements, and your human policies disallow gibberish, no one can forge that document, even with a weak hash function.

A real world example in widespread use today is Bitcoin, which uses weak-ish hashes in some places, but the valid inputs have so few constraints that exploiting them is impossible.

Re:You shouldn't use one hash.

[Anonymous Coward]

I hear this everywhere, but every explanation I've heard for why is hand wavy (like parent, no offense) or too long/technical and I walk away not understanding. Does anyone have a concise explanation why combining two hash functions (either nested or concatenated) is not helpful?

It's counter intuitive, I accept that it's probably true because experts say so, but I'd like to understand.

Re:You shouldn't use one hash.

[Anonymous Coward]

Try harder. hashsha1(gzip(data)) || hashmd5(data) where || is concatenate.

Re:You shouldn't use one hash.

[TeknoHog]

hashsha1(hashmd5(data)) is strong

A hash is a many-to-one function. If you combine many hashes this way, you'll map a huge range of different data onto the same output. To me this seems it would be easier to find collisions, not harder. For starters, the output of sha1 has a fixed length, which greatly limits the range of the final output.

Combining different hashes is a good idea, but one weak link in the chain will probably ruin it all. I'd rather combine the outputs of different hashes into one long string to keep them independent.

Re:You shouldn't use one hash.

[Anonymous Coward]

Let's assume you've found two documents that cause an MD5 collision.

Document 1's md5sum is = c4ca4238a0b923820dcc509a6f75849b (-- this is actually the md5sum for an ascii 1)

And Document 2's md5sum is also = c4ca4238a0b923820dcc509a6f75849b

Now lets see what happens when we hash the MD5sum with sha1....

You end up with 21681d94b42445e996b398400725be8aa0e8edb6 for both Document1 and Document2. So in short, you've inherited all of the weaknesses of the inner checksum and gained nothing from using the outer one(if anything you've defeated it)

Make sense?

Re:You shouldn't use one hash.

[Anonymous Coward]

Yes. Thanks, I now understand that the "nested hash" case

Hash1(Hash2(data))

This is no good because the input to the outer hash function Hash1 is the same anyway if you have a collision in the inner hash function Hash2.

What about the concatenated case?

Hash1(data) + Hash2(data)

Re:You shouldn't use one hash.

[Thanatiel]

That sounds like nonsense isn't it ?
SHA1(data) is a constant for a given "data"
MD5(data) is a (different) constant for a given "data"

SHA1(MD5(data)) is thus SHA1 of a constant which gives you exactly zilch in term of improvement of (in)security. At least it is not worse.

Trying to improve on a "broken" cryptography function by combining simply does not work, especially if the theory is not well understood.
For an example, applying two different cryptographic functions after each other on some data ( f(g(data)) ) could, in theory, give you back the original data.
It's always safer to simply use the next, theoreticians-approved, well-proven, algorithm.

Re:You shouldn't use one hash.

[Anonymous Coward]

What about the concatenated case?

Hash1(data) + Hash2(data)

The security here is going to be as strong as the strongest of the two hashes, but not stronger as far as collision resistance goes. As such, there isn't really much point in using the second hash.

For a bit deeper of a read: http://article.gmane.org/gmane...

In particular:

Joux then extended this argument to point out that attempts to increase
the security of hash functions by concatenating the outputs of two
independent functions don't actually increase their theoretical security.
For example, defining H(x) = SHA1(x) || RIPEMD160(x) still gives you only
about 160 bits of strength, not 320 as you might have hoped. The reason
is because you can find a 2^80 multicollision in SHA1 using only 80*2^80
work at most, by the previous paragraph. And among all of these 2^80
values you have a good chance that two of them will collide in RIPEMD160.
So that is the total work to find a collision in the construction.

Re:You shouldn't use one hash.

[WaffleMonster]

salt = newuuid();
final = salt + hashsha1(data + salt);

For storing hashes of data, this is a no-brainer. It also makes the second hash function unnecessary, providing a small, but measurable, performance boost.

Using salts is like publically apologizing for wrongdoing.

I've tried over the years to make people understand the simple truth only exponents can protect information. When you make something 1000 or 1000000 times harder this "sounds" like a worthwhile accomplishment but in reality it means very little especially if what you are protecting is worth anything to anyone.

If you feel you need to use salts to protect something you are doing that something a disservice by continuing with your current course of action.

Re:You shouldn't use one hash.

[WaffleMonster]

Even Better, although I used SHA512 myself.

  salt = cryptorand.getbbytes(64);
  final = salt +HMACSHA1(data,salt);

What good is the HMAC in this case?

Re:You shouldn't use one hash.

[WaffleMonster]

hashmd5(data) is weak.
hashsha1(data) is weak.
hashsha1(hashmd5(data)) is strong, and unlikely to be attacked successfully unless your key data is too short.

While this construction is wrong I never understood what the problem is with the general approach. The PRF in TLS is derived this way except they are not stacked but rather XOR'd together.

All justifications for not doing away with this I've ever read had been political rather than technical statements. This approach is not approved, untested, uncertain.. etc.

Assuming a sufficiently large block size what is the problem with a crapload of hash algorithms? Obviously defective algorithms pull down effective block size but if you have the margins what prevents this from being an effective insurance strategy? Especially if it is only used for key management/handshake and performance implications of duplicative work are nonexistent. Why not do it?

Re:You shouldn't use one hash.

[cc1984_]

Very interesting article. However, it seems to be saying that a concatenation of an X bit hash and a Y bit hash are no better than a third hash of length X+Y bits. My original comment was in respect that md5 . sha1 would be better than md5 or sha1 alone, but even then I'm no crypto expert so I'm prepared to be proved wrong on that.

Re:You shouldn't use one hash.

[Threni]

"If you combine many hashes this way, you'll map a huge range of different data onto the same output....Combining different hashes is a good idea, but one weak link in the chain will probably ruin it all."

OP's not suggesting you combine an arbitrary number of arbitrary hash algorithms though, but specifically those two, once each.

Re:You shouldn't use one hash.

[kiwix]

If the issue is with collisions (which is the case in this attack), then you just have to break the innermost hash function. When hashmd5(data1) == hashmd5(data2), you also have hashsha1(hashmd5(data1)) == hashsha1(hashmd5(data2)).

Re:You shouldn't use one hash.

[Anonymous Coward]

This is the proof to the classic comment that if you believe you know enough to design your own crypto scheme, without a crypto background, you are a complete idiot.

As others have said, this is idiotic.

Re:You shouldn't use one hash.

[Pseudonym]

Using salts is like publically apologizing for wrongdoing.

The main purpose of salting a hash is to protect against chosen plaintext attacks.

Re:You shouldn't use one hash.

[Pseudonym]

I know you were joking, but in case anyone was actually planning to try this: gzip isn't a monomorphism.

Re:You shouldn't use one hash.

[Pseudonym]

Aargh! Sorry, I meant gzip isn't a function. The same input may have many different gzipped representations.

Re:You shouldn't use one hash.

[Pseudonym]

hashsha1(hashmd5(data)) is strong, and unlikely to be attacked successfully unless your key data is too short.

If hashmd5(text1) == hashmd5(text2), then hashsha1(hashmd5(text1)) == hashsha1(hashmd5(text2)).

Re:You shouldn't use one hash.

[arglebargle_xiv]

hashsha1(data) . hashmd5(data) could possibly be better, but what your suggesting sounds worse to me.

That's exactly what SSLv3 did. The TLS folks then decided they could drop the dual hash because, you know, SHA-1 is so good that we don't need the extra safety level. It's one of the rare cases when the crypto in protocol version n+1 is actually weaker than in version n.

Re:You shouldn't use one hash.

[arglebargle_xiv]

You seem to have missed the bit that says:

We also discuss the potential impact of our attack on several published schemes. Quite surprisingly, for subtle reasons, the schemes we study happen to be immune to our attack.

In other words the paper says "Here is a devastating attack in paired hash functions that happens not to work on real-world uses of paired hash functions". In fact RIPEMD-160, the longest-lived unbroken hash function, gets its security precisely from being a cascaded hash (and is be immune to the attack described in the paper).

Catch 22

[Geoffrey.landis]

Wow, looks like Firefox has some real problems.
From the link quoted: https://blog.mozilla.org/secur...

How to tell if you’re affected
If you can access this article in Firefox, you’re fine.

So, if you Firefox is affected, they won't tell you about it. They'll only tell you if your Firefox is not affected.

Later, same blog post:

What to do if you’re affected
The easiest thing to do is to install the newest version of Firefox. You will need to do this manually, using an unaffected copy of Firefox or a different browser, since we only provide Firefox updates over HTTPS.

So, if your Firefox is affected, you can't upgrade it: you need to have the working version of Firefox to download a working version of Firefox.

What a Catch 22! You can't know about the problem unless you already have fixed the problem, and you can't fix the problem... unless you have already fixed the problem.

Re:Catch 22

[Anonymous Coward]

People will notice, they will not be able to use their bank for example, they probably try reinstalling Firefox, or the worse for Mozilla, install Chrome

Re:Catch 22

[Anonymous Coward]

From https://archive.mozilla.org/pub/firefox/releases/latest/README.txt:

This could be pasted into the location bar of a browser, or used with curl or wget, e.g.
wget -O FirefoxSetup.exe "https://download.mozilla.org/?product=firefox-latest&os=win&lang=en-US"

Re:Catch 22

[Anonymous Coward]

You can't know about the problem

you live in some alternative universe where firefox is the only browser?

Re:Catch 22

[Anonymous Coward]

He lives in a universe where the Internet is only the World Wide Web, that's for sure.

Re:Catch 22

[Geoffrey.landis]

People will notice, they will not be able to use their bank for example, they probably try reinstalling Firefox,

But, per the article, they can't upgrade to the more recent Firefox if what they have is the old version of Firefox.

or the worse for Mozilla, install Chrome

Exactly! When the fix for the problem is "use somebody else's product", I'd call this a real problem for Firefox. Wait, isn't that what I just said?

Wow, looks like Firefox has some real problems.

TLS 1.3 must be pretty insecure

[Anonymous Coward]

TLS 1.1, 1.3 and 1.3

So, clearly we should keep using 1.2. After all, 1.3 is doubly vulnerable.

MD5?

[truck_soccer]

Is MD5 the original name of MC5, who is known for "kicking out the jams" ?

Re:MD5?

[Zero__Kelvin]

That's great. A Slahdot newbie making rap references. Be it noted that on this date you endeared yourself to Slashdotters everywhere!

It Depends on Why You Are Using Hash Codes

[DERoss]

For use in encryption or for verifying that a file is authentic, SHA1 and MD5 should definitely be avoided.

When transmitting a file over a LAN, WAN, or the Internet, however, SHA1 and MD5 are still useful to ensure that the file has not been corrupted (e.g., packets lost). Also, those two hashes can be used to determine if two files in the same system are the same.

Re:It Depends on Why You Are Using Hash Codes

[Anonymous Coward]

When transmitting a file over a LAN, WAN, or the Internet, however, SHA1 and MD5 are still useful to ensure that the file has not been corrupted (e.g., packets lost).

That's error checking though, not cryptography. They're not saying these hashes are useless, just not a good idea in security.

For use in encryption or for verifying that a file is authentic, SHA1 and MD5 should definitely be avoided.

... Also, those two hashes can be used to determine if two files in the same system are the same.

That kind of sounds like you contradicted yourself there. (Maybe some minor semantic difference)

Re:It Depends on Why You Are Using Hash Codes

[TheCarp]

Of course, everything depends on use case. Just being able to find collisions doesn't break all potential uses. It breaks specific use cases where the attacker has a known target and time to work.

It doesn't break use cases where the attacker has an unknown target and little time. It wouldn't break an authentication protocol based on a hash challenge response, since the attacker is asked to offer up his hash, which is checked.

Doesn't matter if he can generate arbitrary collisions then, because he has no target to collide with. If he had the password, he could answer the challenge before it expires.

Re:It Depends on Why You Are Using Hash Codes

[Anonymous Coward]

Someone earlier said "You shouldn't let amateurs design cryptographic systems".

You shouldn't let amateurs design transmission protocols either.
SHA1 and MD5 aren't ideal for transmission. There are simpler hashes that are better at dealing with the type of errors that you typically get from transmissions.
With the correct method you can even repair a couple of incorrectly transmitted bits without having to resend the file.

Re:It Depends on Why You Are Using Hash Codes

[castionsosa]

I'd use CRC-64 or CRC-128 over MD5 anyway, just because it is a lot fewer cycles to compute CRCs than to do the more advanced work needed for a cryptographically secure hash.

I would probably abandon MD5 and SHA1 altogether. If it doesn't need to be cryptographically secure, CRCs do the job. If it does need to be secure, I'd use SHA-3 with whatever length was needed for the job at hand. MD5 is "neither fish, nor fowl" and like MD4, just needs to be moved away from.

Re:It Depends on Why You Are Using Hash Codes

[Anonymous Coward]

I think he's trying to say that for data de-duplication purposes those hashes might still be useful.
You'll probably want to do a bit-wise compare to be sure.

Re:It Depends on Why You Are Using Hash Codes

[castionsosa]

Would it be better to use a large CRC as opposed to a cryptographically secure hash for deduplication work? CRCs are a lot easier to compute.

Re:It Depends on Why You Are Using Hash Codes

[Anonymous Coward]

No, you use a secure system (e.g. TLS with a proper cipher suite) to get the file and verify its authenticity. That is completely different from using hashes for error checking.

Re:It Depends on Why You Are Using Hash Codes

[Bengie]

Unless you have a cryptographically strong hash, you have to compare the data. CRCs are meant only to let you know if data has been corrupted, not if the data is the uniquely different than other data. CRC may be faster than SHA2-256, but it is much slower than having to read and compare a bunch of data.

Re:It Depends on Why You Are Using Hash Codes

[fahrbot-bot]

Someone earlier said "You shouldn't let amateurs design cryptographic systems".

You shouldn't let amateurs design transmission protocols either.

You shouldn't let amateurs do most things - including porn.

Re:It Depends on Why You Are Using Hash Codes

[Anonymous Coward]

You'll probably want to do a bit-wise compare to be sure.

No, I really won't, because the direct comparison check would increase the probability of error. With a hash that big, the probability of an accidental hash collision is lower than the probability of a transient hardware error cropping up during the comparison.

Now, if I were doing a smaller and more efficient hash, I might need the compare.

Re:It Depends on Why You Are Using Hash Codes

[Anonymous Coward]

Why would it be bad for file authentication? I truly don't understand this.

Re:It Depends on Why You Are Using Hash Codes

[GuB-42]

MD5 is vulnerable to full collision attacks
SHA-1 is vulnerable to freestart collision attacks
None of them are vulnerable to preimage attacks

It means that SHA-1 is still safe in the vast majority of applications. Freestart collisions are almost useless in practice, they are only worrisome because they may lead the way to full collision attacks.
MD5 is safe for storing passwords or checking that a file has not been tampered with by a third party. For example, if you download a program, ask the developer (who you trust) or check his website for the expected MD5 and it matches, then you can be reasonably sure that what you got is authentic. However, because it is vulnerable to collision attacks, it is not suitable for digital signature applications.

Re:It Depends on Why You Are Using Hash Codes

[Martin Blank]

SHA-3 is extremely new, and while it's passed multiple reviews, it hasn't undergone the same scrutiny that SHA2 has undergone. Trusting SHA3 at this point may be somewhat naive, especially since even the best attacks against SHA2, which has undergone much more intensive review, don't reduce its strength very far.

Re:It Depends on Why You Are Using Hash Codes

[WhiteKnight07]

And TLS 1.0 and 1.1 both use md5(data).sha1(data) to sign the initial handshake. And since concatenating hashes provides no real additional security this lets an attacker muck around with the initial TLS exchange and perform a protocol downgrade attack by defeating TLS_FALLBACK_SCSV and/or also choose the symmetric cipher used in the TLS session. While its not a full plaintext recovery of the TLS session contents it is certainly not a good thing.

Re:It Depends on Why You Are Using Hash Codes

[Anonymous Coward]

I dunno, even the NSA currently only trust SHA-3 for hashes at this point. Makes me think they don't believe SHA-2 will last very long. Or maybe that is what they want us to think...

Re:It Depends on Why You Are Using Hash Codes

[fendragon]

Because a miscreant can create a collision, i.e. a different file with the same MD5 or SHA-1 hash, with accessible computing power.

Re:It Depends on Why You Are Using Hash Codes

[Anonymous Coward]

I disagree.

Two different issues

[kiwix]

The summary mixes two different issues... SHA-1 is being phased out for certificate signatures, but this is not what the SLOTH attack is about.
SLOTH is about the use of MD5 and SHA1 inside the TLS protocol, to sign or MAC the key-exchange messages.
(Disclaimer: I'm one of the authors of the paper)

Re:Two different issues

[Anonymous Coward]

If you don't mind me asking, will this affect those of us using an old version of FireFox, such as v10 ESR?

Honestly, I think I might be able to go up to v24 ESR before GUI changes create problems.

Still useful outside a cryptographic context?

[Crowd Computing]

So this is a problem concerning the use of weak hashes for cryptographic verification. But how "harmful" are hash collisions when all you're looking for are file transmission errors or bit rot? Do we need a stronger hash function when dealing with compressed archives? Has anybody succeeded in creating two valid zip archives with the same MD5 sum?

Re:Still useful outside a cryptographic context?

[castionsosa]

ZFS uses CRC-64 hashes to check for bit rot for performance reasons.

As for zip archives, maybe we need to move to a signature model where we use the hash and the file size. It is difficult to make two files with the same hash. It is a lot more difficult for them to be the same size.

Re:Still useful outside a cryptographic context?

[pr0fessor]

I don't develop cryptography and have only every used MD5 for file integrity checks. Although my brother was talking the other day about a compressed encryption algorithm that sounded amazingly difficult to implement on even the best modern hardware.

Re:Still useful outside a cryptographic context?

[Bengie]

ZFS uses either Fletcher4-256 or SHA-256. Fletcher is based on CRC-64.

Re:Still useful outside a cryptographic context?

[castionsosa]

There are many encryption and compression algorithms out there. I've seen some people try to combine the two. However, there is a vast distance between making something resistant to modern attacks. Older Mac programs did their own custom algorithms by using a random function with the seed coming from what the user typed in as a password, some other off-the-cuff algorithm, or just doing two rounds of DES for performance reasons.

Problem is that you don't want the bulk cipher as the weak link, when it is quite easy to use a known good one and focus on other things. If you feel you have something that can stand up to extended attacks by everyone in the world, feel free to use it as an optional cascade with it using a completely different key than AES or the well known one.

Re:Still useful outside a cryptographic context?

[pr0fessor]

That's the thing with encryption there is always things to weigh. Poor performance to make brute force attacks to costly vs the reward so long as a side vector isn't found to render it completely useless?

Someone using a unique, proprietary, and undisclosed system of encryption if crafted as well as any standard may actually fair better so long as they are not a huge public company.

Re:Still useful outside a cryptographic context?

[castionsosa]

That is the rub. If someone has a unique algorithm that is quite good, and is kept secret, it would add to the security, especially if the attacker didn't have any access to the endpoints for side channel attacks, so they only have ciphertext to go on. However, there are a lot of attacks that one has to deal with, and eventually the algorithm may be found to be weaker than expected. Skipjack comes to mind of how it was considerably weakened (but not completely broken) once it was declassified.

Re:Still useful outside a cryptographic context?

[Anonymous Coward]

That is one thing I liked about TrueCrypt, the source of randomness was to ask you to wiggle your mouse around for a couple minutes.

Re:Still useful outside a cryptographic context?

[castionsosa]

The old version of PGP (pre /dev/random) used to have something similar as well, where one typed in some keystrokes, and the timing was used to seed the RNG. I wish more programs had this as an option (KeePass does), mainly because it adds a decent source of randomness that is extremely hard to duplicate.

SHA1 and Secure Hashing of Data

[Anonymous Coward]

Posting this anonymously for obvious reasons. The company I'm working for is undergoing some transitions and we needed a way to uniquely identify users without showing their personal information to everyone. I designed a system that uses some personal information (SSN, DOB), concatenates it into a string (whose composition is known to only a select few), and encrypts it using SHA1. (I chose SHA1 because that's what SQL was able to produce... for some reason, I had no luck getting HASHBYTES to produce results with SHA2_256 or SHA2_512.) This hash would only be used on our network and, if some properly, wouldn't be seen by any users.

My question is this: Given this article and assuming that the hashes fell into the hands of someone who wanted to decrypt them, how long would it take to do so? Would it be hours? Months? Decades? Would having multiple hashes tell the would-be cracker anything about the structure of the decrypted string which might help shorten the decryption time? Or would they have to brute force each string until they got one decrypted?

We're early enough in the implementation of this that I could improve the security on this if need be, but obviously the longer the project goes on, the more entrenched this will be and the harder it'll be to replace. Thanks to anyone who has advice on this situation.

Re: SHA1 and Secure Hashing of Data

[Anonymous Coward]

It's not about decrypting passwords but about beeing able to create a new faked password that would match the hash that you have in the database (for a different password) so there is no implications for uses like yours.

Re:SHA1 and Secure Hashing of Data

[Anonymous Coward]

I would suggest using salt in your hash calculations as well. That way, they cannot use a rainbow table to quickly reverse any known hashes.

If you are having trouble getting SQL to generate the appropriate hash, use whatever the programming language you are using to calculate it, then plug the result into the field as normal text. Do not allow the limitations of SQL dictate your security.

Re:SHA1 and Secure Hashing of Data

[WaffleMonster]

The company I'm working for is undergoing some transitions and we needed a way to uniquely identify users without showing their personal information to everyone. I designed a system that uses some personal information (SSN, DOB), concatenates it into a string (whose composition is known to only a select few), and encrypts it using SHA1.

Your problem is not preimage resistance of SHA1 but the piss poor entropy of SSN + DOB.

If you want to do something like this at least use HMAC-SHA1 and try to keep the secret from falling into the wrong hands.

My question is this: Given this article and assuming that the hashes fell into the hands of someone who wanted to decrypt them, how long would it take to do so? Would it be hours? Months? Decades? Would having multiple hashes tell the would-be cracker anything about the structure of the decrypted string which might help shorten the decryption time? Or would they have to brute force each string until they got one decrypted?

None of this is relevant when the hashed data contains no meaningful entropy in the first place.

Re:SHA1 and Secure Hashing of Data

[Anonymous Coward]

I'm not using SSN + DOB as my original string. I'm breaking up the values and rearranging them along with some text that's the same across all entries but wouldn't be known to a random person. There are only a handful of people with access to the exact formula for making the string that is used in the hashes. To everyone else, the hash strings would either be nonexistent (the application would hide them) or a string of gibberish.

I am, however, looking to shift to using SHA2 512. SQL might not be able to generate the strings, but I can generate them using PHP (or some other programming language) and have the values inserted into the database. This way, I'll be working with something that's more secure from the start of the project instead of trying to modify it later on.

Re:SHA1 and Secure Hashing of Data

[Anonymous Coward]

Thanks. I'm going to do just this to improve the security. I'm also not just doing SSN+DOB => Hash, but something more along the lines of:

'some string'+YYYY+'another string'+SSN+MM+'third string'+DD => Hash

(Obviously not the real format I'm using.)

I figured this way the would-be cracker not only has to guess the SSN and DOB to see if they match the hash, but also has to figure out what strings I used and how the data is all arranged. This would be a much harder task than simply guessing a 17 digit number.

Re:SHA1 and Secure Hashing of Data

[WhiteKnight07]

The fact that you say you are "encrypting" something with SHA1 tells me that you are not qualified to work on any product that uses encryption. If you must do something like this at least use bcrypt or pbkdf2. SHA1 and SHA2 are both not the best choice for what you are doing.

Re:SHA1 and Secure Hashing of Data

[Anonymous Coward]

I'd definitely toss a nonce in. When in doubt, if you want to uniquely identify something, you use a fast timer that stores the year, month, date, hour, minute, second, and a good fraction of a second, then couple that with a random number from /dev/urandom. Toss that through SHA-256, and for all intents and purposes, you have a unique key. If you want 100% certainty of a unique key, encrypt the date+random string wit, and use the first 256 bits for the ID. You would have to secure the encryption key, though...

Re:SHA1 and Secure Hashing of Data

[Zero__Kelvin]

"(Obviously not the real format I'm using.)"

You are going to great lengths to subvert the security process by falsely clinging to a security through obscurity paradigm. If your system is secure you can post all of the details of said system and it will be no less secure. Relying on keeping details of the implementation private is Security through/by Obscurity, and only serves to limit the ability of the auditor to thoroughly and properly evaluate your scheme. No competent security professional believes that Security by/through Obscurity works.

Get this:

[Anonymous Coward]

Linux crypto hackers open-sourced the BSD Microsoft monopoly!

How about using two hashes of different families?

[Anonymous Coward]

I asked one of our vendors about this a while back. I wanted the option to use 1 "super secure" hash and another "maybe less secure but really fast" hash (which must be ones that are as mathematically different from each other as possible.) This way you would make collisions harder with minimal overhead.