BLAKE2 Claims Faster Hashing Than SHA-3, SHA-2 and MD5

← Back to Stories (view on slashdot.org)

BLAKE2 Claims Faster Hashing Than SHA-3, SHA-2 and MD5

Posted by timothy on Tuesday December 25, 2012 @06:18AM from the loose-ends-may-appear-under-the-microscope dept.

hypnosec writes "BLAKE2 has been recently announced as a new alternative to the existing cryptographic hash algorithms MD5 and SHA-2/3. With applicability in cloud storage, software distribution, host-based intrusion detection, digital forensics and revision control tools, BLAKE2 performs a lot faster than the MD5 algorithm on Intel 32- and 64-bit systems. The developers of BLAKE2 insist that even though the algorithm is faster, there are no loose ends when it comes to security. BLAKE2 is an optimized version of the then SHA-3 finalist BLAKE."

134 comments

Min score:

Reason:

Sort:

ORAC by MickyTheIdiot · 2012-12-25 06:24 · Score: 4, Funny

He was always good with codes...
1. Re:ORAC by Nyder · 2012-12-25 06:58 · Score: 1
  
  He was always good with codes...
  woot!
  
  --
  Be seeing you...
I don't trust new, untried crypto. by SuricouRaven · 2012-12-25 06:24 · Score: 5, Funny

Give it, oh, five more versions.
1. Re:I don't trust new, untried crypto. by davester666 · 2012-12-25 07:17 · Score: 1
  
  So, you want to wait until the version string the tool reports is at least 1.0.5?
  Done!
  
  --
  Sleep your way to a whiter smile...date a dentist!
2. Re:I don't trust new, untried crypto. by Anonymous Coward · 2012-12-25 08:34 · Score: 2, Interesting
  
  He's waiting for Blake's 7.
  http://en.wikipedia.org/wiki/Blake%27s_7
3. Re:I don't trust new, untried crypto. by Anonymous Coward · 2012-12-25 11:47 · Score: 0
  
  By then, it will probably be SHA-8.
links to NIST by girlinatrainingbra · 2012-12-25 06:26 · Score: 5, Interesting

The BLAKE hash function was an also-ran finalist for the NIST Hash function competition ( http://en.wikipedia.org/wiki/NIST_hash_function_competition ). There is not yet a wikipedia page for BLAKE2, but the winner of the NIST competition was Keccak now known simply as SHA-3 since it won the competition.
.
Why would an optimized (optimized for run time speed? optimized for low memory footprint while running? optimized to minimize the likeliness of hash collisions) version of the same BLAKE entrant be more useful? Perhaps an improved algorithm that made it better competition for Keccak would make more sense. I don't know enough math to say completely, and still need to read the details.
1. Re:links to NIST by Nexion · 2012-12-25 06:37 · Score: 2, Insightful
  
  Yeah... I was under the impression that more hashes faster was a bad thing. That is something for which crackers tune their code, but they didn't explicitly mention password storage. Perhaps it is targeted more for checksum like usage.
2. Re:links to NIST by nazsco · 2012-12-25 06:47 · Score: 1, Informative
  
  Time to encode is not always related to time to decode. So it would benefit dictionary attacks only,
3. Re:links to NIST by Anonymous Coward · 2012-12-25 06:55 · Score: 1
  
  If you can decode a hash, your hash is very very broken.
4. Re:links to NIST by Anonymous Coward · 2012-12-25 06:57 · Score: 2, Informative
  
  There is no "decode" - breaking hashes is done by brute force (or by using dictionaries + modifiers).
5. Re:links to NIST by Zero__Kelvin · 2012-12-25 06:57 · Score: 2, Funny
  
  Yes. I hate optimized versions of things. Why does everyone think it's better just because they made it better?
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
6. Re:links to NIST by Anonymous Coward · 2012-12-25 07:01 · Score: 5, Informative
  
  It is optimized for runtime speed, though they also claim a slightly lower memory footprint.
  The chance of hash collisions is about the same for any unbroken cryptographic hash.
  Keccak has good performance in dedicated hardware, but was one of the slower SHA-3 candidates in software implementations. Compared to MD5, the best SHA-3 implementation is between 2 to 4 times slower on recent Intel processors, or 5 times slower on a recent ARM CPU.
  Note that NIST has stated that any of the five SHA-3 finalists would have been an acceptable SHA-3. Keccak was selected in part due to having a very different composition than the SHA-2 family, decreasing the risk that both are broken at once. That does not mean Keccak is superior to Blake for all purposes - if software speed is the main issue, it is almost certainly worse.
7. Re:links to NIST by Anonymous Coward · 2012-12-25 07:08 · Score: 1
  
  >> Time to encode is not always related to time to decode.
  What do you mean with "decode" ?
  >> they didn't explicitly mention password storage
  a very fast hash is bad for password storage. Password storage needs very slow hashes. generic hashing of a lot of data needs fast hashes.
8. Re:links to NIST by Johann+Lau · 2012-12-25 07:13 · Score: 1
  
  That also means you can hash more often in the same time, it cancels out. I'm not a crypto expert or even non-doofus, but basically you keep inreasing the number of iterations as processing power increases, e.g. calibrate it to take at least N seconds once a year. Which has nothing to do with the algorithm used really; I just like to throw dangerous half-knowledge out there to see what happens haha.
9. Re:links to NIST by marcansoft · 2012-12-25 07:25 · Score: 5, Informative
  
  For password hashing, that is correct. However, cryptographic hash functions are not designed for such use (and yes, all the websites and services out there using plain hashes for passwords are Doing It Wrong, even if they are using a salt). You can build a good password hashing scheme out of a cryptographic hash function (for example, PBKDF2), but plain hash functions are not suitable (precisely because they are too fast).
  Fast cryptographically secure hash functions are a Good Thing, so you can hash a given block of data (and thus compute its digest and e.g. verify its digital signature) as fast as possible. This speeds up things like GPG, SSL, Git*, good old sha1sum checksums, etc. If you then want to use such a hash function as the core of a password hashing scheme, you can compensate for the extra speed by simply increasing the number of iterations. Making a hash function slower is always easy.
  *Git is pretty much stuck with SHA-1 for now, but future incompatible versions of the repo format could conceivably switch to a faster hash function if it made sense.
10. Re:links to NIST by diamondmagic · 2012-12-25 07:25 · Score: 1
  
  Don't confuse a hash with a key derivation function. A hash is just a cryptographic primitive, you shouldn't use it directly (like you don't use block ciphers directly). It should be fast, and if you need it to be slower, you can iterate its output through itself and slow it artificially.
  A MAC like HMAC uses a hash, but it accepts a secret key as a parameter and it does some stuff to prevent so-called length-extension attacks (whereby given Hash(x) you can determine very quickly Hash(Concat(x, y)) for some C and x, meaning attackers can append data to your secret communications and go unnoticed). Speed is important in this application, and your secret key should already have enough security that speed doesn't matter: 128 bits of security (= 256 bit key) should outlive much of the combined computational power of the Earth. (There's 512 bit hashes because, among other reasons, one use of hashes is to cut their output in half thereby eliminating information about their internal state, and then the effective security is one-half of that, or 128 bits.)
  Key derivation functions, like PBKDF2, by contrast, have to work with very low input strength, usually 40-80 bits. By iterating the hash 1000 times, you add 10 bits of security on top of your input strength. It's still not very secure, but it's better than the alternative of nothing.
  
  --
  Wonder what the public key field is for?
11. Re:links to NIST by Anonymous Coward · 2012-12-25 07:37 · Score: 5, Informative
  
  A common misconception, but untrue. Cryptographic hashes can be used for many purposes - for storing passwords, to sign documents, to verify file integrity, as a short unique identifier for content, etc.
  The only of these for which slower is better, is password storing.
  If you are using e.g. cryptographic hash functions with a 512-bit output, it is irrelevant for practical security that one hash function is a billion times faster than another. Either way, you will not find a collision in the lifetime of the universe without finding a weakness in the hash.
  Now, this applies when we can assume that any needed keys are of good randomness. This is not the case with passwords, because human-chosen passwords have low enough entropy that they can be guessed.
  However, it is very simple to make a slow hash from a fast one by using a key derivation function like PBKDF2, which iterates over the hash function a configurable number of time, often hundreds of thousands.
  In short, many applications benefit from a fast hash algorithm, and none suffer, because you can always easily make a slower one.
12. Re:links to NIST by Anonymous Coward · 2012-12-25 07:41 · Score: 1
  
  You obviously have never used full disk encryption, ZFS, etc.
  Faster hashes will be _very_ welcome!!!!
13. Re:links to NIST by steviesteveo12 · 2012-12-25 08:28 · Score: 0
  
  No, making it easier to run multiple instances of a hash, especially on a CPU, doesn't benefit a legitimate user very much but it hugely benefits an attacker. The problem is the different workload that someone storing and verifying passwords has compared to someone who is trying to crack a long list of them. All but the biggest web services will be dealing with roughly one login at a time (ie. you're usually finished with the previous login before the next user tries to login) whereas people attacking will be trying to run as many hashes as possible as quickly as possible to find any matches.
  For password storage, you want a really unwieldy hashing algorithm that runs slowly and expensively (in terms of I/O, memory and processing) because you want to punish an attacker for running it so many times. An algorithm that's too memory hungry or esoteric to run on something like a GPU core is all to the good right now.
