| HN Mirror

notfed 630 days ago

I'd also throw in that HMAC is overrated. It's a workaround for bad hash algorithms that are vulnerable to length-extension attacks.

If you're using a "good" hash algorithm, then MAC-ing is simple: hash over your key and message.

It's pretty weird that SHA-256 has been king for so long, when SHA-512/256 (which, as I've noticed people don't understand, means SHA-512 truncated to 256 bits) was there from the beginning and is immune from this attack.

Anyway, in general it's a pet peeve of mine that many people so often say "HMAC" when really they just mean MAC.

skrebbel 630 days ago

> It's pretty weird that SHA-256 has been king for so long, when SHA-512/256 (which, as I've noticed people don't understand, means SHA-512 truncated to 256 bits) was there from the beginning and is immune from this attack.

A bit of a tangent, but I didn't know this, so thanks for pointing this out. It's insane to me that there's two SHA hash algorithms that result in a 256 bit string, named nearly identically, but the one is vulnerable to a length-extension attack but the other isn't. I had simply assumed that SHA-256 and SHA-512 are the exact same thing except the length of the result. Wouldn't anyone? The length of the result is right there in the name! I mean why does SHA-256 even exist when SHA-512/256 is what we should all use? Why does a single library implement an algorithm that everybody in crypto land, apparently (if you're right), already knew was broken from the start? Give the good one the short name and keep the bad one out of codebases! Come on! Crypto is hard but crypto people keep making it harder and I hate it.

dspillett 630 days ago

> why does SHA-256 even exist when SHA-512/256 is what we should all use?

SHA-512 is more computationally costly so running that and truncating the result is slower than just running SHA-256. Where performance is key¹ and you have other protection in your protocol that mitigates extension issues, that could be a significant benefit.

IIRC SHA512 used 64-bit values throughout rather than 32 as used in SHA256, so it might actually be faster on software on modern 64-bit architectures, nullifying the above consideration on such platforms, but back when the SHA2 family were formally specified 64-bit processing was far far less common. Also if you have acceleration for SHA256 in hardware but not 512 that flips things back. Hardware support for SHA256 will be cheaper in silicon than SHA512.

----

[1] very low CPU power systems, or hashing en-mass on now powerful arrangements

NovemberWhiskey 630 days ago

>SHA-512 is more computationally costly

In fact, as you suggested later, SHA-512 is actually much less computationally expensive on 64 bit machines - it has 25% more rounds, but you can do twice the number of bytes per round.

All other things being equal (which they seldom are), you will often see a significant speed improvement with SHA-512 vs. SHA-256 on larger payloads.

Of course, I immediately tried to test this with "openssl speed" on my M1 Mac and SHA-512 is 70% slower, so I guess there's some architectural optimization there.

jaeckel 629 days ago

The answer is: dedicated CPU instructions for SHA256 vs. software implementation of SHA512. For amd64 there's SHA-NI, for Arm there's the crypto extensions, but both only provide sha256 (at least when I last looked at their specs)

mtndew4brkfst 630 days ago

Can the algorithm benefit from SIMD/AVX512? Not helpful for ARM Macs, I have one too, but might be a contributing factor to lower adoption since those instructions aren't as widespread. First consumer chips in ~2017 and first AMD chips in ~2022.

poincaredisk 630 days ago

Being "vulnerable" to hash length extension is not a problem for a hash function. It is a problem for a MAC, hence HMAC exists. People confuse both, so SHA-3 competition explicitly requested functions resistant against hash length extension. SHA-256 is a perfectly fine hash function.

And, I don't know how to say it, if you don't know what are the difference between SHA-256 and SHA-512/256 you shouldn't use either. Cryptography really is hard.

Keyed SHA-512/256 would be a design smell. Just use HMAC.

Yes and no. HMAC is very inefficient for short messages, but that inefficiency quickly vanishes into noise for anything over a kB or two. (HKDF and HMAC-DRBG are probably the worst offenders as they are always running HMAC on small inputs).

