Hi On 7/15/24 16:12, Rob Landers wrote:
This always gets me. "safer" doesn't have a consistent meaning. For
Yes it does. SHA-256 is safer than MD5. And on modern CPUs with sha_ni extensions, it's also faster. The following is on a Intel i7-1365U:
$ openssl speed md5 sha1 sha256 sha512 *snip* version: 3.0.10 built on: Wed Feb 21 10:45:39 2024 UTC options: bn(64,64) compiler: *snip* CPUINFO: OPENSSL_ia32cap=0x7ffaf3ffffebffff:0x98c027bc239c27eb The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes md5 114683.10k 286174.51k 550288.90k 715171.50k 783611.22k 788556.46k sha1 138578.57k 440607.38k 1082163.29k 1674088.45k 2017296.38k 2047377.41k sha256 150670.11k 460483.71k 1054829.57k 1553830.57k 1807897.94k 1823981.57k sha512 41246.76k 181566.07k 341457.66k 645468.50k 781042.81k 804296.02k
----
example, if you were to want to create a "content addressable address" using a hash and it needs to fit inside a 128 bit number (such as a GUID), you may be tempted to take SHA-X and just truncate it. However, this biases the resulting numbers, which this bias may
This is false. For a hash algorithm to be considered cryptographically secure (which I consider to be a reasonable definition of "safe"), it - among other properties - needs to have the "avalanche effect" property, which means that any change in the input is going to affect each output bit with 50% probability.
This means that for a cryptographic hash algorithm - such as the SHA-2 family - the resulting hash is indistinguishable from uniformly selected random bits. And this property also holds after truncation - you just have fewer bits of course.
See also: https://security.stackexchange.com/a/34797/21705
be considered unsafe (such as using it in an A/B testing tool). Just because you have a short hash, doesn't make it "unsafe" as longer hashes can also be considered "unsafe." What people usually mean by this is in the context of encryption, and in those cases it is unsafe, but in the context of non-encryption, usage of truncated larger hashes is just as unsafe.
I'm afraid I don't understand what you are attempting to say here. Best regards Tim Düsterhus