14. Re:links to NIST by mysidia · 2012-12-25 08:39 · Score: 0
  
  Either way, you will not find a collision in the lifetime of the universe without finding a weakness in the hash.
  If the hash is as strong as it is intended to be.
  If the hash has weaknesses (and most any hash certainly will have as of yet undiscovered weaknesses); the increased efficiency in computing the hash for the application, also results in increased efficiency of searching for a collision.
  A collision search / attack against the security of the hash will require some very large number of hashing operations. If the hash is more speed efficient, these attack operations will complete much more quickly.
15. Re:links to NIST by mysidia · 2012-12-25 08:52 · Score: 1
  
  The only of these for which slower is better, is password storing. If you are using e.g. cryptographic hash functions with a 512-bit output, it is irrelevant for practical security that one hash function is a billion times faster than another.
  No, it's not irrelevent. The 64-bit hash that cannot be sped up may be stronger than a 512-bit hash that can be computed quickly.
  If the fast hash enables me to build an ASIC that can perform 10^150 hashing operations per second instead of 10^80, then I will be able to find a collision on the weak hash within a few hours, whereas, the slower 64-bit hash might have been something that would take hundreds of years.
16. Re:links to NIST by Johann+Lau · 2012-12-25 08:59 · Score: 2
  
  All but the biggest web services will be dealing with roughly one login at a time (ie. you're usually finished with the previous login before the next user tries to login) whereas people attacking will be trying to run as many hashes as possible as quickly as possible to find any matches.
  So how does a slower hash help here? It changes nothing about this fundamental principle.
  
  An algorithm that's too memory hungry or esoteric to run on something like a GPU core is all to the good right now.
  Botnets.
17. Re:links to NIST by Anonymous Coward · 2012-12-25 09:01 · Score: 1
  
  A fast cryptographically secure hash function is always nice to have, for example, deduplication in a filesystem. You want it to be as difficult as possible to create a hash collision, while not needlessly wasting time and CPU cycles.
  For authentication, you'll of course be adding a salt and as much recursion as necessary to ensure brute force attacks aren't feasable. Nobody is going to depend on the hashing function alone.
18. Re:links to NIST by rthille · 2012-12-25 09:10 · Score: 1
  
  And has a very large number of bits in the resulting hash...
  
  --
  Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
19. Re:links to NIST by steviesteveo12 · 2012-12-25 09:18 · Score: 2
  
  I thought you weren't a crypto expert?
20. Re:links to NIST by Anonymous Coward · 2012-12-25 09:27 · Score: 0
  
  You can't “add” any bits of security strength by iteration. Output space is too big to be brute-forced efficiently and you simply slow down exploration of input space by those iterations. It has the same strength as without it, only constants are changed.
21. Re:links to NIST by SirMarth01 · 2012-12-25 09:31 · Score: 2
  
  NIST's comments on their selection of Keccak to be SHA-3: (PDF)
  
  Additionally, KECCAK complements the existing SHA-2 family of hash algorithms well. NIST remains confident in the security of SHA-2 which is now widely implemented, and the SHA-2 hash algorithms will continue to be used for the foreseeable future, as indicated in the NIST hash policy statement. One benefit that KECCAK offers as the SHA-3 winner is its difference in design and implementation properties from that of SHA-2. It seems very unlikely that a single new cryptanalytic attack or approach could threaten both algorithms. Similarly, the very different implementation properties of the two algorithms will allow future application and protocol designers greater flexibility in finding one of the two hash algorithms that fits well with their requirements.
  So, Keccak wasn't necessarily chosen because it was "superior" to the other finalists (note that it's slow when implemented in software, especially in comparison to the other finalists), but because it was different enough that, should SHA-2 be found to be fundamentally broken, SHA-3 should remain unaffected.
  An optimized version of BLAKE would be useful because it can run faster than SHA-3 in software, while also being (theoretically) stronger than SHA-2 (or other older algorithms).
  Mind you, I'm not an expert in cryptography; regardless, it probably wouldn't be the greatest choice to use BLAKE2 right away. It's still not been held up to the level of scrutiny that something like SHA-2 has. (Although I'm certain that being a finalist has helped it come under much closer scrutiny than if it hadn't been one.)
  As for why a fast cryptographically secure hash function is desirable, others have already answered that question better than I can.
22. Re:links to NIST by Anonymous Coward · 2012-12-25 09:37 · Score: 0
  
  A 100ghz 100,000 core CPU that could try a hash every 1 clock cycle wouldn't be an issue for a 12char+ strong pass-phrase. I'm not sure why people keep talking about the dangers of "fast" hashes.
23. Re:links to NIST by Anonymous Coward · 2012-12-25 09:43 · Score: 1
  
  If the fast hash enables me to build an ASIC that can perform 10^150 hashing operations per second
  Ohh, I see we're not working within the laws of thermodynamics anymore. 10^150 hashing ops you just did just consumed the entire MilkyWay for energy.
24. Re:links to NIST by aysa · 2012-12-25 10:56 · Score: 1
  
  Why would an optimized (optimized for run time speed? optimized for low memory footprint while running? optimized to minimize the likeliness of hash collisions) version of the same BLAKE entrant be more useful?
  BLAKE2 is an improved version of the SHA-3 finalist BLAKE. Like BLAKE or SHA-3, BLAKE2 offers the highest security, yet is fast as MD5 on 64-bit platforms and requires at least 33% less RAM than SHA-2 or SHA-3 on low-end systems. I can find applications in cloud storage, software distribution, host-based intrusion detection, digital forensics, revision control and embedded systems https://blake2.net/blake2_20121223.pdf
25. Re:links to NIST by Anonymous Coward · 2012-12-25 11:34 · Score: 1
  
  your theoretical CPU is slow
  custom ASICs can compute hashes for different data in parallel, for 12 character password to be secure against them, it would have to be completely random, contain letters of mixed case, numbers and symbols
26. Re:links to NIST by WaywardGeek · 2012-12-25 11:45 · Score: 0
  
  I need some good crypto advice.
  I happen to be at the point in writing a P2P application framework where I need to select a hash function for authenticating messages. Of course, I'll make it selectable in the future, but I need to choose a default hash. I was about to settle on SHA-2. However, I'm not happy with the performance of SHA-2 and SHA-3 compared to SHA-1, and frankly I need MD5 speed. Blake2p sounds like it fits the bill. I've downloaded the code and it seem simple enough to include in my project. I'm very tempted to start using it, at least for now.
  The scheme I'm thinking of using is to do a standard key exchange so both peers share a secret key, and then to append the shared secret key to each message, take a 64-bit cryptographic hash of the whole thing, and append that to the message (without the shared secret key). The other peer can easily verify the hash, which should make random errors virtually impossible to get through, compared to the 16-bit CRC in TCP/IP packets, which I've seen fail plenty of times. 64-bits isn't enough to use as a document signature, but but for P2P message authentication, is there any reason to use a longer hash? Are there any good reasons other than the obvious (blake2 is not well battle tested) to avoid blake2?
  The value of transactions over this protocol I expect to be credit-card sized purchases and small bank account values, rather than military grade secrets. If the PSK is long, say 512 bits, I don't see how guessing will get anywhere. Am I missing some attacks? Thanks in advance.
  
  --
  Celebrate failure, and then learn from it - Nolan Bushnell
