Ah, didn't know he also worked on it. It wasn't obvious in the article.
Then I have two basic questions (for either you and tptacek):
1) Given I just need to hash the contents of a file for content-addressed data (like in git), it seemed like sha2-256 would be sufficient. However, it seemed like on 64-bit machines, sha2-512 is faster, and I can just lop off the first 256 bits. Is that correct? And in what cases would you use sha3-256/sha3-512?
2) Given I need to build an API that authenticates through client tokens, I was thinking of using JWT (json web tokens) with HMAC256, and a payload with a randomly generated token for the at_hash claim, and send it over TLS. Do I need to include a nonce in the payload? If not, it's the same JWT on every client request. If so, how would you recommend generating a nonce?
In the article, under symmetric signatures, you talk about not doing anything complicated with the data you feed into the HMAC. But I'm not sure what the simple construction of this data is. Is it where you say "just concatenate the key and data and hash them and be secure"?
1) Yes, use SHA512/256 (truncated SHA512). I don't think I'd default to SHA3 anywhere.
2) Are you entirely convinced you actually need client tokens? In particular, can you get away with a 256-bit random token and store the session in a database?
3) Re: HMAC input malleability: yep, concat and HMAC is fine. Serializing JSON or whatever is also fine. You're usually providing the tag (that's what the output of HMAC is called) verbatim next to the message, so you generally don't care about e.g. canonical serialization.
2) Hrm. I guess maybe? As I understand it, the reason for a client token is to have stateless servers, so the server doesn't need to look up a valid token upon every request--which scales better. In my case, the API endpoint is for something that doesn't (and won't) get a lot of traffic, so I can probably get away with a 256-bit random token over TLS? Since it's over TLS, there probably aren't MITM attacks to sniff the token and replaying it--so it's probably ok? Are there other considerations I'm not aware of?
It's not always a foregone conclusion that it scales better. I've seen people argue that when using ECDSA verification that's 4x longer than an in-DC RTT. Usually: DB kv lookups aren't even close to the most expensive thing your app does.
Generally: don't do encrypted tokens. If you must: don't do JWT for this. Just secretbox a thing and be done with it, or use PASETO[0].
A lot of the implementations _aren't even faster_, but the laundry list of security bugs they have caused is very real. Suddenly you get to worry about irrevocable tokens in order to solve scaling problems you don't have.
> However, it seemed like on 64-bit machines, sha2-512 is faster, and I can just lop off the first 256 bits.
Just as a heads-up, SHA-512/256 isn't exactly just SHA-512 with 256 bits chopped off. It also uses a unique IV. This might not be a big difference in practice, but I'd lean toward using SHA-512/256 explicitly, and not SHA-512 truncated to 256 bits.
Then I have two basic questions (for either you and tptacek):
1) Given I just need to hash the contents of a file for content-addressed data (like in git), it seemed like sha2-256 would be sufficient. However, it seemed like on 64-bit machines, sha2-512 is faster, and I can just lop off the first 256 bits. Is that correct? And in what cases would you use sha3-256/sha3-512?
2) Given I need to build an API that authenticates through client tokens, I was thinking of using JWT (json web tokens) with HMAC256, and a payload with a randomly generated token for the at_hash claim, and send it over TLS. Do I need to include a nonce in the payload? If not, it's the same JWT on every client request. If so, how would you recommend generating a nonce?
In the article, under symmetric signatures, you talk about not doing anything complicated with the data you feed into the HMAC. But I'm not sure what the simple construction of this data is. Is it where you say "just concatenate the key and data and hash them and be secure"?