6 ms·
> Just do hmac-sha256(data, secret) instead Or use SHA3(secret || data), it was specifically designed to not have the pitfalls of sha2 which made HMAC construc
by BelenusMordred 5y ago
> Just do hmac-sha256(data, secret) instead
Or use SHA3(secret || data), it was specifically designed to not have the pitfalls of sha2 which made HMAC constructions necessary along with being less computationally expensive. There's also KMAC built from keccak which has some advantages over simply hashing the concatenated key and message.
https://csrc.nist.gov/publications/detail/sp/800-185/final https://csrc.nist.gov/publications/detail/sp/800-185/final
https://crypto.stackexchange.com/questions/17735/is-hmac-needed-for-a-sha-3-based-mac https://crypto.stackexchange.com/questions/17735/is-hmac-nee...
- josephg 5y agoA friendly reminder for the 99% of people here who, like me, don’t live and breathe this stuff: Don’t “just” use some crypto construction you read on HN. Don’t invent your own thing. Find a well respected crypto library (eg libsodium) and look up your use case in the API documentation. Eg, for authentication libsodium exposes these API methods: https://libsodium.gitbook.io/doc/secret-key_cryptography/secret-key_authentication https://libsodium.gitbook.io/doc/secret-key_cryptography/sec...
- chupasaurus 5y agoThat's why Cryptographic Right Answers [0] is a thing. [0] https://latacora.singles/2018/04/03/cryptographic-right-answers.html https://latacora.singles/2018/04/03/cryptographic-right-answ...
- tialaramex 5y agoAs that version of the post alludes to (in talking about D-H) the problem is that the people who most need these answers don't know how to ask their question in a suitable way. The NaCl/ Sodium APIs are oriented around applications. You want to do X, Sodium says you should call this API and the things you get back have the following properties. For example, what Sodium will actually do for the API your parent mentioned is HMAC-SHA512-256 ie it's using SHA512/256. But rather than give that as advice (and risk some developer either trying to re-implement SHA512/256 because their tool doesn't offer it, or worse, thinking SHA512 sounds strictly better so they'll do that) - Sodium just implements the thing you should do. But if I were going to write a snarky "Right Answers" type post about this subject what it would say is that JWT almost certainly isn't the solution to a problem you have, it might be a solution to a problem you wish you had, but you likely have actual problems, now, and you should work on those. Why do I say "wish" you had? Well as we see in a lot of these threads, immediately people talk about how it'll be a struggle to scale up the naive session approach when you have this big geographically distributed system. If your startup becomes Facebook or Google, you'll have to rewrite all this stuff. Why not instead use JWTs? Your startup isn't going to be Facebook or Google. When you prove me wrong you'll have piles of cash for engineers to fix the scaling problems you knew about and, much more importantly, all the other problems you'd never dreamed of. You are attempting premature optimisation.
- Redoubts 5y ago“”” Asymmetric encryption Percival, 2009: Use RSAES-OAEP with SHA256 and MGF1+SHA256 bzzrt pop ffssssssst exponent 65537. “”” Am I having a stroke?
- BelenusMordred 5y agoI provided a link to a NIST spec on this exact issue and a stackexchange discussion with lots of eyeballs/votes. Sure, don't just listen to me, but please do listen to them. Using sha3 as stated above is certainly something to consider for the numerous people out there implementing message authentication into their systems. It's simple and hard to mess up, if I was building a greenfields project today is probably the tool I'd reach for. Libsodium is fairly complex and had it's own issues. Sha3 implementations in most languages are battle-hardened and simple to use.