27. Re:links to NIST by WaywardGeek · 2012-12-25 12:30 · Score: 2
  
  No, his point was valid. You can always make a slow hash algorithm out of a fast one, for example by rehashing over and over again a 100K times. Speed in a hashing algorithm is always a good thing, so long as its used properly, which unfortunately often not the case. I'm hoping to avoid making a mistake myself. I'm considering using a blake2 64-bit authentication has in P2P messages. Any good reasons not to?
  
  --
  Celebrate failure, and then learn from it - Nolan Bushnell
28. Re:links to NIST by Jorl17 · 2012-12-25 12:47 · Score: 2
  
  Why not Ask Slashdot?
  
  --
  Have you heard about SoylentNews?
29. Re:links to NIST by sqlrob · 2012-12-25 13:00 · Score: 1
  
  No, nobody SHOULD depend on the hashing function alone.
  There's a big difference between "shouldn't" and "doesn't"
30. Re:links to NIST by marcansoft · 2012-12-25 13:31 · Score: 1
  
  First of all, you mention the TCP/IP checkum, at the same time as key exchanges, long PSKs, and money transfer. Which is it, simple message integrity or message authentication? If you need authentication, you shouldn't even be mentioning TCP/IP checksums. If all you need is integrity, then just append an MD5.
  Assuming you need authentication: I don't have any opinion on Blake2, but you should use an HMAC instead of just appending the shared secret key and taking the hash. HMAC can be built on top of any hash function, including Blake2. You should also make your MACs at leasts 128 bits long, preferably 192 or 256. 64 bits is definitely bruteforceable these days. I wouldn't settle for anything shorter than 256 for a protocol that involves money.
  Keep in mind that a basic message authentication code is only one piece of a secure protocol. There are many possible attacks that might slip through (e.g. replay attacks, MITM, timing attacks, ...). For example, you need to ensure that an attacker can neither reinject a message from the current session back into it (e.g. by using a sequence number in the signed payload) nor reinject a message from a different session (e.g. by ensuring that there is a random component to the shared secret) nor somehow guess the right MAC code (e.g. by making sure that the wrong-MAC responses do not leak any information, neither in contents nor timing), and of course there's always the host identification problem (preventing a simple MITM where the attacker performs a key exchange with both sides and resigns/reencrypts traffic both ways). Honestly, your first choice should be to use an existing well-tested protocol, such as TLS (you can build your own host verification rules on top of it, you don't have to use the "well-known" root CA list). Failing that, consult a real crypto expert.
31. Re:links to NIST by Anonymous Coward · 2012-12-25 13:36 · Score: 0
  
  Okay, so first, what you want is a message authentication code (MAC).
  The "industry standard" for MACs is HMAC-SHA-1 or HMAC-SHA-256. You should consider using one of these if at all possible. There are many robust implementations of these, which may also contain protection against less obvious attacks like timing attacks.
  (These typically have a verification function that take the message, the given hash, and the key, and returns true if the message is valid. E.g. crypto_auth_verify )
  If you really do need the performance and are willing to use a bleeding-edge algorithm, there is nothing technically wrong with using BLAKE2's keyed hashing mode. (Use blake2*_init_key(), or pass a key and keylen to blake2*())
  Though if you are going to cut it down to 64 bits anyway, you should also check out SipHash, which is even faster and is geared towards this use case. It uses a 128-bit key and outputs a 64-bit hash.
32. Re:links to NIST by Johann+Lau · 2012-12-25 16:22 · Score: 1
  
  I'm not trying to be dense, I just really don't get it.
  For me, at least when just considering CPU, 1000 iterations of Algorithm A take as long as 1 iteration of an Algorithm B which is 1000 times slower, and a slower hash makes it slower for both sides in equal measure, likewise for a faster hash. That's why I claimed "it's a wash".
  If there is a way to use memory/IO in a way that increases the cost for attacking it more than than the cost of defense, someone has to actually spell it out for me, or I'll remain ignorant :(
33. Re:links to NIST by mysidia · 2012-12-25 17:26 · Score: 2
  
  I'm considering using a blake2 64-bit authentication has in P2P messages. Any good reasons not to?
  That may not be a very conservative choice from a security standpoint. The algorithm is new, and has less review/scrutiny and has stood less of a test of time than some other algorithms such as SHA1, RIPEMD-160, Tiger, VSH, Whirlpool. The protocol or its optimization may be broken in a subtle way that will be discovered within 2 to 6 years.
  Even BLAKE the SHA-3 finalist may have stood less scrutiny so far. Although; the finalist protocols for SHA3 will eventually be under a microscope, and a great deal of scrutiny from many crypto researchers. It remains to be seen of there will be an attack against new "optimized" version; frankly, I'm not sure how much scrutiny the optimized version will get if it's not also a finalist for SHA3, and it's not right now a widely used algorithm either.
  I would suggest implementing the protocol in some manner with support for multiple choices of hashing algorithm, so you can upgrade later, or replace/transition away from the BLAKE-fast algorithm without breaking the network, if it turns out to have issues.
34. Re:links to NIST by DMUTPeregrine · 2012-12-25 19:05 · Score: 1
  
  Fast hashes are bad for passwords. Slow hashes are bad for data integrity checking, message authentication codes, and other such things. They are similar constructs, but used for very different purposes.
  
  If you want to verify your 1TB video collection got transmitted properly you want a fast hash to keep it from taking a long time. That same hash would be totally unsuitable for password hashing.
  
  --
  Not a sentence!
35. Re:links to NIST by Dr_Barnowl · 2012-12-25 23:02 · Score: 1
  
  When you're hashing your password, you only have to do it once. Your multiplier is 1.
  When you has to defeat a password, you have to do it as many times as you need to, to match the previously hashed password. Let's say you have a really crap password (a 6 digit number) and your attacker knows this. Your multiplier is between 1 and 1,000,000
  The hash is the difficulty factor. If your hash is optimized for throughput, it's cheap. The advantage is that it's really good for establishing data integrity - large volumes of data pass through it quickly. This is the opposite of what you want in a password hash, where the data volume is small.
  If we take hypothetical hashes A and B, where the cost of A is 1 and the cost of B is 1,000 , we can see that the cost of hashing data with B is too much for bulk data, but the cost of doing it for passwords makes it harder for an attacker, who has to hash a vast amount of data compared to someone logging into their account.
  A : 1 x 1 - 1,000,000 = 1 - 1,000,000
  B : 1,000 x 1 - 1,000,000 = 1,000 - 1,000,000,000
36. Re:links to NIST by mattpalmer1086 · 2012-12-25 23:39 · Score: 1
  
  Follow this simple rule: don't invent your own crypto. And that goes double for protocols. It's hard. I mean, really, really hard to get it right. If you are not an expert, then there are almost certainly known attacks which will undermine the security of your entire system. If you are an expert, there are still probably subtle attacks (but fewer of them which may not be discovered for years).
  I understand most standard modern crypto and protocols quite well. I have studied and worked with it long enough to recognise that using tried and tested methods is almost always the right thing to do. I am not an expert, but I am hopefully a reasonable practitioner.
  With that disclaimer out of the way, you need to identify what security you are trying to achieve first, before tacking on cryptographic primitives left right and center. You seem to want message confidentiality and message authentication. For confidentiality with message authentication, use standard constructions. Preferably use an authenticated encryption mode, which has the advantage that they can take less message space than the old style encrypt-then-HMAC constructions, and are usually faster than doing either separately. And you typically only need a single key. If you use the encrypt-then-MAC construction, don't use the same key for encryption as you do for MACing.
  Does confidentiality extend to the attacker knowing whether he has seen the same encrypted plaintext before? I.e. should the same plaintext always encrypt to a different ciphertext, or are you happy for the same ciphertext to always be produced for the same plaintext? Do you care about replay attacks? What happens if an attacker replays an old message? Message counters or timestamps can help here. What about non-repudiation? Does it matter whether you can prove which side generated the message or not? For payments, this might be important.
  This only scratches the surface. Get proper advice to analyse the true security requirements of your protocol, and use standardised constructions in the implementation. Use BLAKE by all means if it fits the security you need to achieve and performance is a primary requirement. But figure out what security you need first.
