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

21–30 of 85 posts

Re: Digital signatures and how to avoid them

#21

Post by resonious »

Elucalidavah wrote: post #19
resonious wrote: post #12

Earlier quoted context omitted.

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

> "&" inside JSON strings but yours escapes it What escaping of "&" inside JSON are you talking about? Some unholy mix of JSON and urlencode?

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

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

Re: Digital signatures and how to avoid them

#22

Post by atoav »

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?

Re: Digital signatures and how to avoid them

#23

Post by nmadden »

notfed wrote: post #18
loeg wrote: post #14

Earlier quoted context omitted.

More generally, a MAC. You don't necessarily need one based on a hash. (Unrelated) see also the more recent https://www.latacora.com/blog/2018/04/03/cryptographic-right...

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…

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

Re: Digital signatures and how to avoid them

#24

Post by argulane »

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?

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.

Re: Digital signatures and how to avoid them

#25

Post by vogr »

__MatrixMan__ wrote: post #13
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…

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

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

Re: Digital signatures and how to avoid them

#26

Post by growse »

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

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

Re: Digital signatures and how to avoid them

#27

Post by skrebbel »

notfed wrote: post #18
loeg wrote: post #14

Earlier quoted context omitted.

More generally, a MAC. You don't necessarily need one based on a hash. (Unrelated) see also the more recent https://www.latacora.com/blog/2018/04/03/cryptographic-right...

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…

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

Re: Digital signatures and how to avoid them

#28

Post by ramchip »

__MatrixMan__ wrote: post #13
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…

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.

Re: Digital signatures and how to avoid them

#29

Post by ramchip »

gyush wrote: post #11

> As well as authenticating a message, they also provide third-party verifiability and (part of) non-repudiation. I think digital signatures and third party verification are an incredibly useful feature. The ability to prove you received some data from some third party lets you prove things about yourself, and enables better data privacy long-term, especially when you have selective disclosure when combined with zero…

The article's point is that these properties are not always desirable. Imagine someone messages a friend via an app, and mentions that they're gay, in a country where it's illegal. If the app uses signatures they can't deny that they sent the message. If it's based on key agreement (like Signal), then either party could have faked the exchange, so there's at least some deniability.

Re: Digital signatures and how to avoid them

#30

Post by dspillett »

skrebbel wrote: post #27
notfed wrote: post #18

Earlier quoted context omitted.

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…

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

Post reply on HN