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

51–60 of 85 posts

Re: Digital signatures and how to avoid them

#51

Post by sebbu »

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…

I already successfully used EU digital signatures through lex [1], but neither openpassport [2] not withpersona / linkedin [3] supports EU's new (2019+) identity cards, only passports. [1] https://lex.community/ [2] https://github.com/zk-passport/openpassport/issues/126 [3] https://www.linkedin.com/help/linkedin/answer/a1631613

Re: Digital signatures and how to avoid them

#52

Post by Aachen »

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?

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

Re: Digital signatures and how to avoid them

#53

Post by arianvanp »

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…

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

Re: Digital signatures and how to avoid them

#54

Post by dfox »

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

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.

Re: Digital signatures and how to avoid them

#55

Post by rpigab »

kbolino wrote: post #50
rpigab wrote: post #43

To me, DKIM doesn't prove that the user john.smith@gmail.com sent that email. It proves that gmail.com sent it. I'd avoid trusting FAANGs in courts when the fate of political leaders is at stake.

This is exactly what DKIM means, and this is why it has wide adoption, while S/MIME and PGP-signed mail remain relegated to niche uses. The entire purpose of DKIM is not to prove that the individual behind john.smith@gmail.com sent the message, but that a legitimate server owned and operated by the entity behind gmail.com sent the message. It's mostly there to reduce spam and phishing, not to ensure end-to-end commun…

Your last sentence kinda contradicts the fact that the company Google operates the server behind gmail.com.

If Google was evil (but in reality it's not), it could have forged and signed an email from john.smith@gmail.com with valid DKIM, sent on other mail servers or not (since we talk about leaked emails, we just need a file), when in reality the Google user john.smith@gmail.com never sent that email. To me, John Smith could have plausible deniability in court, depending on if everyone trusts Google to be 100% reliable. If the stakes are higher than what the company would risk to lose if found to have forged the email, what's stopping them?

Re: Digital signatures and how to avoid them

#56

Post by anyfoo »

loeg wrote: post #15
anyfoo wrote: post #10

Earlier quoted context omitted.

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

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

Re: Digital signatures and how to avoid them

#57

Post by dchest »

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?

Mostly incompetence.

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

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

Re: Digital signatures and how to avoid them

#58

Post by poincaredisk »

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…

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.

Re: Digital signatures and how to avoid them

#59

Post by [deleted] »

rpigab wrote: post #55
kbolino wrote: post #50

Earlier quoted context omitted.

This is exactly what DKIM means, and this is why it has wide adoption, while S/MIME and PGP-signed mail remain relegated to niche uses. The entire purpose of DKIM is not to prove that the individual behind john.smith@gmail.com sent the message, but that a legitimate server owned and operated by the entity behind gmail.com sent the message. It's mostly there to reduce spam and phishing, not to ensure end-to-end commun…

Your last sentence kinda contradicts the fact that the company Google operates the server behind gmail.com. If Google was evil (but in reality it's not), it could have forged and signed an email from john.smith@gmail.com with valid DKIM, sent on other mail servers or not (since we talk about leaked emails, we just need a file), when in reality the Google user john.smith@gmail.com never sent that email. To me, John Sm…

[deleted]

Re: Digital signatures and how to avoid them

#60

Post by kbolino »

rpigab wrote: post #55
kbolino wrote: post #50

Earlier quoted context omitted.

This is exactly what DKIM means, and this is why it has wide adoption, while S/MIME and PGP-signed mail remain relegated to niche uses. The entire purpose of DKIM is not to prove that the individual behind john.smith@gmail.com sent the message, but that a legitimate server owned and operated by the entity behind gmail.com sent the message. It's mostly there to reduce spam and phishing, not to ensure end-to-end commun…

Your last sentence kinda contradicts the fact that the company Google operates the server behind gmail.com. If Google was evil (but in reality it's not), it could have forged and signed an email from john.smith@gmail.com with valid DKIM, sent on other mail servers or not (since we talk about leaked emails, we just need a file), when in reality the Google user john.smith@gmail.com never sent that email. To me, John Sm…

Google could forge the email without DKIM (DMARC only requires one of SPF or DKIM to succeed, not both). While DKIM gives high confidence that the email came from Google, neither its presence nor absence says anything about John Smith.
Post reply on HN