37. Re:links to NIST by steviesteveo12 · 2012-12-26 01:38 · Score: 1
  
  Dr_Barnowl puts it very well too. I'm taking his example of a 6 digit password here. IIRC someone (maybe at Google?) did research that most users will sit for around a second on a login before they start wondering if it's broken, so that gives you a whole second -- billions of processor cycles -- to run anything you want on the single password. An attacker doesn't have the luxury of spending that much time on a single password. For example, a million seconds (000000-999999 @ 1s each) is about a week and a half. Parallelism helps attackers, really quite a bit -- a single Nvidia GeForce GTX690 has 3072 cores which means that with all cores running you can cut that down to 5 minutes with one graphics card which is why you don't want your hash to be easily run on hugely parallel hardware. The important thing is that trying billions of possibilities in parallel is only something an attacker ever would do. That means you want to make the hash function too big to fit into a GPU core's cache, use instructions that a GPU can't process, lock in some way etc etc.
38. Re:links to NIST by steviesteveo12 · 2012-12-26 01:39 · Score: 1
  
  Exactly, that's very well put.
39. Re:links to NIST by WaywardGeek · 2012-12-26 03:31 · Score: 1
  
  Thanks! Both to you and the others who replied. These comments are quite useful, and exactly what I was hoping for. First, I really am focusing on authentication of small messages. If encryption is needed, I expect the communication channel to be secured using existing mechanisms. My basic P2P protocol does not address secrecy, and is meant to be ISP friendly. In short, I'm hoping to build a Ripple based system for exchange of value, though that's just part of the P2P platform, which I intend to be a rapid application development tool for high performance P2P apps. While secrecy is an aim of Ripple, it's not one of my aims, and users of the system may request the state of any or all of the Ripple network. I also intend the system to be IRS friendly, and frankly, Ripple becomes much simpler if you have access to the whole network.
  Based on you're guys feedback, I'm thinking SipHash sounds like an excellent fit, but I'll provide a software switch to the P2P server to switch to HMAC-SHA2. I'll include a message sequence number between each pair of peers which are never reused in a session. Is there anything else I need to do?
  Authenticating messages between peers who already have a shared key is code I'm writing now, so thanks for the instant feedback. For signing Ripple money, and key exchange, I'll need a proven public key crypto system. BitCoin uses an elliptic curve system, which considerably reduces the size the transaction history. Do you guys have any advice for choice of e-money signing systems? There's no really hurry here, I'm just looking for initial advice. An important consideration is that I wish to support micro-transactions as small as 0.01 cent. The typical cost of computation and bandwidth for such transactions needs to be far less than this, say 0.0001 cents or lower.
  
  --
  Celebrate failure, and then learn from it - Nolan Bushnell
40. Re:links to NIST by ILongForDarkness · 2012-12-26 04:44 · Score: 1
  
  But doesn't that also mean that your user authentication process will be 1000 slower (at least for the CPU part of the process)? I'm assuming the user types their password and the hash gets sent over the wire. Hashing might be a bigger part of the type with Blake on a non-Intel piece of hardware (say a smart phone) since the instruction set might not be there, and definitely the CPU horsepower isn't.
41. Re:links to NIST by Johann+Lau · 2012-12-26 04:45 · Score: 1
  
  Ah! Now that I got it, I feel a bit stupid for not seeing that right away.. thanks a lot to you all for explaining over and over ^^ Not knowing what the big deal / difference is kinda bugged me, now I have closure.
42. Re:links to NIST by ILongForDarkness · 2012-12-26 04:48 · Score: 1
  
  Not to mention liability issues: using standards and getting exploited anyways is much different than trying to roll your own and being the only one vulnerable to the attack ... "the buck stops ... hopefully somewhere else".
43. Re:links to NIST by steviesteveo12 · 2012-12-26 05:52 · Score: 1
  
  That's not a problem. You would never do any of this on the client end. It's far too easy for someone to strip out the hashing the password stage and replace it with a false "yeah, it worked" signal. Sony did a howler where they implemented a client side CAPTCHA where they sent out the right answer and asked if you'd typed it in. http://cryptogasm.com/2011/07/sony-captcha-fail/
  It's might be 1000x slower but, so what? You can afford to take half a second longer. Users generally won't even notice.
44. Re:links to NIST by WaywardGeek · 2012-12-26 09:59 · Score: 1
  
  I agree. I'm planing to use SipHash and having a switch to use HMAC-SHA2. Thanks for the advice.
  
  --
  Celebrate failure, and then learn from it - Nolan Bushnell
45. Re:links to NIST by Anonymous Coward · 2012-12-26 12:39 · Score: 0
  
  There is no such thing as "doesn't" in this universe. Everything in this universe is based on probability and has a chance of less than 100% and greater than 0%. All you can do is approach zero and get as close as possible.
46. Re:links to NIST by Anonymous Coward · 2012-12-26 12:45 · Score: 0
  
  Well then, a 20char strong pass-phrase and call it a day. You even build a theoretically perfect 100% efficient computer that could count that high unless you found a source of energy that rivaled the observable universe.
47. Re:links to NIST by mysidia · 2012-12-26 13:17 · Score: 1
  
  No, his point was valid. You can always make a slow hash algorithm out of a fast one, for example by rehashing over and over again a 100K times.
  Not true. The word always is very dangerous when you don't restrict it. You can always make a slow implementation of a hash algorithm by rehashing over and over again 100K times.
  It may very well be that the result of performing all those 100K repetitions can be computed in a different way, that is barely any slower than 1 more repetition of the original hash, so your slow implementation that does 100K repetitions, is not the fastest way to accomplish them.
  Ergo, you don't have a slow hash at all.
48. Re:links to NIST by Anonymous Coward · 2012-12-27 01:53 · Score: 0
  
  Please use a specialized MAC construction for this, and don't build it yourself (e.g. appending the key to the message). In the case of Blake2 there is a standardized keyed mode that you can use. This code is includes in both the c and the C# implementations. BTW with Blake2s key sizes beyond 256 bits won't increase your security, but good random 128 bit keys are already enough to prevent practical attacks, so that's not a problem.
  Alternatively you could consider one-time-macs. These are pretty fast, and are getting popular as part of authenticated modes such as GCM. There is also SipHash which is a keyed hash with 64 bit output, that can be used as MAC.
  So there are certainly faster alternatives to Blake2 when you need a MAC. Blake2 offers collision resistance for unkeyed hashing, a property that MACs don't need. So specialized MACs can be made faster by sacrificing that property.
  ----
  You should also consider existing protocols, such as TLS. AES-GCM is pretty fast on modern CPUs, so choose a fast suite.
Time by Anonymous Coward · 2012-12-25 06:27 · Score: 1

If security is important to you, don't use it until its been around for a few years at least. Boy was it annoying replacing all the md5 usages in various codebases... and that's been around for more than "a few years."
1. Re:Time by magic+maverick+ · 2012-12-25 07:08 · Score: 1
  
  So use a generic hashthis() function (or class, whatever), and then you don't have to replace sha3() or blake2() or whatever through your code, merely modify the hashthis() function to use the new algorithm instead. Forward thinking amirite?
  
  --
  HELP MY ACCOUNT HAS BEEN HACKED BY AN ILLIBERAL ART STUDENT SET TO DESTROY THE INTERWEBZ!
2. Re:Time by Gaygirlie · 2012-12-25 07:24 · Score: 4, Informative
  
  So use a generic hashthis() function (or class, whatever), and then you don't have to replace sha3() or blake2() or whatever through your code, merely modify the hashthis() function to use the new algorithm instead. Forward thinking amirite?
  Otherwise yes, but it would make all the existing data unreadable. If you make it easy to change the hashing method like that then you will also have to always track what data was hashed with what method.
3. Re:Time by preaction · 2012-12-25 07:47 · Score: 1
  
  Which is exactly what /etc/shadow does, and it's been around for a long time. These are all solved problems if anyone would pay attention.
