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

81–85 of 85 posts

Re: Digital signatures and how to avoid them

#81

Post by sandij »

dwaite wrote: post #80
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?

Non-repudiation of commitments to a transaction can be good when both parties want to avoid later disputes about the authenticity of these commitments. It requires careful design of the data to be signed, the public key certificates, the policies governing the signature creation and validation processes, and the signature formats to enable validation as long as needed.

Attribute presentation is not designed for this feature. When attribute presentation becomes non-repudiable, it creates legal uncertainty:

1. In court, the verifier may now present the proof of possession as evidence. But this is, at least in the EU, not recognised by default as an e-signature. It is yet unknown if it would be interpreted as such by a court. So the verifier keeps a risk that will be difficult for them to assess.

2. Even if it would be recognised as evidence, the holder may argue that it is a replay of a presentation made in another transaction. Presentation protocols are not designed for timestamp assurance towards third parties, and generally do not include verifiable transaction information.

3. The verifier may protect itself by audit-logging attribute presentation input and output along with publicly verifiable timestamps and verifiable transaction information, and by editing its terms and conditions to claim a priori non-repudiation of any presentation. Typically such a solution would not create the same evidence files at the holder’s side. So the holder would not be able to present as strong evidence in court as the verifier. (This asymmetry aspect needs some more elaboration.)

Non-repudiation is well arranged in EU law for e-signatures. If anyone would want the same for attribute presentation, this should involve changes in law. As far as I can see, non-repudiation is now opportunistically being considered in mDL/EUDI just from an isolated technical perspective.

Re: Digital signatures and how to avoid them

#82

Post by sandij »

dwaite wrote: post #80
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?

Another issue with non-repudiation of presentation is that it encourages relying parties to log full transcripts of presentation interactions. It could also encourage supervisory bodies to request such over-complete logging. Instead, relying parties should log the minimum necessary, to avoid developing a honeypot of personal data.

Re: Digital signatures and how to avoid them

#83

Post by anyfoo »

loeg wrote: post #62
anyfoo wrote: post #56

Earlier quoted context omitted.

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

Do you ever need to implement an HMAC from scratch? I'd look for an off-the-shelf solution before trying to find a cryptographer.

I don't, and I absolutely did not mean to imply that anyone should implement HMAC themselves. I was addressing people who want to potentially use HMAC (after proper consultation with cryptographers), for which a general understanding of HMAC is prerequisite. Hence why my original comment only described implementation on a surface level, but elaborated over potential uses for HMAC.

Only cryptographers should implement crypto primitives. Even if I'd get the algorithm itself right, I might not know how to make it so that it runs in constant time (which is something that crosses into the CPU's ability to do so), and thus may inadvertently leak secrets through side channels.

But even if I just use HMAC, I still consult with cryptographers to make sure my use is correct, that there is no better solution, and that I am not missing any attack vectors.

Even in simple cases it can be a grave mistake to use seemingly simple crypto primitives without proper consultation, see for example some of the very prominent problems that were the result of improper IV usage with AES.

Re: Digital signatures and how to avoid them

#84

Post by namibj »

nmadden wrote: post #75
namibj wrote: post #73

Earlier quoted context omitted.

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?

Google's post-quantum TLS experiments that were done in public via Android Chrome are such; basically you just do normal TLS handshake but stack the key derivation from the traditional DH-type perfect-forward-secrecy exchange with a post-quantum-perfect-forward-secrecy exchange that you all seal under the same handshake authentication, and where you make sure to only use post quantum symmetric primitives to fuse the traditional session key material with the PQ session key material such that you don't rely on either one's resistance to keep your secrets secret.

Sorry I don't have a link quite on hand right now.

Re: Digital signatures and how to avoid them

#85

Post by nmadden »

namibj wrote: post #84
nmadden wrote: post #75

Earlier quoted context omitted.

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

Google's post-quantum TLS experiments that were done in public via Android Chrome are such; basically you just do normal TLS handshake but stack the key derivation from the traditional DH-type perfect-forward-secrecy exchange with a post-quantum-perfect-forward-secrecy exchange that you all seal under the same handshake authentication, and where you make sure to only use post quantum symmetric primitives to fuse the…

OK, sure. As far as I’m aware, nobody’s actually made that into an actual AKEM proposal though. (I wish they would, as I think many applications would be fine with pre-quantum authentication and post-quantum confidentiality).
Post reply on HN