5 ms·

Do you also agree with the recommendations given in the article in 2018?

by iamwil 9y ago

lvh 9y ago
I might be misunderstanding you, but... 'tptacek and I worked on the 2018 recommendations in the article, and I think we still agree with what we said last week when we edited it :-)
- iamwil 9y ago
  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"?
  - lvh 9y ago
    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.
    - iamwil 9y ago
      1) Huh. Weird it exists at all then. 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?
      - lvh 9y ago
        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]. [0]: https://github.com/paragonie/paseto https://github.com/paragonie/paseto
        iamwil 9y ago
        By secretbox, I assume you mean NaCl's secretbox. Cool, thanks for the tips, and helping make the web a more cryptographically secure place.
        ketralnis 9y ago
        > Generally: don't do encrypted tokens Can you point to a RTFM on why not? I'm sure it's a big list of reasons but where can I read about the biggest one?
        lvh 9y ago
        Because they cause more problems than they solve. 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. A good intro is: http://cryto.net/~joepie91/blog/attachments/jwt-flowchart.png http://cryto.net/~joepie91/blog/attachments/jwt-flowchart.pn...
  - stouset 9y ago
    > 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.

Do you also agree with the recommendations given in the article in 2018?

by iamwil 9y ago

Do you also agree with the recommendations given in the article in 2018?

lvh 9y ago

I might be misunderstanding you, but... 'tptacek and I worked on the 2018 recommendations in the article, and I think we still agree with what we said last week when we edited it :-)

iamwil 9y ago
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"?
- lvh 9y ago
  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.
  - iamwil 9y ago
    1) Huh. Weird it exists at all then. 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?
    - lvh 9y ago
      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]. [0]: https://github.com/paragonie/paseto https://github.com/paragonie/paseto
      - iamwil 9y ago
        By secretbox, I assume you mean NaCl's secretbox. Cool, thanks for the tips, and helping make the web a more cryptographically secure place.
      - ketralnis 9y ago
        > Generally: don't do encrypted tokens Can you point to a RTFM on why not? I'm sure it's a big list of reasons but where can I read about the biggest one?
        lvh 9y ago
        Because they cause more problems than they solve. 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. A good intro is: http://cryto.net/~joepie91/blog/attachments/jwt-flowchart.png http://cryto.net/~joepie91/blog/attachments/jwt-flowchart.pn...
- stouset 9y ago
  > 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.