4. Re:Time by Gaygirlie · 2012-12-25 07:55 · Score: 1
  
  Which is exactly what /etc/shadow does, and it's been around for a long time. These are all solved problems if anyone would pay attention.
  No one was talking about unix passwords here. Data can be almost anything that needs to be hashed and it may be stored in SQL - databases, random text files, proprietary binary files and so on. In other words your referral to /etc/shadow is irrelevant.
5. Re:Time by zippthorne · 2012-12-25 07:56 · Score: 1
  
  You have to do that anyway...
  For passwords, I'd assume (but probably be wrong...) that you'd convert the password to the new hash either when the user signs in next, or when the user changes their password next, but you still have to be able to check against the old hash, so you'd always need to know what type of hash that is. Seems to me that the best place to store that is in a field in the database right next to the hash itself.
  One would assume that hashthis() would be implemented to either be aware of the hash's algorithm (a property of its object, perhaps?), or take an argument that indicates the hash.
  I would assume that the feature, "able to change the hash algorithm" would tend to get added either around the first time that it needed to be updated, or by experienced developers who have already experienced that event in other applications.
  
  --
  Can you be Even More Awesome?!
6. Re:Time by magic+maverick+ · 2012-12-25 08:12 · Score: 1
  
  I almost said something like that, along with the solution, but figured people could figure it out on their own.
  With password hashes, the type of hash tends to be part of the end result (e.g. $B$ indicates a hash of type B, while $A$ indicates a hash of type A; not real examples, 'cause I can't be bothered looking them up). You could easily do something similar with generic hashes.
  zippthorne (in a sibling to this post) gave some other thoughts.
  
  --
  HELP MY ACCOUNT HAS BEEN HACKED BY AN ILLIBERAL ART STUDENT SET TO DESTROY THE INTERWEBZ!
7. Re:Time by preaction · 2012-12-25 08:43 · Score: 1
  
  People were talking about storing the hash algorithm with the hash (and implying it was a bad thing, or too much to ask for a simple programmer), which is what /etc/shadow does (which they did back before we had as much power and space as we do now.) The fact that /etc/shadow is storing passwords is, as you said, irrelevant. It stores info about the hash with the hash so that later you know what hash to use to verify.
8. Re:Time by mysidia · 2012-12-25 09:17 · Score: 1
  
  There is a common method of doing this, by inserting a "HASH TYPE" header in front of a password. RFC2307
  SHA256 CRYPT() with 10000 rounds - {SHA256-CRYPT}$5$rounds=100000$hK.9TGSGMfuVhMY1$ukBEvc3eTCJNgiK.BIsNIWmq9JU3D8tMapmqwJB6ip0
  Cleartext password - {plain}password {clear}password
  Traditional Unix crypt - {crypt}FHrLg6eHMx2nA
  Unsalted MD5 - {md5}
  Salted MD5 - {smd5}p47J0UeLzLY+/Lk7q0ohOnMJTGI=
  Unix MD5 Crypt - {md5-crypt}$1$QgAqzRlm$Wo69omVJhJHZR2aOKJ4qs1
  Unsalted SHA - {sha1}...
  Unsalted SHA - {sha}W6ph5Mm5Pz8GgiULbPgzG37mj9g=
  Salted SHA1 - {ssha}Dh+8hirJLTZa79Pupbn4W5qbRMP9C7Bv
  SHA256 - {sha256}
  SHA512 - {sha512}
  Salted SHA 256 - {ssha256}
  Salted SHA 512 - {ssha512}
  Windows NT Hash / MD5 - {nt}
  NTLM - {ntlm}
  Lanman - {lm}
  {CRAM-MD5}
  {plain-md4}(MD4 in hex)
  {SKEY}....
9. Re:Time by aliquis · 2012-12-25 09:38 · Score: 1
  
  Because it's so hard to store hash,MD5 or hash,SHA3 or whatever in two fields in a database.
They just need five more versions then.. by Dynamoo · 2012-12-25 06:30 · Score: 0

'nuff said.

--
Never email donotemail@WeAreSpammers.com
1. Re:They just need five more versions then.. by MickyTheIdiot · 2012-12-25 06:31 · Score: 1
  
  Version 2 was code named Jenna.
2. Re:They just need five more versions then.. by Anonymous Coward · 2012-12-25 07:14 · Score: 0
  
  I'm waiting for Avon.
  "I'm not reversible, I'm not stupid, and I'm not hashing."
Missing the point by Anonymous Coward · 2012-12-25 06:49 · Score: 1, Interesting

There are 3 aspects that are important to the security of hashing algorithms.
1) one-directional. You cannot get back to the original from the hash.
2) unique-ness. Fewer different sources with hash to the same result.
3) takes time to make. The quicker it is to create the hash, the quicker it is to brute-force your way through all possible combinations to find a hash that matches.
Most password cracking happens by getting a list of hashed password values through some other securitu exploit, and running as many hashes as you can as quickly as you can to find match.
If they're claiming a fast hash is a good thing, they're missing the point.
1. Re:Missing the point by Georules · 2012-12-25 07:13 · Score: 5, Insightful
  
  Fast hashing has its uses as well. Such as verifying data transmissions. Passwords aren't the only things that we hash.
2. Re:Missing the point by pipatron · 2012-12-25 07:16 · Score: 1
  
  3) takes time to make. The quicker it is to create the hash, the quicker it is to brute-force your way through all possible combinations to find a hash that matches.
  Most password cracking happens by getting a list of hashed password values through some other securitu exploit, and running as many hashes as you can as quickly as you can to find match. If they're claiming a fast hash is a good thing, they're missing the point.
  Bullshit. You don't bruteforce a 512 bit hash, no matter how fast it is. It simply doesn't work like that. You must find a weakness in the algorithm to break even much smaller hashes.
  
  --
  c++; /* this makes c bigger but returns the old value */
3. Re:Missing the point by magic+maverick+ · 2012-12-25 07:18 · Score: 3, Informative
  
  Nah, you are. Hashes are used for a lot more than just passwords. Yes, for passwords a fast generic hash function like SHA2 or SHA3 (let alone MD5) is not such a good option. But for verifying that a downloaded executable or other file has not been modified, it's mostly fine. But don't use MD5, because it's completely broken (e.g. with it being possible to have two distinct PDF files having the same hash).
  For password hashing use Blowfish/Bcrypt.
  
  --
  HELP MY ACCOUNT HAS BEEN HACKED BY AN ILLIBERAL ART STUDENT SET TO DESTROY THE INTERWEBZ!
4. Re:Missing the point by Agent+ME · 2012-12-25 07:36 · Score: 1
  
  Taking time is only important if your input data is small and you don't want someone guessing the input data and verifying it against the hash.
  If you want a hashing algorithm to take time, it's not that hard: just run it X times.
5. Re:Missing the point by OneAhead · 2012-12-25 07:38 · Score: 1
  
  No weakness required, simply the ability to make educated guesses about the data being hashed. As in brute forcing password hashes. Granted, hash functions are used for a host of other applications, but password hashes happen to be pretty high-profile, and most definitely have a requirement that they shouldn't be too fast. You can call GP's claim 3) not generally true, but to call it bullshit is, well, bullshit.
6. Re:Missing the point by Desler · 2012-12-25 07:53 · Score: 1
  
  Hashes are used for far more than storing passwords securely.
7. Re:Missing the point by PhrostyMcByte · 2012-12-25 08:17 · Score: 2
  
  3) takes time to make. The quicker it is to create the hash, the quicker it is to brute-force your way through all possible combinations to find a hash that matches.
  I wouldn't say that. The hash itself should be as quick as possible, so long as it satisfies the other requirements. We have things like PBKDF2 when we want a hash to eat up a lot of CPU, and scrypt when we want to eat up lots of RAM as well.
8. Re:Missing the point by eric_herm · 2012-12-25 08:34 · Score: 1
  
  You forgot : changing a little bit the input should ideally produce a totally different output ( ie, good cascading effect, if I am not wrong on the property ).
