Over the past year and a half I've had it drummed into me that fast hashing is bad and slow hashing is good. If this is so, why have they optimised this new hashing algorithm to be as fast as possible?
BLAKE2, an improved version of the SHA-3 finalist BLAKE optimized for speed
21–30 of 34 posts
Re: BLAKE2, an improved version of the SHA-3 finalist BLAKE optimized for speed
#22Over the past year and a half I've had it drummed into me that fast hashing is bad and slow hashing is good. If this is so, why have they optimised this new hashing algorithm to be as fast as possible?
fast hashing is bad for storing one way functions of passwords because it makes them easier to attack and make many guesses about the original value from the transformed value, hence all the noise about using slow "key derivation functions" instead. for all other common use cases, faster is better, all else equal.
Re: BLAKE2, an improved version of the SHA-3 finalist BLAKE optimized for speed
#23Over the past year and a half I've had it drummed into me that fast hashing is bad and slow hashing is good. If this is so, why have they optimised this new hashing algorithm to be as fast as possible?
Slow hashing is usually bad, except for password-derivation functions.
Re: BLAKE2, an improved version of the SHA-3 finalist BLAKE optimized for speed
#24Over the past year and a half I've had it drummed into me that fast hashing is bad and slow hashing is good. If this is so, why have they optimised this new hashing algorithm to be as fast as possible?
Password hashes and general-purpose crypto hashes are not the same thing. If it helps, try using the technical term for the kinds of functions cryptography offers for password hashing: key derivation functions (KDFs).
Re: BLAKE2, an improved version of the SHA-3 finalist BLAKE optimized for speed
#25Earlier quoted context omitted.
That doesn't really apply to memory use on the order of a single kilobyte. You're not going to be hashing many different streams at once.
And why not? Ever considered a busy SSL offload device or VPN appliance? A kilobyte here, a kilobyte there, and pretty soon you're talking real memory!
I think something handling a TCP stream has better things to worry about than an extra buffer smaller than a single packet.
Re: BLAKE2, an improved version of the SHA-3 finalist BLAKE optimized for speed
#26I'm not sure how reduced memory requirements are a benefit to encryption. Are there really any low end systems still in use today that actually have issues with memory usage? Even $150 notebooks come with 1 gig of ram. This seems more like it would help save ram on interception devices like the Narus Device or the huge datacenters owned by the NSA, which have a huge issue with storing all the data required to interce…
> Even $150 notebooks come with 1 gig of ram.
The issue is with the processor's cache memory, which is small, typically 64 kiB or so. (The TLB cache is also important.) Even a few hundred bytes savings can give an important improvement in speed amd power consumption.
Re: BLAKE2, an improved version of the SHA-3 finalist BLAKE optimized for speed
#27Earlier quoted context omitted.
And why not? Ever considered a busy SSL offload device or VPN appliance? A kilobyte here, a kilobyte there, and pretty soon you're talking real memory!
I think something handling a TCP stream has better things to worry about than an extra buffer smaller than a single packet.
Well, you're wrong, at least for a specific segment of hardware and software on the market. The size of a packet is not related to the acceptable per-connection overhead. Some network devices like ASIC-accelerated routers can't handle any per-connection state.
If you don't believe me, hop on any kernel development mailing list and try to convince them they could solve world hunger by only adding 1 KB overhead to the TCP socket structure that tracks actve connection states.
Re: BLAKE2, an improved version of the SHA-3 finalist BLAKE optimized for speed
#28Over the past year and a half I've had it drummed into me that fast hashing is bad and slow hashing is good. If this is so, why have they optimised this new hashing algorithm to be as fast as possible?
Password hashes and general-purpose crypto hashes are not the same thing. If it helps, try using the technical term for the kinds of functions cryptography offers for password hashing: key derivation functions (KDFs).
Hey, that was supposed to be my line!
Re: BLAKE2, an improved version of the SHA-3 finalist BLAKE optimized for speed
#29Over the past year and a half I've had it drummed into me that fast hashing is bad and slow hashing is good. If this is so, why have they optimised this new hashing algorithm to be as fast as possible?
To expand on what has already been noted: a good place for fast hashing is when you're using hashing millions of objects. For example, if I wanted to parse thousands of feeds and store items using a unique hash as their key, I'd want a fast hash that's collision resistant (for the uniqueness part) and one that's fast (for the millions of objects). With password hashing (KDFs, as tptacek noted), the collision resistance is useful, but we want to keep it fairly slow to avoid being able to brute force attacks.
Re: BLAKE2, an improved version of the SHA-3 finalist BLAKE optimized for speed
#30I'm not sure how reduced memory requirements are a benefit to encryption. Are there really any low end systems still in use today that actually have issues with memory usage? Even $150 notebooks come with 1 gig of ram. This seems more like it would help save ram on interception devices like the Narus Device or the huge datacenters owned by the NSA, which have a huge issue with storing all the data required to interce…
Think smart cards.
Or RFID. If you actually want to build secure RFID devices, you need really low-power crypto.