But, on the other hand, HMAC has repeatedly proven itself to be resilient to all kinds of attacks. I definitely didn’t mean any MAC when I recommended HMAC: eg I don’t think Poly1305 is a good general purpose MAC. PRF maybe, but sometimes you need the MAC to be committing too. Yes, some hash functions can be used with a simple prefix MAC, but then you need to list which specific hash functions to use (and most of those are not yet widely available).

You're pointing out that SOTA hashes like SHA3 and Blake2 aren't length-extendable, which is true, but KMAC is more than simply keyed SHA3; it's also domain-separated.

kccqzy 630 days ago

Ah yes of course in 2018 it's still HMAC.

https://www.latacora.com/blog/2024/07/29/crypto-right-answer...

JimDabell 630 days ago

They published a followup to that article two months ago, and the correct answer in 2024 is still HMAC.

Who's "they"? This "right answers" thing is a meme (I ruefully share responsibility for it) that needs to die; Colin Percival has nothing to do with anything but the first one.

loeg 629 days ago

I linked to the older Latacora one upthread and this comment is linking to the newer Latacora one. So I think it's reasonable to read "they" as "Latacora" here.

Yes, I wrote the older Latacora one, which was based on thing I wrote under my own name before I founded Latacora; I'm pretty sure I'm on solid ground saying Colin Percival had nothing to do with anything I wrote, since I wrote the first one as a rebuttal to Colin. (Did I misread you? Maybe we just agree.)

atoav 630 days ago

One question I always wondered about with cookie signing is: Why not store the user and the cookie in a database and check against that when they try to present it to you? Performance reasons?

argulane 630 days ago

It's mostly about performance. If you can store all the required info about the user inside the cookie then you can avoid a DB query roundtrip before sending a response.

Now that your cookie looks like this (probably also base64 encoded):

  {"id": 42, "display_name": "John", "is_admin": false, "session_end_at":1726819411}

You don't have to hit the DB to display "Hi John" to the user and hide the jucy "Admin" panel. Without HMAC, an attacker could flip the "is_admin" boolean in the cookie.

You could also create a cookie that is just random bytes

  F2x8V0hExbWNMhYMCUqtMrdpSNQb9dwiSiUBId6T3jg

and then store it in a DB table with similar info but now you would have to query that table for each request. For small sites it doesn't matter much and if it becomes a problem you can quite easily move that info into a faster key-value store like Redis. And when Redis also becomes too slow you are forced to move to JSON Web Tokens (JWT) witch is just a more standardized base64 encoded json wrapped with HMAC to avoid querying a database for each request.

But even if you are using random bytes as your session identifier, you should still wrap it in a HMAC so that you can drop invalid sessions early. Just for making it harder for someone to DDOS your DB.

kd5bjo 630 days ago

Back in the Justin.tv days, we used this for some messages that were passed by the client between two of our systems: The main authentication was done by the web stack which gave the client an HMAC-signed viewing authorization. That was then passed on to the video servers which knew how to check the authorization but weren’t hooked up to the main DB.

Setting things up this way meant that we didn’t need to muck about with the video server code whenever we made policy changes as well as isolating the video system from web stack failures— If the web servers or DB went down, no new viewers could start up a stream but anyone already watching could continue uninterrupted.

atoav 630 days ago

Thanks for the clear explaination, I suspected as much. Wasn't sure however if that was all there is to it.

Aachen 630 days ago

Premature optimisation. We have a diverse set of clients but of all the ones I've audited with JWT and similar crypto-solutions, not one (of those that used sessions at all, not like a CDN or so) could not have run on a single database server. Some more comfortably than others, but also embedded devices with a handful of users at most will use cryptographic sessions nowadays. Some also choose to pack a session cookie into the JWT data and now you've got two things to validate instead of one

I understand it's nice to never have to worry about it regardless of scale, but generating sessions with an established CSPRNG and being able to invalidate them at will is an order of magnitude simpler. It's also standard and abstracted away for you already if you use any framework

http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo...

dchest 630 days ago

Mostly incompetence.

http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-...

jeroenhd 630 days ago

This is how many (most?) session cookies work. Track the data on the backend, only send an identifier to the frontend.

The JWT and similar cookies exist for when you want to do scaling and such. You don't need much more than a user ID and a user name for many pages of a web application, your database may be in another continent, so you may as well store some variables in the client side. This has the added benefit of being able to put down as many frontends as you may need, integrating nicely with technologies like Kubernetes that can spawn more workers if the existing workers get overloaded.