9. Re:Missing the point by Immerman · 2012-12-25 09:22 · Score: 1
  
  Just to clarify - it's not the duplicate hashes that are the problem. Hash collisions should *always* be considered inevitable since the number of possible pdfs (or whatever) will exceed the number of possible hash values by many, many orders of magnitude unless the hash size is as large as the original file. The problem is that it's possible to *intentionally* cause a hash collision - for example by appending some "garbage" data to a compromised executable to make it appear to as though it's the original. And that's really only a problem in situations where you're using the hash to guard against malicious intervention, which is only one application of hashes. If you're simply using it to detect transmission or storage errors it's a non-issue. And if you're using it to generate something like a really good hash-table key (something secure hashes can also be quite valuable for) then you still need to be able to recognize and gracefully handle duplicate keys because collisions *will* eventually occur, a good hash just makes them uncommon enough that they're unlikely to cause performance penalties.
  
  --
  --- Most topics have many sides worth arguing, allow me to take one opposite you.
10. Re:Missing the point by Anonymous Coward · 2012-12-25 10:15 · Score: 0
  
  In most applications, data being hashed is not even secret. That 3rd claim is simply irrelevant for general purpose cryptographic hash functions. It applies only to special constructions for password storage.
11. Re:Missing the point by Anonymous Coward · 2012-12-25 10:17 · Score: 0
  
  A little knowledge is a dangerous thing. Moron.
12. Re:Missing the point by Pseudonym · 2012-12-25 10:42 · Score: 1
  
  Hash collisions should *always* be considered inevitable since the number of possible pdfs (or whatever) will exceed the number of possible hash values by many, many orders of magnitude unless the hash size is as large as the original file.
  The number of possible PDFs is larger, but the number of actual PDFs is lower. Much lower.
  A very reliable rule of thumb is that if there are N possible hash values, then you should expect 0.5 hash collisions after hashing N items. (Exercise: Prove this. You want to consider the limit as N goes to infinity.) So if you're hashing PDF files and looking for a collision, then for a 512-bit hash, you need around 2^256 PDF files to have a realistic chance of a collision. I'd wager that there aren't anywhere near 2^256 PDF files.
  Of course hash collisions should always be considered inevitable. As you say, that's just good programming practice. However, if your hash function is good and has a large range, it can safely be considered rare.
  
  --
  sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
13. Re:Missing the point by magic+maverick+ · 2012-12-25 11:08 · Score: 1
  
  Well yes. Good point that I should have made, it is the intentional aspect that is most worrisome. You take a PDF file, take the hash, and then can easily generate another PDF file with the same hash. Which apparently could be used for fraud. Or, take an executable and then generate a malicious one with the same hash and trick someone into downloading it instead of the correct one. I should have expanded on that point in my original post.
  
  --
  HELP MY ACCOUNT HAS BEEN HACKED BY AN ILLIBERAL ART STUDENT SET TO DESTROY THE INTERWEBZ!
14. Re:Missing the point by WillerZ · 2012-12-25 11:40 · Score: 1
  
  A very reliable rule of thumb is that if there are N possible hash values, then you should expect 0.5 hash collisions after hashing N items.
  No you shouldn't. You should expect 0.5 collisions after hashing N/2 items. Trivially you are guaranteed at least M collisions when hashing N+M items.
  I don't actually know off the top of my head how many collisions you should expect if you hashed N items.
  
  --
  I guess today is a passable day to die.
15. Re:Missing the point by Immerman · 2012-12-25 12:14 · Score: 2
  
  Okay, I can only assume that that's a typo - if you have N possible hash values and have hashed N items then you almost certainly already have many, many collisions, and are guaranteed a collision on the (N+1)th hash by the pigeonhole principle.
  Consider that a good hash function will bear many similarities to a random number generator and you'll see that it's a variant of the birthday problem - you don't need 180 people in a room to get a 0.5 chance of two people having the same birthday, only something like 20-30 (I don't remember exactly), and the effect scales sub-linearly. Logarithmically if I remember correctly. So yes, a good hundreds-of-bits hash function will generate values that can safely be considered rare, just NOT unique. And even events with billions-to-one against odds happen all the time in the real world, just not in a predictable fashion.
  
  --
  --- Most topics have many sides worth arguing, allow me to take one opposite you.
16. Re:Missing the point by Anonymous Coward · 2012-12-25 14:52 · Score: 0
  
  Link to source? I worked for a short time in anti-malware development. MD5s are often used to identify binaries. Malware authors could benefit somewhat from being able to collide with the MD5 of a well-known benign binary (detection evasion). I am not a crypto expert, but I was only aware of MD5 collision generation based on carefully crafted input files. That is, I did not find that a general method existed for modifying an arbitrary input file in any way such that a different set of bytes would have the same MD5. I would be interested in reading about it if such a thing exists.
17. Re:Missing the point by fnj · 2012-12-25 16:11 · Score: 1
  
  Are you sure you don't mean "you need around 2^511 PDF files"?
  2^256 is not anywhere near half of 2^512.
18. Re:Missing the point by fnj · 2012-12-25 16:36 · Score: 2
  
  Good and fast hashes are all you need for any purpose. You can't make a slow hash fast, but it's trivially easy to make a fast hash slow. You just use sequential rounds, enough of them to make it slow.
  SHA-512 is fine for passwords. It's the best there is. You're nuts to use anything else, the US military agrees with me, and it is the default in RHEL6 and other recent security conscious distros. The thing is, nobody with any sense uses a single round for this purpose. They use 5000, or 50,000, or 719,246. When you configure your password security on linux to SHA-512, glibc defaults to 5000 rounds.
19. Re:Missing the point by Anonymous Coward · 2012-12-25 17:41 · Score: 0
  
  It was definately me that was missing the point here. As has been pointed out to me, hashing has many more uses than just passwords (just as thumbprints have more uses than unlocking doors); and as with everything, faster is better — if your password hashing hasn't taken long enough, hash it again, and repeat until it *is* sufficiently time-consuming.
  To everyone who pointed out my fallacy without being condescending about it, thank you and Merry Christmas.
  To everyone who was an asshole about my mistake, well, Merry Christmas to you too, because that's what I was taught Christmas is about: whether or not you celebrate Christmas, Christmas celebrates you.
20. Re:Missing the point by Pseudonym · 2012-12-26 13:13 · Score: 1
  
  Okay, I can only assume that that's a typo
  
  What I wrote was √N, but Slashdot in its wisdom cut off the square root sign.
  If there are N possible hash values, you should expect 0.5 collisions after hashing sqrt(N) items.
  
  --
  sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
21. Re:Missing the point by Pseudonym · 2012-12-26 13:14 · Score: 1
  
  Slashdot screwed up my comment. Please see this correction.
  
  --
  sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
22. Re:Missing the point by Pseudonym · 2012-12-26 13:15 · Score: 1
  
  Slashdot screwed up my comment. Please see this correction. 2^256 is the square root of 2^512.
  
  --
  sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
23. Re:Missing the point by Pseudonym · 2012-12-26 13:18 · Score: 1
  
  By the way, to answer your question: If there are N hash values and you hash N items, you should expect N(1-2/e) collisions. The proof of this is also left as an exercise.
  
  --
  sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
24. Re:Missing the point by Anonymous Coward · 2012-12-27 03:51 · Score: 0
  
  Take your binary file, pad in some junk data. Keep changing the junk data until you get a collision. MD5 isn't that hard anymore. The old Microsoft MD5 cert has already been broken using similar, and was used to insert falsely signed updates into Windows a few months back.
  
  Obviously there is a way to optimize the generation of your junk data to more quickly produce a collision; don't just brute force it.
25. Re:Missing the point by DrVxD · 2012-12-28 11:16 · Score: 1
  
  Take a look at this
  
  --
  Not everything that can be measured matters; Not everything that matters can be measured.
26. Re:Missing the point by DrVxD · 2012-12-28 11:18 · Score: 1
  
  whether or not you celebrate Christmas, Christmas celebrates you.
  But only in Soviet Russia
  
  --
  Not everything that can be measured matters; Not everything that matters can be measured.
