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

41–50 of 85 posts

Re: Digital signatures and how to avoid them

#41

Post by moffkalast »

sunk1st wrote: post #5
moffkalast wrote: post #3

Earlier quoted context omitted.

I mean it's not a super big deal if the EU identity private key leaks in some arcane attack or if someone steals it the normal way, you can just cancel it and order a new one like a credit card. It expires every two years I think anyway. This reminds me of a specific number that Americans have to give in plain text as proof of digital identity that they only get one of and can't change it ever. Lol.

That doesn’t matter. The claim being made by the grandparent post is that the legal system isn’t well-equipped to deal with scenarios like, “yes the digital signature is valid but it was improperly authorized.”

The legal system also isn't well equipped to deal with the conceptually roughly equal case of someone stealing your car and running people over with it, but it deals with it anyway.

Re: Digital signatures and how to avoid them

#42

Post by pjc50 »

sandij wrote: post #20
lmm wrote: post #8

Earlier quoted context omitted.

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

Getting the parties on the desk, or the people commissioning enterprise IT systems, to understand this is going to be a serious uphill struggle. Especially in places that are used to photocopying your ID.

Re: Digital signatures and how to avoid them

#44

Post by mistrial9 »

pjc50 wrote: post #42
sandij wrote: post #20

Earlier quoted context omitted.

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

Getting the parties on the desk, or the people commissioning enterprise IT systems, to understand this is going to be a serious uphill struggle. Especially in places that are used to photocopying your ID.

the liquor store owner that scans the barcode on your Driver's License "does not understand" and does not care to understand. Yet the opening to your entire life to some low-level cog has been transferred. The correct answer for the wonks out there is : scan ID to answer the question "is this person over the legal drinking age" YES or NO .. which is stored. Similar situations with different contexts, abound.

Re: Digital signatures and how to avoid them

#45

Post by nmadden »

ramchip wrote: post #36
nmadden wrote: post #33

Earlier quoted context omitted.

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

Ok, makes sense.

Re: Digital signatures and how to avoid them

#46

Post by kd5bjo »

argulane wrote: post #24
atoav wrote: post #22

Earlier quoted context omitted.

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

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.

Re: Digital signatures and how to avoid them

#47

Post by next_xibalba »

Slightly off topic:

In school I only took one cryptography class (it was bundled with networking, at that), and to this day I still think it contained some of the most amazing concepts I've ever learned. Public-key cryptography being on the short list along with cryptographic hash functions. Maybe it's my particular bias, or maybe cryptography has just attracted some of the most creative genius' of the 20th century.

Re: Digital signatures and how to avoid them

#48

Post by atoav »

argulane wrote: post #24
atoav wrote: post #22

Earlier quoted context omitted.

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

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

Re: Digital signatures and how to avoid them

#49

Post by formerly_proven »

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.

The 32 bit variants are accelerated via SHA-NI on most CPUs, which inverts the performance ranking again, making SHA-256 the fastest common cryptographic hash by far.

Re: Digital signatures and how to avoid them

#50

Post by kbolino »

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

This has nothing to do with the particular companies involved nor their particular trustworthiness.

Post reply on HN