By also encrypting the cookie, you can get rid of most of the backend state management, even for variables that should be hidden from the user, and simply decrypt+mutate+encrypt the cookie passed back and forth with every request, stuffing as many encrypted variables in there as can you can make fit.

They're also useful for signing in to other websites without the backend needing to do a bunch of callbacks. If a user of website A wants to authenticate with website B, and website B trusts website A, simply verifying the cookie with the public key (and a timestamp, maybe a n\_once, etc.) of website A can be enough to prove that the user is logged into website A. You can stuff that cookie into a GET request through a simple redirect, saving you the trouble of setting up security headers on both ends to permit cross-website cookie exchanges.

In most cases, signed cookies are kind of overkill. If all your application has is a single backend, a single database, and a single frontend, just use session cookies. This also helps protect against pitfalls in many common signed cookie variants and their frameworks.

Originally it was about scalability - signed/encrypted cookies are stateless, and hence (in theory) allow easy horizontal elastic scaling: just share the key with the new nodes. But I suspect that in a lot of cases now it is because it is easier initially to throw a key into an environment variable than standup a database, sort out caching, etc. It’s only later that you start thinking about revocation and idle timeouts and key rotation and all the other stuff that it becomes clear that it's not that simple to do well.

resonious 630 days ago

A bit of a tangent. This isn't a dig on HMAC itself, but using HTTP request body or query string as the HMAC "message" is the worst. My employer provides some APIs with that sort of scheme and it's a very common source of technical customer support tickets.

The problem is that many people are using web frameworks that automatically turn body and query into some kind of hash map data structure. So when you tell them "use the request body as the HMAC message", they go "OK, message = JSON.stringify(request.body)", and then it's up to fate whether or not their runtime produces the same exact same JSON as yours. Adding a "YOU MUST USE THE RAW REQUEST BODY" to the docs doesn't seem to work. We've even had customers outright refuse to do so after we ask them to do so in the "why are my verifications failing" ticket. And good luck if it's a large/enterprise customer. Get ready to have 2 different serialization routines: one for the general populous, and one for the very large customer that wrote their integration years ago and you only now found out that their runtime preserves "&" inside JSON strings but yours escapes it.

Rant over...

Elucalidavah 630 days ago

> "&" inside JSON strings but yours escapes it

What escaping of "&" inside JSON are you talking about? Some unholy mix of JSON and urlencode?

resonious 630 days ago

Ruby on Rails turns "&" into "\u0026".

See rails/rails, activesupport/lib/active_support/json/encoding.rb.

beeboobaa3 630 days ago

Shitty software developers will always find ways to screw things up unfortunately

growse 630 days ago

I think AWS SigV4 tries (and succeeds?) in solving this issue?

__MatrixMan__ 630 days ago

Are things like Diffie Hellman generally available such that you can always get a symmetric key? Or is that a special case?

[1]: https://www.latacora.com/blog/2024/07/29/crypto-right-answer... [2]: https://neilmadden.blog/2021/01/22/hybrid-encryption-and-the...

vogr 630 days ago

I'm no cryptographer, but I would say that it is indeed the case that you can assume that two parties can derive a shared key over an untrusted channel. The post Cryptography Right Answers PQ [1], linked in another comment, addresses this in the section "Key Exchange". Rather than thinking about Diffie-Hellman directly, you would turn to a Key Exchange Mechanism (KEM).

Before post-quantum cryptography concerns, KEM were indeed mostly built on top of Diffie-Hellman key agreement, but you could also build one on top of RSA, or on top of some lattice constructs. But you wouldn't build one yourself, there are good constructions to choose from! The OP actually has a 3-part series on KEMs, although I don't think it addresses post-quantum issues [2].

Just want to point out that the article specifically says to use an authenticated KEM (AKEM). A normal, unauthenticated KEM would not work as it provides no authentication. There are no post-quantum authenticated KEMs as yet.

namibj 629 days ago

There are post quantum KEMs though that authenticate with a classical mechanism, which limits quantum attacks to interactive from the previous total breakage of recorded ciphertext exchanges (e.g. Wireshark capture at a router encountered in both directions of the traffic flow).