27. Re:Missing the point by DrVxD · 2012-12-28 13:16 · Score: 1
  
  I don't actually know off the top of my head how many collisions you should expect if you hashed N items.
  One of the characteristics of a good cryptographic hash is that it has a uniform distribution in the hash space - so really, you have a generalisation of the birthday paradox; the section there on 'Collision Counting' gives the expected number of collisions as
  n - d + d ( ( d -1 ) / d ) ^ n
  (where d is the number of possible hash values, and n is the number of items).
  Since we're hashing N items, with N outcomes, then we can substitute d==N, n==N
  N - N + N ( ( N - 1 ) / N ) ^ N
  and simplify a little:
  N ( ( N - 1 ) / N ) ^ N
  My calculus is embarrassingly rusty, so I did a quick graph of that (and its differential) on Wolfram Alpha, and it looks to be tending to around 36.7% collisions, which I thought was surprisingly high - but then again, the birthday paradox still strikes me as a surprising result...
  
  --
  Not everything that can be measured matters; Not everything that matters can be measured.
Faster? by sgnn7 · 2012-12-25 06:59 · Score: 0

Increased speed of hashing is usually a bad thing since passwords stored many times use a one-way hash function. With a faster hashing speed those passwords will be faster to crack. Personally, I'd opt for the highest-enthropy, slowest-speed, and lowest collision ration hashing function.
1. Re:Faster? by Anonymous Coward · 2012-12-25 07:09 · Score: 0
  
  It would probably be quite easy to get a dedicated FPGA to either perform hashes much faster, or perform many of them in parallel (or both). For a good hashing algorithm, making it run ten times as fast on a CPU will not make it significantly easier to break.
2. Re:Faster? by Buzer · 2012-12-25 07:13 · Score: 1
  
  It depends on what hashing function is used or. For passwords, yeah, that kind of function is good. But that's not the only use for hash function. If you need to know if files X and Y in different systems are identical, you want that checksum pretty fast. If you are transmitting data at 10Gbit/s and want to make sure it's going without problems, you are going to need something very fast. But you most likely want to make sure it's still slow enough that it cannot be bruteforced on the wire.
