61–70 of 171 posts
Not really. It's even 2x slower than SHA256-NI, the builtin. b3sum is much faster than sha256sum, and blake3 is about 2x faster than blake2. http://rurban.github.io/smhasher/doc/table.html
Is it better in preventing hash collisions?
Compared to? MD2, MD4, MD5, SHA-1, etc.: There are collisions known, so yes. SHA-2, SHA-3, BLAKE2b, Skein, Whirlpool, etc.: We don't have any collisions for these, so it doesn't get any better than that.
There are important differences; some of those primitives are definitely more trustworthy than others.
SHA-2 and Whirlpool use the old Merkle–Damgård construction, which has fallen out of favor because of unfortunate properties.
They are vulnerable to length extension attacks, such that it can be misused. For instance, if you want to use it as a keyed hash, you cannot just do sha2(key + message) (where + is concatenation). You have to use something like HMAC for that.
Skein is much better, but has a bit of an aged design now, and an insane 72 rounds. It doesn’t have as much love as BLAKE2 for instance, which makes it unlikely that people will build things competitive with BLAKE3 with it.
SHA-3, BLAKE2b and BLAKE3 are the best. Like Skein, they are not vulnerable to length extension attacks, so they have a trivial keyed hash function construction.
SHA-3 in particular has an elegant new design, the Sponge construction, which yields precise cryptographic protections in terms of the number of bits of security. It has displaced Merkle–Damgård as The Way We Do Things™ now; many modern hashes use it, eg Gimli relied on it to make comparisons.
One of the great things about this form is that it makes it a XOF: you can make your hash as long as you desire. (BLAKE also shares this property, but with a different construction.)
However, SHA-3 is slow, so if you want speed, use BLAKE2b (or Kangaroo12) over SHA-3, and BLAKE3 over them both.
If you want to be conservative about security and don't care about speed, a safe bet is still SHA-512/256, which is safe against length extension attacks.
JP Aumasson just announced Blake3 at Real World Crypto a few days ago during the lightning talks. This was also right after he presented on "Too Much Crypto"[1] which argues that we use too many rounds in symmetric constructions: our security margins are too high and don't match any of the best "practical" attacks. We're too paranoid for our own good. He suggests reducing the number of rounds for a number of construc…
This seems a quite dangerous way of thinking. New attacks, methods to attack crypto are discovered regularly. A view years ago people also said SHA-1 will never get broken to the degree it just got broken a recently.
So the only think we can do is to be slightly paranoid, everything else would be strongly negligent.
Especially if we consider how long it often takes in practice to update software and phase out previous encryption and hash methods without having to worry about e.g. downgrade attacks or similar.
Sure software should be possible to be updated asap, but honestly how long will it take until SHA-1 is phased out?
EDIT: Through that also means if you believe you will always be able update the _deployed_ relevant parts of your software ASAP (which can't work for libraries) and you are sure that you will follow the crypto community close enough and you believe some one else does so to if you are unavailable because of sickness, then yes go ahead and use less paranoid/secure crypto.
Earlier quoted context omitted.
There is a comparison of Blake3 to various hash functions (including SHA-2 and SHA-3 families) on AWS c5.metal; see the chart here: https://github.com/BLAKE3-team/BLAKE3
Yes, and it didn't go unnoticed that KangarooTwelve (which - mind - does not belong to the SHA-3 family right now) is not included on that prominent comparison diagram, while it is considered in the BLAKE3 paper.
Earlier quoted context omitted.
No, Blake3 is a cryptographic hash algorithm, not for dictionaries or hash tables. It is intended for cryptographic signatures, file/data integrity, message authentication codes, etc. For dictionaries/hash tables you'd typically use a very fast hash algorithm like xxHash, murmurHash, etc. Those are tuned for speed but can have collisions (typically they have very short outputs - 32 or 64 bits - so that they're easy t…
In any situation where a hashcode is cacheable (which seems to me to cover all situations where a hashcode even makes sense) a cryptographic hash function might not be such a bad idea (especially if you're IO bound in any way). With a bad hash function you can end up with a high level of bucket utilisation, significantly reducing the efficiency of the structure. With user defined data there's even the possibility of…
Salting is the way to deal with these issues, and for hash tables it works well even if your hash function isn’t cryptographically secure. Hence, for hash tables, salt+fast hash function should be sufficient.
Earlier quoted context omitted.
In any situation where a hashcode is cacheable (which seems to me to cover all situations where a hashcode even makes sense) a cryptographic hash function might not be such a bad idea (especially if you're IO bound in any way). With a bad hash function you can end up with a high level of bucket utilisation, significantly reducing the efficiency of the structure. With user defined data there's even the possibility of…
Actually, a counter-point: there might be situations where you want an anti-cryptographic hash function - where similar inputs produce generally similar hashes. It could have some application as a preprocessing step in clustering (if it could be done efficiently).
JP Aumasson just announced Blake3 at Real World Crypto a few days ago during the lightning talks. This was also right after he presented on "Too Much Crypto"[1] which argues that we use too many rounds in symmetric constructions: our security margins are too high and don't match any of the best "practical" attacks. We're too paranoid for our own good. He suggests reducing the number of rounds for a number of construc…
> which argues that we use too many rounds in symmetric constructions: our security margins are too high and don't match any of the best "practical" attacks. We're too paranoid for our own good. He suggests reducing the number of rounds for a number of constructions like AES, SHA-3, Blake2, etc. This seems a quite dangerous way of thinking. New attacks, methods to attack crypto are discovered regularly. A view years…
We are not just securing ourselves, but our social network too. Something you do can be used to discredit your kids and grand-kids a long time from now.
JP Aumasson just announced Blake3 at Real World Crypto a few days ago during the lightning talks. This was also right after he presented on "Too Much Crypto"[1] which argues that we use too many rounds in symmetric constructions: our security margins are too high and don't match any of the best "practical" attacks. We're too paranoid for our own good. He suggests reducing the number of rounds for a number of construc…
> which argues that we use too many rounds in symmetric constructions: our security margins are too high and don't match any of the best "practical" attacks. We're too paranoid for our own good. He suggests reducing the number of rounds for a number of constructions like AES, SHA-3, Blake2, etc. This seems a quite dangerous way of thinking. New attacks, methods to attack crypto are discovered regularly. A view years…
It's not, really, because there is obviously some security margin that is too high. It makes a lot of sense to consider and try to quantify what that is. If all we have is some vague 'well, there are always new attacks' then how do we know the current margins are enough? Why not double the rounds, crank up the hash sizes, etc? It's not really a meaningful response to Aumasson's work.