nmadden 629 days ago

Are there? I’ve advocated for such constructions in the past, but I’ve never seen an actual proposal. Do you have a link?

namibj 621 days ago

Google's post-quantum TLS experiments that were done in public via Android Chrome are such; basically you just do normal TLS handshake but stack the key derivation from the traditional DH-type perfect-forward-secrecy exchange with a post-quantum-perfect-forward-secrecy exchange that you all seal under the same handshake authentication, and where you make sure to only use post quantum symmetric primitives to fuse the traditional session key material with the PQ session key material such that you don't rely on either one's resistance to keep your secrets secret.

Sorry I don't have a link quite on hand right now.

dfox 630 days ago

One thing to note about authentication in DH-like systems is that you can derive symmetric key without authenticating the parties, establish secure (but unauthenticated) channel with the resulting symmetric key(s) and the do authentication inside that channel in a way that will only succeed if the symmetric key used by both parties is the same (this is called channel binding). For example SSH2 and many Active Directory related protocols do this.

ramchip 630 days ago

DH + HMAC on its own doesn't give you authentication, anyone can establish a symmetric key. It's possible to build authentication on top but it requires pre-shared data or PKI.

The way DH is used typically for encryption (ECIES) or in TLS doesn’t give you authentication. But you can get authentication from DH alone, without PSK or PKI. See https://neilmadden.blog/2021/04/08/from-kems-to-protocols/ for some details on the security properties of various types of DH.

ramchip 630 days ago

I meant that some data still needs to be distributed securely, just it's the sender's public key rather than a PSK. I recon "pre-shared data" was not the best choice of words...

(Still love the blog post!)

Ok, makes sense.

Yeah, if you have a shared secret, HMAC is the way to go.

It's also super simple: It's almost literally just concatenating the secret and the message you want to authenticate together, and take an ordinary hash (like SHA256) of that, the rest of it is just to deal with padding.

It's super intuitive how HMAC works: If you just mash secret and message together on your side, and get the same answer as what the other side told you, then you know that the other side had the secret key (and exactly this message), because there's obviously no way to go from SHA256 to the input.

HMAC is also useful if you want to derive new secret keys from other secret keys. Take an HMAC with the secret key and an arbitrary string, you get a new secret key. The other side can do the same thing. Here's the kicker, the arbitrary string does not have to be secret to anyone, it can be completely public!

Why would you do that? Well, maybe you want the derived key to have a different lifetime and scope. A "less trusted" component could be given this derived key to do its job without having to know the super-secret key it was derived from (which could be used to derive other keys for other components, or directly HMAC or decrypt other stuff).

loeg 630 days ago

> It's also super simple: It's almost literally just concatenating the secret and the message you want to authenticate together, and take an ordinary hash (like SHA256) of that, the rest of it is just to deal with padding.

It's not quite as simple as that. The output of the first hash is hashed a second time (to prevent length extension attacks).

anyfoo 630 days ago

Thanks, forgot to mention that. Needless to say, I always consult real cryptographers when working on stuff like that.

loeg 630 days ago

Do you ever need to implement an HMAC from scratch? I'd look for an off-the-shelf solution before trying to find a cryptographer.

anyfoo 624 days ago

I don't, and I absolutely did not mean to imply that anyone should implement HMAC themselves. I was addressing people who want to potentially use HMAC (after proper consultation with cryptographers), for which a general understanding of HMAC is prerequisite. Hence why my original comment only described implementation on a surface level, but elaborated over potential uses for HMAC.

Only cryptographers should implement crypto primitives. Even if I'd get the algorithm itself right, I might not know how to make it so that it runs in constant time (which is something that crosses into the CPU's ability to do so), and thus may inadvertently leak secrets through side channels.

But even if I just use HMAC, I still consult with cryptographers to make sure my use is correct, that there is no better solution, and that I am not missing any attack vectors.

Even in simple cases it can be a grave mistake to use seemingly simple crypto primitives without proper consultation, see for example some of the very prominent problems that were the result of improper IV usage with AES.

arianvanp 630 days ago

And this is is why I have come to love AWS Sigv4