3. Re:Faster? by Anonymous Coward · 2012-12-25 07:22 · Score: 4, Informative
  
  Faster hashing is better. The good guys have to pay a cost of X for hashing at b bits. The attacker has to, ideally, pay a cost of 2^b*X (well, a little less due to the Birthday paradox, but it'll still be exponential). Halving X helps the good guys, because hashing is now faster for everyone. It doesn't help the attacker because you should have chosen b to be so big that halving X makes just absolutely no difference because 2^b is so big that it's completely impractical even if X is just the time for a single cycle on a CPU.
  Here's another way of looking at it: trying to impede the attacker by increasing X is the wrong idea because you ALSO have to pay for X. Instead, you want to focus on b because here your cost grows slowly with b while the attacker's cost grows exponentially with b. So smaller X is better, that is, faster hashes are better.
4. Re:Faster? by Anonymous Coward · 2012-12-25 08:27 · Score: 0
  
  Mod parent up. It is easy to slow down a hash for specific applications (like passwords, which is about the only application in which you want a slower hash), but for most other applications, a faster hashing algorithm is better.
5. Re:Faster? by sydneyfong · 2012-12-25 09:24 · Score: 2
  
  Generally you're right.
  However, for passwords specifically, you'll need longer plaintext passwords for this to work. It doesn't matter how many bits your hash function is at, if the average password is only 8 characters of Alphanumeric (which, unfortunately, has entropy much less than 64 bits...). Salts help against things like rainbow attacks, but it won't help if an attacker is trying to crack one specific account that is protected by a 8 character password -- in that case, the speed of the hash function is the only variable in the cracking effort.
  We all know we should have longer plaintext passwords, but the fact is -- our puny brains cannot remember random characters that well.
  And passphrases haven't really caught on, unfortunately.
  
  --
  Don't quote me on this.
6. Re:Faster? by Anonymous Coward · 2012-12-25 09:45 · Score: 2, Interesting
  
  That's why there are dedicated hash functions for password hashing like bcrypt and scrypt that should be used for this. One should never use generic cryptographic hash function for storage of passwords directly. Being slow was never considered as a goal in design of cryptographic hash functions, they are intended to be practical replacements for random oracles. They could, however, be used as a building blocks for PBKDF that might be appropriate for password storage.
7. Re:Faster? by Pseudonym · 2012-12-25 10:46 · Score: 1
  
  The birthday paradox only lets you find a collision faster, not crack a specific password faster.
  If you have a good b-bit hash function, then the expected cost of "undoing" a specific hash is X*2^(b-1), but the expected cost of finding half a collision (the birthday paradox scenario) is X*2^(b/2).
  
  --
  sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Before "too fast = bad" by Anonymous Coward · 2012-12-25 07:38 · Score: 2, Interesting

I know I’m already too late for a few, but fast hashing is good. The only thing you want a slow hash for is a PBKDF—and, to be honest, that is and should be an entirely different construct to a hash, although you can make PBKDFs out of cryptographic hashes.
I’m still not seeing anything that makes this better than Skein, however, which is very fast in software, can perform signature pinned and keyed hashes and rounds (which could be used to make a PBKDF of arbitary strength), and even has a built-in tree hash function, and parallelises well. Skein’s still my favourite SHA-3 finalist by far, and I’m going to be using it in production instead of SHA-3—given FIPS won’t be driving SHA-3 adoption in short order, we won’t get hardware support for some time, and the NSA value hardware speed far more than software speed (as they mostly work with hardware CSMs). Further, I am not entirely convinced the round function underneath the sponge construction is necessarily different enough to survive an attack that would weaken AES.
Keccak’s way, way too slow given Skein and BLAKE are faster and of comparable security (although BLAKE was the second least favourite of my picks), and I suspect that SHA-3 will face slow adoption: there’s nothing obviously wrong with SHA-2, and absolutely no reason to move from SHA-256 to something significantly slower than SHA-256 when other hashes of comparable security exist which have received a similar amount of cryptographic attention and run faster. Keccak’s a poor sell.
As for PBKDFs, perhaps we need to hold another contest entirely for them, although it is also getting to the point that by the time we’d finish such a competition, passwords which the average person can remember have too little entropy to survive even brute force on any practical PBKDF you’d want to run (bearing in mind that if it runs too slow it represents a potential point of DoS), and no asymmetric PBKDF can exist that resists offline attacks.
It might also be worthwhile to hold a contest to define a tweakable block cipher and define more modes based on that, and perhaps that would be an interesting way forward.
1. Re:Before "too fast = bad" by Anonymous Coward · 2012-12-25 08:39 · Score: 0
  
  Iâ(TM)m still not seeing anything that makes this better than Skein, however, which is very fast in software, can perform signature pinned and keyed hashes and rounds (which could be used to make a PBKDF of arbitary strength), and even has a built-in tree hash function, and parallelises well.
  BLAKE2 is faster than Skein. BLAKE and Skein is mostly neck-and-neck, and BLAKE2 does some tweaks to make it faster, most importantly reducing the number of rounds by about one fourth. (16 to 12 rounds, and 14 to 10)
  They also define a tree hash mode, and an increased-parallelism version.
  It's not a bad specification, but the decreased round number does reduce the security margin. The authors claim that it is still comfortable, but I'll wait to hear what other cryptographers have to say on that.
  It is also very configurable, which lets you tune it for your internal use case, but can be a disadvantage to implementations and standard specifications.
2. Re:Before "too fast = bad" by TechyImmigrant · 2012-12-25 10:24 · Score: 2
  
  > the NSA value hardware speed far more than software speed
  I don't think this is true for NIST though. Witness the results of the SHA competition. Keccak sucks in hardware compared to Skein. Skein is lovely to implement in hardware. Ultimately the sponge construction is what won it.
  They certainly ignored my advice on hardware implementation.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
3. Re:Before "too fast = bad" by Anonymous Coward · 2012-12-25 11:00 · Score: 0
  
  Keccak sucks in hardware compared to Skein. Skein is lovely to implement in hardware.
  I think you are misremembering something here. Keccak was definitely one of the best performers in hardware. Groestl also did well, IIRC. BLAKE was a decent all-rounder. Skein never did well in the performance-per-area metric, neither for FPGA nor ASIC.
  I can't at the top of my head remember how JH did, but hopefully better than in software.
4. Re:Before "too fast = bad" by TechyImmigrant · 2012-12-25 12:26 · Score: 3, Insightful
  
  The issue is not so much how small and fast you can make one instance of the algorithm, but rather, how it scales from small/slow to fast/big. An algorithm like a hash or block cipher gets baked into many silicon contexts, like instructions, or memory datapaths, or offload processors, or IO datapaths. The size/speed/power requirements of these different contexts varies.
  Keccek is harder to divide down into smaller execution chunks in hardware than skein.
  Skein has an add-xor core operation that is repeated width-wise and depth-wise. So you can easily scale it in width, depth and pipeline depth in order to meet the needs of the situation.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Re:Famous last words by Desler · 2012-12-25 08:02 · Score: 1

Faster is good for plenty of applications of hashes such as checksums on data.
Fastest Encryption by Anonymous Coward · 2012-12-25 09:13 · Score: 0

Is this: source_byte_to_encrypt XOR some_random_byte.
1. Re:Fastest Encryption by TechyImmigrant · 2012-12-25 10:26 · Score: 1
  
  > [Fastest Encryption] Is this: source_byte_to_encrypt XOR some_random_byte.
  No it isn't. The complex part is the generation of 'some_random_byte'. Check out SP800-90A,B & C. Those are not efficient algorithms.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
The SW speed of BlakeX is moot by TechyImmigrant · 2012-12-25 09:49 · Score: 3, Interesting

The software speed of the SHA algorithms is somewhat moot in the medium terms because over the medium term, crypto primitives (encryption, hashing, RNGs etc) are moving to hardware and moving to an instruction model instead of a device+device_driver model.
So the hardware implementations available to software through instructions will be faster than software implementations and have much better security properties in terms of attack surface and side channels. Modern crypto tends to fall to side channels and implementation error before it falls to crypto attacks and hardware is the best place to solve these problems.
At the recent NIST RBG Workshop http://www.nist.gov/itl/csd/ct/rbg_workshop2012.cfm
I presented a short talk on where Intel is going. http://csrc.nist.gov/groups/ST/rbg_workshop_2012/johnston.pdf
Basically, we've started putting standards based crypto primitives in hardware, on the CPU die, presented through the instruction interface (E.G. AES-NI, RdRand, RdSeed) to provide for more secure crypto on PCs. This is our publicly stated intent going forward. So who cares how many cycles it takes when there's a constant time instruction available that is faster?

--
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
1. Re:The SW speed of BlakeX is moot by Anonymous Coward · 2012-12-25 10:22 · Score: 0
  
  The problem is cryptographic algorithms get broken. Ever heard of SHA0? Turns out they found a problem at the last minute and SHA0 never got much use, instead the 160-bit hash that got a lot of use was SHA1. Once you've got one of these in hardware, you can't accommodate changes. Cryptographic algorithms seem a good fit for GPUs, since they can be readily reprogrammed and (symmetric) cryptographic algorithms tend not to be too complex.
2. Re:The SW speed of BlakeX is moot by TechyImmigrant · 2012-12-25 12:19 · Score: 1
  
  Yes, but the NIST competition method to define new algorithms that yielded AES and SHA3 seems to have focused more attention on the algorithms, so the odds of them being broken is reduced. SHA-0 and SHA-1 were essentially handed to the world on a plate, with little outside analysis.
  So I have greater confidence in AES and SHA-3 that I did in the older algorithms. Hence me pushing to put such algorithms into CPU silicon.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
3. Re:The SW speed of BlakeX is moot by Anonymous Coward · 2012-12-27 01:40 · Score: 0
  
  If/when we get hardware instructions on all relevant platforms(which includes ARM smartphones for me) that improve the performance of SHA-3 beyond that of Blake2, then Blake2 has essentially become useless.
  But I expect that to take at least a decade, since my impression is that, unlike AES, Keccak doesn't lend itself to accelerating instructions.
  Do you know of any plans to add SHA-3 related instructions, or how SHA-3 could be accelerated?
4. Re:The SW speed of BlakeX is moot by Anonymous Coward · 2012-12-27 04:00 · Score: 0
  
  Don't forget that the SHA3 applicants finalists were tweaked versions of already well known algorithms. This dramatically increases confidence.
5. Re:The SW speed of BlakeX is moot by TechyImmigrant · 2012-12-27 04:50 · Score: 1
  
  Sorry, I can't say more that I said in the NIST slides.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
fix the font! by Anonymous Coward · 2012-12-25 13:08 · Score: 0

Hey, Slashdot! Could you fix the formatting? I mean, I zoom pages because 8CPI is too small, but I can't zoom in on it.slashdot.org - you must have specified the font in a way that prevents zoom. This happens with all browsers I've tried (Fx, Sf, IE, Chrome). And it's really annoying
Faster is not better.... by gweihir · 2012-12-25 15:58 · Score: 0

Faster also means faster to attack. Also, there is absolutely no need for faster crypto-hashes at this time, the available ones are quite fast enough.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Re:cool by Taco+Cowboy · 2012-12-25 18:22 · Score: 1

According to wikipedia's page on the NISH-sponsored competition - @
http://en.wikipedia.org/wiki/NIST_hash_function_competition
- one of the criteria of the elimination of potential candidates was ...

Security: "We preferred to be conservative about security, and in some cases did not select algorithms with exceptional performance, largely because something about them made us 'nervous,' even though we knew of no clear attack against the full algorithm."

Would the clause above invalidate Blake2??

--
Muchas Gracias, Señor Edward Snowden !
Why encrypt? by PacRim+Jim · 2012-12-25 19:14 · Score: 1

It occurs to me that, under certain circumstances, encryption might be unnecessary. An eavesdropper expected encrypted text might be skeptical of brazenly published open text. Hiding in plain sight, so to speak.
Was there ever an issue with SHA's speed? by Anonymous Coward · 2012-12-25 23:23 · Score: 0

#1) Was there ever an issue with the lightening fast speed of SHA? I never once ever thought... "gee... this instant SHA function is so slow!" Never.
#2) Is BLAKE just as secure? Only time can tell. I'm sure not going to risk security over "speed hype" of fractions of fractions of a fraction of a millisecond. No way.
1. Re:Was there ever an issue with SHA's speed? by Anonymous Coward · 2012-12-27 04:08 · Score: 0
  
  New SSDs are getting up into the 500MB+ ranges, should be breaking past 1GB/s in the near future, and hashing algorithms are stuck around 150MB/s pegging a single core on a modern CPU.
  
  1) Was there an issue with the 8086? I never once thought "gee.. this instant addition function is so slow!" Never.
  
  When it comes to computing, faster is ALWAYS better. Let security be handled by math that makes it near impossible to break with the limitations of our Universe.
Zen .. by Anonymous Coward · 2012-12-26 01:18 · Score: 0

i always preferred BLAKES 7 myself ...
Re:cool by GameboyRMH · 2012-12-26 01:54 · Score: 1

Wow how scientific of them |:-|

--
"When information is power, privacy is freedom" - Jah-Wren Ryel
Software only? by martijn+hoekstra · 2012-12-26 22:56 · Score: 1

What about simplicity and performance for hardware implementations? Or is this meant as a software hash? TFA only gives software runtimes.
1. Re:Software only? by Anonymous Coward · 2012-12-27 02:05 · Score: 0
  
  In hardware Keccak is better than Blake. If you're interested in hardware implementations, you should look at papers talking about the Blake1 hardware properties. Blake is doing decently in hardware, but there is little reason to use it there since Keccak is better and standard.
  Blake2 aims at people who mainly care about software performance, because that's an area where Keccak is rather slow.
Re:cool by Anonymous Coward · 2012-12-27 01:28 · Score: 0

NIST eliminated certain unconventional algorithms despite them being fast. Not because they were fast. Blake on the other hand is rather standard, so this doesn't apply to it. With unconventional algorithms a sudden break through in analysis is more likely than for algorithms were similar algorithms were studied for decades.
At that time Blake1 had 14 and 10 rounds. The number of rounds was only increased to 16 and 14 for the last round of SHA-3 to increase the security margin, and not because there was any attack that came near 14 and 10 rounds. Blake2 is Blake1 with some minor tweaks and the number of rounds set to 12 and 10.
So Blake2 certainly has a smaller security margin than Blake1, but the margin is still pretty large.