Digital signatures and how to avoid them
neilmadden.blog
Digital signatures and how to avoid them
1–10 of 85 posts
Re: Digital signatures and how to avoid them
#2This 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 credential subject for example.
Instead, the high assurance use cases should complement digital credentials (with plausible deniability of past presentations) with qualified e-signatures and e-seals. For these, the EU for example does provide a legal framework that protects both the relying party and the signer.
Re: Digital signatures and how to avoid them
#3This 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…
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.
Re: Digital signatures and how to avoid them
#4This 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…
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.
Well, at least you can laminate it
Re: Digital signatures and how to avoid them
#5This 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…
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.”
Re: Digital signatures and how to avoid them
#6This 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…
[dead]
Re: Digital signatures and how to avoid them
#7The 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 be like a signature, but the two parties (or just a single party at different times) can share a key, HMAC really is the right answer. Things like, a server needs to cryptographically sign a cookie to prevent tempering: that's HMAC. Or a server needs to know an API request is coming from an expected client: that's also HMAC.
[0]: https://www.daemonology.net/blog/2009-06-11-cryptographic-ri...
Re: Digital signatures and how to avoid them
#8This 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.
Re: Digital signatures and how to avoid them
#9This 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…
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.
> 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.
You can get up to ten replacements of your card in your lifetime. They do all have the same number though.
Re: Digital signatures and how to avoid them
#10The 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 side told you, then you know that the other side had the secret key (and exactly this message), because there's obviously no way to go from SHA256 to the input.
HMAC is also useful if you want to derive new secret keys from other secret keys. Take an HMAC with the secret key and an arbitrary string, you get a new secret key. The other side can do the same thing. Here's the kicker, the arbitrary string does not have to be secret to anyone, it can be completely public!
Why would you do that? Well, maybe you want the derived key to have a different lifetime and scope. A "less trusted" component could be given this derived key to do its job without having to know the super-secret key it was derived from (which could be used to derive other keys for other components, or directly HMAC or decrypt other stuff).