Has KangarooTwelve received more analysis than BLAKE2? Or are both recommendations morally equivalent in the context of standardization and confidence in security margins?
To be clear: I agree with Marc in general, but there are exceptions where I disagree with Marc's "only use {FIPS,NIST,etc.}-approved crypto":
* I prefer Ed25519 over foot-bullety ECDSA (i.e. before RFC 6979).
* I prefer to never use RSA at all.
* I prefer XChaCha20-Poly1305 over AES-GCM, since the former is always constant-time without requiring specialized hardware and you have a negligible chance of nonce misuse even after an absurd number of messages.
* I prefer Argon2id and scrypt over PBKDF2 for key stretching.
* I prefer Argon2id and bcrypt over PBKDF2 for password storage.
* I prefer BLAKE2 over SHA-256, especially when length extension attacks are within the threat model of the protocol being discussed. SHA3 is good. Most SHA2 hash functions are fine (as long as they're not being used stupidly). But BLAKE2 is not only faster, thanks to libsodium, it's more readily available to developers than SHA3 (which, like AES, is only performant with specialized hardware circuits in software that takes advantage of said circuits).
None of the algorithms I've mentioned above are random pet projects by hobbyists.
To resolve this impasse, what needs to happen is: Standards bodies (NIST, FIPS, ISO, etc.) need to stop digging their heels in on sunk-cost fallacies and give at least some of these algorithms a fair consideration. Then one of two things will follow:
1. They'll be found to be as secure as the cryptographers who have studied them already believe, and therefore appropriate for standardization.
2. New attacks will be found, and the state of the art can be moved forward.
And this trend of cryptography towards requiring specialized hardware to be fast and secure? I oppose it wholeheartedly.
To be clear: I agree with Marc in general, but there are exceptions where I disagree with Marc's "only use {FIPS,NIST,etc.}-approved crypto":
* I prefer Ed25519 over foot-bullety ECDSA (i.e. before RFC 6979).
* I prefer to never use RSA at all.
* I prefer XChaCha20-Poly1305 over AES-GCM, since the former is always constant-time without requiring specialized hardware and you have a negligible chance of nonce misuse even after an absurd number of messages.
* I prefer Argon2id and scrypt over PBKDF2 for key stretching.
* I prefer Argon2id and bcrypt over PBKDF2 for password storage.
* I prefer BLAKE2 over SHA-256, especially when length extension attacks are within the threat model of the protocol being discussed. SHA3 is good. Most SHA2 hash functions are fine (as long as they're not being used stupidly). But BLAKE2 is not only faster, thanks to libsodium, it's more readily available to developers than SHA3 (which, like AES, is only performant with specialized hardware circuits in software that takes advantage of said circuits).
None of the algorithms I've mentioned above are random pet projects by hobbyists.
To resolve this impasse, what needs to happen is: Standards bodies (NIST, FIPS, ISO, etc.) need to stop digging their heels in on sunk-cost fallacies and give at least some of these algorithms a fair consideration. Then one of two things will follow:
1. They'll be found to be as secure as the cryptographers who have studied them already believe, and therefore appropriate for standardization.
2. New attacks will be found, and the state of the art can be moved forward.
And this trend of cryptography towards requiring specialized hardware to be fast and secure? I oppose it wholeheartedly.