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

71–80 of 85 posts

Re: Digital signatures and how to avoid them

#71

Post by tptacek »

loeg wrote: post #70
tptacek wrote: post #67

Earlier quoted context omitted.

Yes, I wrote the older Latacora one, which was based on thing I wrote under my own name before I founded Latacora; I'm pretty sure I'm on solid ground saying Colin Percival had nothing to do with anything I wrote, since I wrote the first one as a rebuttal to Colin. (Did I misread you? Maybe we just agree.)

I think we agree. I was only responding to the "Who's 'they'?" bit.

Sorry. I'm touchy about the cursed meme I helped create and also flinching at the idea that anything I wrote might get attributed to Colin. Definitely don't mean to jump down your throat.

Re: Digital signatures and how to avoid them

#72

Post by JimDabell »

tptacek wrote: post #71
loeg wrote: post #70

Earlier quoted context omitted.

I think we agree. I was only responding to the "Who's 'they'?" bit.

Sorry. I'm touchy about the cursed meme I helped create and also flinching at the idea that anything I wrote might get attributed to Colin. Definitely don't mean to jump down your throat.

Yeah, just in the interests of clarity, somebody linked to the Latacora article “Cryptographic Right Answers” and I’d happened to read the updated Latacora article “Cryptographic Right Answers: Post Quantum Edition” a few hours beforehand, so I linked to it. “They” means Latacora, not Colin Percival.

Re: Digital signatures and how to avoid them

#73

Post by namibj »

nmadden wrote: post #32
vogr wrote: post #25

Earlier quoted context omitted.

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.

There are post quantum KEMs though that authenticate with a classical mechanism, which limits quantum attacks to interactive from the previous total breakage of recorded ciphertext exchanges (e.g. Wireshark capture at a router encountered in both directions of the traffic flow).

Re: Digital signatures and how to avoid them

#74

Post by namibj »

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…

Can you make the comparison to the German eID (notable for it's unusually extensive privacy-preserving tactics)?

Re: Digital signatures and how to avoid them

#75

Post by nmadden »

namibj wrote: post #73
nmadden wrote: post #32

Earlier quoted context omitted.

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.

There are post quantum KEMs though that authenticate with a classical mechanism, which limits quantum attacks to interactive from the previous total breakage of recorded ciphertext exchanges (e.g. Wireshark capture at a router encountered in both directions of the traffic flow).

Are there? I’ve advocated for such constructions in the past, but I’ve never seen an actual proposal. Do you have a link?

Re: Digital signatures and how to avoid them

#76

Post by loeg »

tptacek wrote: post #71
loeg wrote: post #70

Earlier quoted context omitted.

I think we agree. I was only responding to the "Who's 'they'?" bit.

Sorry. I'm touchy about the cursed meme I helped create and also flinching at the idea that anything I wrote might get attributed to Colin. Definitely don't mean to jump down your throat.

No problem.

Re: Digital signatures and how to avoid them

#77

Post by jaeckel »

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…

The answer is: dedicated CPU instructions for SHA256 vs. software implementation of SHA512. For amd64 there's SHA-NI, for Arm there's the crypto extensions, but both only provide sha256 (at least when I last looked at their specs)

Re: Digital signatures and how to avoid them

#78

Post by sandij »

namibj wrote: post #74
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…

Can you make the comparison to the German eID (notable for it's unusually extensive privacy-preserving tactics)?

I’m not sure what the German eID uses today, but the German architecture team has explored KEM+MAC for the EU Digital Identity Wallet. Maybe its eID is similar. You can apply KEM+MAC at either or both of two points:

1. plausible deniability of the document’s issuer seal

2. plausible deniability of having presented the document

The second is great for legal certainty for the user. The first has problems. It would be incompatible with qualified e-sealing; stakeholders have no evidence if issuer integrity was compromised.

Also, it would mean that issuance happens under user control, during presentation to a relying party. In a fully decentralised wallet architecture, this means including the trusted issuer KEM key pair on the user’s phone. Compromising the issuance process, for example by extracting the trusted issuer KEM key pair, could enable the attacker to impersonate all German natural persons online.

The advantage would have been that authenticity the content of stolen documents could be denied. This potentially makes it less interesting to steal a pile of issued documents and sell it illegally. But how would illegal buyers really value qualified authenticity e-seals on leaked personal data?

Re: Digital signatures and how to avoid them

#80

Post by dwaite »

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…

Can you go into a bit more detail on what you see as the problem in non-repudiation of presentation?
Post reply on HN