111–120 of 126 posts
Earlier quoted context omitted.
I assume MD5 is in there too now. Just out of curiosity, what are the most common use cases for non-cryptographic hash functions?
MD5 isn't particularly fast. Basic non-vector BLAKE3 beats it, and SHA1 beats it by even more.
So what are the next steps for cryptographic hash functions? Is it going to just be "make even faster" ? Or are we chasing new properties, or stronger guarantees (or hopes?) of existing properties?
An associative / non-commutative hash function over lists. This would mean that the hash of a list, H(list1), could be "concatenated" with another hash, H(list2), to find the hash of the concatenation and be equivalent to H(list1+list2). I think such a construction could be huge for cryptographic verification of data in data structures while avoiding baking in incidental details about the data structure itself. I hes…
Earlier quoted context omitted.
Aside from the various technical reasons others have given, I would like to say please have a look at the underlying design of SHA-3 - it’s really elegant, with so many applications beyond just hash functions. Ironically, I feel like SHA-3 should obsolete block ciphers like AES more than it obsoletes SHA-2. https://keccak.team/sponge_duplex.html
SHA-3 is extremely slow compared to common ciphers like AES and ChaCha20. Sponge functions might someday become the building blocks of symmetric ciphers, but it's unlikely that SHA-3 will (without hardware acceleration).
You can also look at things like the Strobe framework, which builds essentially all of its symmetric crypto out of the SHA-3 core permutation: https://strobe.sourceforge.io/
Earlier quoted context omitted.
MD5 isn't particularly fast. Basic non-vector BLAKE3 beats it, and SHA1 beats it by even more.
Yes, I'm already aware of that, thank you. Could you please expand upon what the main use cases are for non-cryptographic hashes?
Oh. Well you said "in there too now" so I thought you were saying it was like xxhash in being insecure and fast. Even if that wasn't your intent, I wanted to make it clear to other people.
> Could you please expand upon what the main use cases are for non-cryptographic hashes?
Very fast hashes are good for hash maps, or even critical for them. That covers a huge amount of uses. And judging by the list on xxhash's website, a bunch of file transfer programs use it as well as bloom filter implementations, along with the databases that are probably using it for various maps.
Earlier quoted context omitted.
Yes, I'm already aware of that, thank you. Could you please expand upon what the main use cases are for non-cryptographic hashes?
> Yes, I'm already aware of that, thank you. Oh. Well you said "in there too now" so I thought you were saying it was like xxhash in being insecure and fast. Even if that wasn't your intent, I wanted to make it clear to other people. > Could you please expand upon what the main use cases are for non-cryptographic hashes? Very fast hashes are good for hash maps, or even critical for them. That covers a huge amount of…
So what are the next steps for cryptographic hash functions? Is it going to just be "make even faster" ? Or are we chasing new properties, or stronger guarantees (or hopes?) of existing properties?
An associative / non-commutative hash function over lists. This would mean that the hash of a list, H(list1), could be "concatenated" with another hash, H(list2), to find the hash of the concatenation and be equivalent to H(list1+list2). I think such a construction could be huge for cryptographic verification of data in data structures while avoiding baking in incidental details about the data structure itself. I hes…
Earlier quoted context omitted.
It's weird terminology. highwayhash aims to be cryptographically secure for its problem domain. But it's designed by (afaik) non-cryptographers, has weird security claims (they gauge security from statistical tests) and hasn't (afaik) received any formal peer review; it can also be instantiated in sub-secure hash sizes. You shouldn't use it to protect secrets, beyond the kind of incident secrecy you'd ask from someth…
Without intending to endorse the wording, I suspect what's being communicated might be something related to the difficulty for an attacker to derail your system by cheaply predicting hashes. IIRC, the standard Java runtime HashMap implementation was susceptible to this at one point - an attacker could easily and cheaply force all values into only a few buckets. The idea being, you might not care about actual cryptogr…
One of my favorite aspects of the b3sum utility is that it has a --no-names flag: $ echo hi | b3sum --no-names 0b8b60248fad7ac6dfac221b7e01a8b91c772421a15b387dd1fb2d6a94aee438
I've noticed in my shells that when I do this I get the newline, so be wary of that if you are passing this hash around. I think echo -n should fix that on most platforms. I just tried your "hi" against https://connor4312.github.io/blake3/index.html and get hi/n - 0b8b60248fad7ac6dfac221b7e01a8b91c772421a15b387dd1fb2d6a94aee438 hi - 85052e9aab1b67b6622d94a08441b09fd5b7aca61ee360416d70de5da67d86ca
Earlier quoted context omitted.
Aside from the various technical reasons others have given, I would like to say please have a look at the underlying design of SHA-3 - it’s really elegant, with so many applications beyond just hash functions. Ironically, I feel like SHA-3 should obsolete block ciphers like AES more than it obsoletes SHA-2. https://keccak.team/sponge_duplex.html
SHA-3 is extremely slow compared to common ciphers like AES and ChaCha20. Sponge functions might someday become the building blocks of symmetric ciphers, but it's unlikely that SHA-3 will (without hardware acceleration).
Is this 1.0 ready indeed? a comment in blake3_neon.c: // TODO: This is probably incorrect for big-endian ARM. How should that work?
IMO, this shouldn't be a TODO. This should be an #error based on the standard C macros for detecting endianness at compile-time.