4 ms·

My takeaway from this post kind of is that there are probably too many variants and derivatives of SHA-3. Then again, these days normal developers should probab

My takeaway from this post kind of is that there are probably too many variants and derivatives of SHA-3. Then again, these days normal developers should probably use some recommended interface of mature crypto libraries anyway and shouldn't play around with cryptographic primitives directly, so maybe more choice for the library devs is good.

baby 9y ago
Yeah all these discussions are rather aimed at people who implement cryptography or have to make a well-thought hash choice at some point. As a developer you should use something like libsodium that has a default "hash" API. Underneath, the developers made the choice of choosing Blake2, but this is transparent to the user of the library. If you do not have access to high level libraries like that, and don't want to loose time/dig too much into the topic, following standards (SHA-3) is easy.
paulddraper 9y ago
> some recommended interface of mature crypto libraries Maybe for bubble code it'd be okay to just say "gimma a hash". But most real code needs to interoperate with stuff. E.g. I need to send a SHA-256 from a JS client to a Python server. So there needs to be a consistent and portable "SHA-256" concept that everyone understands. A cryptographic hash is not a complicated concept (even if developing one is). I suppose you can think about whether you require collision resistance or merely second pre-image resistance, but the popular ones are all intended to be collision resistant anyway.
- mikepurvis 9y ago
  The interop situation with the CRC family of hash functions is terrible. Check this madness out: https://bitbucket.org/martin_scharrer/crccheck/src/default/crccheck/crc.py https://bitbucket.org/martin_scharrer/crccheck/src/default/c...
npscalar 9y ago
Yes and no. After all, these are just modes using Keccak (think, say, AES-CBC, AES-GCM all use AES), so the choice depends more on the purpose than anything else. But indeed, the naming is confusing. Instead of SHA3-256, SHAKE256, KMAC256 and ParallelHash256, maybe they should have better named them SHA-3-hash256, SHA-3-xof256, SHA-3-mac256 and SHA-3-parallel256 (or so).

baby 9y ago

Yeah all these discussions are rather aimed at people who implement cryptography or have to make a well-thought hash choice at some point. As a developer you should use something like libsodium that has a default "hash" API. Underneath, the developers made the choice of choosing Blake2, but this is transparent to the user of the library. If you do not have access to high level libraries like that, and don't want to loose time/dig too much into the topic, following standards (SHA-3) is easy.

paulddraper 9y ago

> some recommended interface of mature crypto libraries Maybe for bubble code it'd be okay to just say "gimma a hash". But most real code needs to interoperate with stuff. E.g. I need to send a SHA-256 from a JS client to a Python server. So there needs to be a consistent and portable "SHA-256" concept that everyone understands. A cryptographic hash is not a complicated concept (even if developing one is). I suppose you can think about whether you require collision resistance or merely second pre-image resistance, but the popular ones are all intended to be collision resistant anyway.

mikepurvis 9y ago
The interop situation with the CRC family of hash functions is terrible. Check this madness out: https://bitbucket.org/martin_scharrer/crccheck/src/default/crccheck/crc.py https://bitbucket.org/martin_scharrer/crccheck/src/default/c...

npscalar 9y ago

Yes and no. After all, these are just modes using Keccak (think, say, AES-CBC, AES-GCM all use AES), so the choice depends more on the purpose than anything else. But indeed, the naming is confusing. Instead of SHA3-256, SHAKE256, KMAC256 and ParallelHash256, maybe they should have better named them SHA-3-hash256, SHA-3-xof256, SHA-3-mac256 and SHA-3-parallel256 (or so).