SHA-2 isn't outdated if used correctly (e.g. combine with HMAC if length extension attacks are a threat to your protocol). SHA-3 is the "break glass in case of emergency" hash.

Doesn't even need HMAC to break length extension. You can just truncate the result ("SHA-512/256"), or use SHA_d(x) = SHA(SHA(x)) or SHA(0^B || SHA(x)). (Although SHA_d starts to look a lot like HMAC.)

Absolutely but it’s all besides the point for this particular application, anyway. If you fix the pointer size (e.g. payload (i.e. both the secure and raw pointers) must be 64 bits, no less, no more) then length extension is a non-issue.

(Rebuttal: Some languages have fat pointers or maybe some architectures support 32-bit binaries.. I think having the key tied to the payload size would address the theoretical weakness there? In practice signed pointers are already fat pointers and the contents of fat pointers are not actually addresses in the first place, and neither are supported in the current implementation.)

You are right, SHA2 is fine still, mostly.

But... Combining with HMAC isn’t exactly a seal of approval. HMAC with MD5 is still considered secure because even if you made a hash collision you didn’t have the key.

And yes, SHA3 would be overkill. Most people don’t understand the mechanics of hashing let alone the new keying that SHA3 brings.

AMD offers it across the board on models since Zen 1, which is probably what the article has in mind. It's nice that Intel offers it as an accelerator on their low-end parts, but ideally they would ship the support across the product range.

If you care about speed and are concerned about sha1/2 vulnerabilities, maybe take a look at blake2? Faster than sha1, probably a similar level of security as sha3 (it is a redesign of a finalist for sha3). It's also the default for nacl/sodium.

https://blake2.net/

Nope. ptrauth needs a good hash in Hardware. There's only crc32c, aes, sha1 (-160) and sha256 (i.e. sha2-256). Of these crc32c is entirely insecure, aes not applicable, so we are left with AMD, Intel laptops (Goldmont), armv8 and Power8. For sure we don't care about any SHA vulnerabilities here, only about speed.

Blake2 is about a factor of 1000 slower. Secure hashes are not really applicable for pointer hashing (i.e. 48bit). Some need 16byte alignment (but you can use a stack word for that), some need excessive padding. Here the padding will kill you.

SHA3 is designed to be quite fast in hardware, there just isn't much hardware that accelerates it yet. Blake2 is faster in software, but that software is (as you note) much slower than SHA2's hardware implementations. So for existing systems SHA2 is the best option. Eventually SHA3 will probably be widespread and SHAKE128 with appropriately chosen output size will be the best choice.

SHA2 is by far not the best option for ptrauth. The best option is HW and API dependant. There are dozens of better options. I recently included most secure hashes with tons of variants into https://github.com/rurban/smhasher/blob/master/README.md#smh... SHA3 would be atrocious. Something like fletcher2 or wyhash seem to be best.

Right. Pointer authentication depends on it not being easy to forge a signature given the desired pointer. Given that there's a secret key included in the signature, the requirements on the hash function aren't really very strong. Signatures just need to not leak information about the key that could be used to predict other signatures.