Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Digital signatures and how to avoid them

neilmadden.blog

Post reply on HN
Print view View original

31–40 of 85 posts

Re: Digital signatures and how to avoid them

#31

Post by nmadden »

atoav wrote: post #22
kccqzy wrote: post #7

The author mentions HMAC at the end. I think HMAC is really an underrated technique. I remember reading Colin Percival's classic Cryptographic Right Answers [0] and saw a section about "symmetric signatures." I pondered to myself what scheme I could use for that before I looked at the answer: of course it's just HMAC. I feel like this is another perspective that ought to be more widely known: if you want something to…

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?

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.

Re: Digital signatures and how to avoid them

#32

Post by nmadden »

vogr wrote: post #25
__MatrixMan__ wrote: post #13

Earlier quoted context omitted.

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

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 w…

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.

Re: Digital signatures and how to avoid them

#33

Post by nmadden »

ramchip wrote: post #28
__MatrixMan__ wrote: post #13

Earlier quoted context omitted.

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

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.

Re: Digital signatures and how to avoid them

#34

Post by jeroenhd »

atoav wrote: post #22
kccqzy wrote: post #7

The author mentions HMAC at the end. I think HMAC is really an underrated technique. I remember reading Colin Percival's classic Cryptographic Right Answers [0] and saw a section about "symmetric signatures." I pondered to myself what scheme I could use for that before I looked at the answer: of course it's just HMAC. I feel like this is another perspective that ought to be more widely known: if you want something to…

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?

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.

Re: Digital signatures and how to avoid them

#36

Post by ramchip »

nmadden wrote: post #33
ramchip wrote: post #28

Earlier quoted context omitted.

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.

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!)

Re: Digital signatures and how to avoid them

#37

Post by beeboobaa3 »

resonious wrote: post #12
kccqzy wrote: post #7

The author mentions HMAC at the end. I think HMAC is really an underrated technique. I remember reading Colin Percival's classic Cryptographic Right Answers [0] and saw a section about "symmetric signatures." I pondered to myself what scheme I could use for that before I looked at the answer: of course it's just HMAC. I feel like this is another perspective that ought to be more widely known: if you want something to…

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 "…

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

Re: Digital signatures and how to avoid them

#38

Post by NovemberWhiskey »

dspillett wrote: post #30
skrebbel wrote: post #27

Earlier quoted context omitted.

> 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 t…

> 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 mig…

>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.

Re: Digital signatures and how to avoid them

#39

Post by mtndew4brkfst »

NovemberWhiskey wrote: post #38
dspillett wrote: post #30

Earlier quoted context omitted.

> 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 mig…

> 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…

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.

Re: Digital signatures and how to avoid them

#40

Post by NovemberWhiskey »

mtndew4brkfst wrote: post #39
NovemberWhiskey wrote: post #38

Earlier quoted context omitted.

> 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…

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.

I did a quick check on a 2016-era Xeon E5 v4 (AVX2), and sha512 is much faster per openssl speed.
Post reply on HN