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

11–20 of 85 posts

Re: Digital signatures and how to avoid them

#11

Post by gyush »

> 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 knowledge proofs. See: https://www.andrewclu.com/sign-everything -- the ability to make all your data self-sovereign and selectively prove data to the outside world (i.e. prove I'm over 18 without showing my whole passport) can be extremely beneficial, especially as we move towards a world of AI generated content where provenant proofs can prove content origin to third parties. You're right that post quantum signature research is still in progress, but I suspect that until post-quantum supremacy, it's still useful (and by then I hope we'll have fast and small post quantum signature schemes).

EU's digital signatures let you do this for your IDs and https://www.openpassport.app/ lets you do this for any country passport, but imagine you could do this for all your social media data, personal info, and login details. we could have full selective privacy online, but only if everyone uses digital signatures instead of HMACs.

Re: Digital signatures and how to avoid them

#12

Post by resonious »

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

Re: Digital signatures and how to avoid them

#13

Post by __MatrixMan__ »

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?

Re: Digital signatures and how to avoid them

#14

Post by loeg »

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…

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

Re: Digital signatures and how to avoid them

#15

Post by loeg »

anyfoo wrote: post #10
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…

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

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

Re: Digital signatures and how to avoid them

#16

Post by kccqzy »

loeg wrote: post #14
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…

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

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

Re: Digital signatures and how to avoid them

#17

Post by JimDabell »

kccqzy wrote: post #16
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...

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

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

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

Re: Digital signatures and how to avoid them

#18

Post by notfed »

loeg wrote: post #14
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…

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

Re: Digital signatures and how to avoid them

#19

Post by Elucalidavah »

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

> "&" inside JSON strings but yours escapes it

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

Re: Digital signatures and how to avoid them

#20

Post by sandij »

lmm wrote: post #8
sandij wrote: post #2

This article is very relevant in the context of the EU Digital Identity Wallet, and digital credentials in general, such as ISO/IEC 18013-5 mobile driver licenses and other mdocs. We may accidentially end up with non-repudiation of attribute presentation, thinking that this increases assurance for the parties involved in a transaction. The legal framework is not designed for this and insufficiently protects the crede…

Isn't non-repudiation something we want for cases like this? If e.g. a car rental place checks your driving license before renting you a car, and then you get into a crash, no-one wants you to be able to claim that you never showed them your driving license and they never checked.

To prove that the car rental company has seen the driver licence, they just need to show the judge a copy of the licence which is e-sealed by its issuing authority. No need to include a non-repudiable proof-of-possession signature of the holder. Having that in addition would just introduce legal ambiguity and information asymmetry to the disadvantage of the holder.

The opponent may still claim that the car rental place is showing a copy that was obtained illegally, and not in holder presentation. To avoid such a claim, the car rental company should ask for a qualified e-signature before providing the car key. The signed data can include any relevant claims that both parties confirm as part of the transaction. To provide similar assurance to the customer, the company should counter-sign that document, or provide it pre-sealed if it is an automated process.

Note that with the EU Digital Identity, creating qualified e-signatures is just as easy as presenting digital credentials.

Post reply on HN