Name of collaborators:
In the file mes.sage you will find what I've got to say to you all (the file can be directly interpreted in Sage, but make sure to have a look at what it contains).
Note: mes.sage will need to be reloaded afterwards because the variables r and s used for the signature are overwritten by those of the certificate.
1. Check that the parameters given in the certificate form a valid triple for DSA.
Since is prime, this is sufficient to guarantee that the multiplicative order of is (since it cannot be a proper divisor of it).
2. Then verify that the message signature checks out correctly. The hash function that was used is simply to take the number of characters in the message (mod ).
3. This is, however, a very insecure hash function. Can you see how an attacker could use this to forge a message bearing my signature? (the signature has to appear valid to anyone that verifies it).
Remember that it's actually a hash of the message that is signed; that is, the signature would still be considered valid on any other message having the same hash value. For example:
The security of the hash function really is an integral part of the security of the digital signature.
Your turn now: you should have received a private key from the CA. Check that the it contains form indeed a valid key pair for DSA with the given .
Here is my private key:
Then compute the SHA256-DSA signature of a message of your choice with this private key. You may post the signed message on the forum on Campus so that everybody can verify the signature.
And here's the corresponding verification function:
Being a certificate authority is not a role that should be taken lightly. Indeed, if you take a look at the certificates generated by Charles-Antoine, you'll see that there is a serious problem with hist implementation of DSA: all components of his signatures are equal! What mistake has been committed?
If all values of are the same, it means that the same value of was used for all signature -- when a new random one should be used each time to protect the private signing key. Indeed, as soon as the same is used to sign two different messages and , we get a system of linear congruences which is readily solved for (and ), e.g. using Cramer's rule:
Exploit this mistake by recovering the CA private key, hence gaining the ability to generate your own ("verifiable") certificates. Test this ability by forgeing a fake one!
This is the message that Charles-Antoine actually signed:
We only need a second certificate for the attack to work.
And here's the actual cracking:
Et voilà! Having recovered Charles-Antoine's private signing key, we can now sign anything we want as him (and a verifier has no way to detect the forgery). Here's for example a fake certificate that binds my public key with someone famous:
Anyone that verifies Charles-Antoine's signature on this certificate using his public key will consider it valid:
As always, to do things properly in real life, it's better not to try to implement your own crypto and instead use a standard tool. Learn how the signature (and subsequent verification of it) of a text file works with OpenSSL and show me an example of it (you can run the commands in a terminal attached to this project).
Assuming you a textfile message.txt that you want to sign, these would be the command you need to issue: