ML-DSA is a module lattice digital signature post-quantum algorithm, based on the FIPS 204 standard, approved and recommended by NIST for post-quantum cryptography. ML-DSA lets users sign and verify data (like documents, files, code, certificates, etc.) in a way that should stay secure even when large scale fault tolerant quantum computers (LSFTQC) become practical and accessible.
The problem with the current digital signature algorithms, like RSA or ECDSA, is that they rely on math problems that quantum computers can solve quickly. In other words, LSFTQC can break current digital signature algorithms, like RSA or ECDSA (on which most of the current blockchains and cryptos are based), very fast.
In the previous posts (see [1-2]) we considered ML-KEM post-quantum algorithm, recommended by NIST, and the example of how to use it for sending secure messages over communication channels not protected by post-quantum or hybrid encryptions. As a rule, we encrypt messages when we do not want that unauthorized parties would be able to read them. ML-DSA and other digital signature algorithms do not encrypt messages, the messages are sent not encrypted. Because, these messages are not encrypted, hackers can modify them. To prevent such scenario, senders send with the messages their digital signatures and public keys, which allow to verify by recipients, that the messages were not modified by unauthorized parties. Let us consider an example.
John, who is the CEO of a private company, wants to invite Helen, who is a financial director in the company, to a very important meeting. There is no any secret information in the message (therefore, there is no a need to encrypt the message), but there is a risk that unauthorized parties can change the message and mislead Helen, which may result in Helen misses the meeting. To prevent such scenario, John must sign the message with his private cryptographic key and send to Helen the message, the signature, and the public cryptographic key (to verify that the message was not modified).
John goes to this URL: https://agustinsrg.github.io/crystals-dilithium-js/test.html (for other options, see [3-8]) and creates private/public cryptographic keys, by clicking on the button “Generate”.
Then, John creates a digital signature of the message with the generated private key, by clicking on the button “Sign”.
Then, John sends the message, the signature, and the public key to Helen.
To verify that the message was not modified by unauthorized paries, Helen goes to the same URL, enters the message, the signature, and the public key into the corresponding fields and clicks on the button “Validate”. The result is valid, so the message is authentic.
P.S. 1. If there is a need to keep messages secret then users must encrypt the messages. If there is no a need to keep messages secret then these messages must be digitally signed to prevent modifications of these messages by unauthorized parties.
2. Hybrid or pure post-quantum encryptions require two ways communications/interactions between a sender and a receiver, before the encryptions and transmissions of the encrypted messages. Digitally signed messages do not require two way communications/interactions between a sender and a receiver.
3. Digital signatures on digital data/files/documents are analogous to hand-written signatures on paper documents and have the same purpose: to provide integrity, authentication, and non-repudiation of the signed documents/data.
4. ML-DSA can be used for digital signing of encapsulation keys and cipertexts in ML-KEM.
5. In our old analogy (see [2]), the main difference between ML-DSA and classical digital signature algorithms is in the foundation (complex mathematical problem).
References:
3. https://agustinsrg.github.io/crystals-dilithium-js/test.html
4. https://asecuritysite.com/webcrypto/crypt_ml_dsa
6. https://learn.microsoft.com/en-us/windows/win32/seccng/cng-mldsa-examples
