For those who want a conceptual, visual, cartoon explainer, check out our 1min animated series: https://gun.eco/docs/Cartoon-Cryptography
An Overview of Cryptography
11–20 of 34 posts
Re: An Overview of Cryptography
#12Very interesting paper indeed. Could be more appealing if the vanilla html was properly styled though.
I find it fairly decent, far better than the usual academic pdf anyway if that's the standard most accept. How would you improve the page?
My personal tweaks:
body { font-size: 19px; width: 72ch; font-family: Charter; margin: 0 auto; line-height: 1.4; }
and then remove the size= option on the element.
Re: An Overview of Cryptography
#13Cryptography was both my favorite topic in school and the one that cemented my realization in that I wasn't good enough to do math for a living.
Re: An Overview of Cryptography
#14"This scheme also provides nonrepudiation since it proves that Alice sent the message; if the hash value recovered by Bob using Alice's public key proves that the message has not been altered, then only Alice could have created the digital signature." This is a common misconception. Just because a signature verifies under Alice's public key, it does not necessarily imply Alice generated the signature. For many common…
In particular, see also this 2005 paper by Thomas Pornin: http://www.bolet.org/~pornin/2005-acns-pornin+stern.pdf EDIT: Looks like this paper is also already included in the list of citations for the 2019 paper :)
This is also a Cryptopals exercise in Set 8:
Re: An Overview of Cryptography
#15Shameless plug: I’ve been writing my own introduction for students/developers/consultants/... and you can read it online for free it seems (or at least some chapters): https://www.manning.com/books/real-world-cryptography
Re: An Overview of Cryptography
#16Earlier quoted context omitted.
In particular, see also this 2005 paper by Thomas Pornin: http://www.bolet.org/~pornin/2005-acns-pornin+stern.pdf EDIT: Looks like this paper is also already included in the list of citations for the 2019 paper :)
This is also a Cryptopals exercise in Set 8: https://toadstyle.org/cryptopals/61.txt
The first time I heard of this bug was through the Another Look series where it was called DSKS.
Re: An Overview of Cryptography
#17"This scheme also provides nonrepudiation since it proves that Alice sent the message; if the hash value recovered by Bob using Alice's public key proves that the message has not been altered, then only Alice could have created the digital signature." This is a common misconception. Just because a signature verifies under Alice's public key, it does not necessarily imply Alice generated the signature. For many common…
LetsEncrypt was vulnerable to this exact attack - it let people issue valid TLS certificates for domains they didn't control:
https://www.agwa.name/blog/post/duplicate_signature_key_sele...
Re: An Overview of Cryptography
#18"This scheme also provides nonrepudiation since it proves that Alice sent the message; if the hash value recovered by Bob using Alice's public key proves that the message has not been altered, then only Alice could have created the digital signature." This is a common misconception. Just because a signature verifies under Alice's public key, it does not necessarily imply Alice generated the signature. For many common…
Btw you don’t mention repudiation in there, but would you say it makes sense to say that most signature scheme actually don’t provide non-repudiation?
Re: An Overview of Cryptography
#19"This scheme also provides nonrepudiation since it proves that Alice sent the message; if the hash value recovered by Bob using Alice's public key proves that the message has not been altered, then only Alice could have created the digital signature." This is a common misconception. Just because a signature verifies under Alice's public key, it does not necessarily imply Alice generated the signature. For many common…
LetsEncrypt was vulnerable to this exact attack - it let people issue valid TLS certificates for domains they didn't control: https://www.agwa.name/blog/post/duplicate_signature_key_sele...
We discuss this exact attack (and blog post) in Section 5.1 of the paper :).
IIRC: it was missed by both an academic analysis of LE and a 3rd party audit of their crypto design. Thankfully Andrew spotted it a few weeks before they went live in major browsers!
Re: An Overview of Cryptography
#20"This scheme also provides nonrepudiation since it proves that Alice sent the message; if the hash value recovered by Bob using Alice's public key proves that the message has not been altered, then only Alice could have created the digital signature." This is a common misconception. Just because a signature verifies under Alice's public key, it does not necessarily imply Alice generated the signature. For many common…
Btw you don’t mention repudiation in there, but would you say it makes sense to say that most signature scheme actually don’t provide non-repudiation?
It depends what you consider to be non-repudiation!
With key substitution, you have a signature that can verify under multiple public keys. However, each key was either honestly generated and used to sign the message, or was maliciously generated and intended to appear to have signed the message.
In this sense, the party associated with each public is indisputably associated with the corresponding signature.
However, this gets a bit more confusing with message key substitution (two public keys, two messages, one signature) or colliding signature (one public key, any number of messages, one signature). For example, a malicious party might produce a signature which is valid for any message. Does the fact that they've "signed everything" mean they can repudiate having signed anything? (The connection between intent to sign and the signature has arguably been lost).
We do discuss these other properties in the paper, but we don't really delve into non-repudiation in the informal sense.