Repository navigation
Add digital signature verification #12
Description
Activity
I think a post-quantum signature scheme should be used instead. I propose RAIN, since it is more simple to understand than other post-quantum signature schemes.
Do you know if there is any JavaScript implementation of Rainer scheme? Currently, Clavimit uses the standardized Web Crypto API, which is widely implemented across modern browsers and it does not implement its own cryptographic implementation. I do not expect to the post-quantum schemes (standardized or not) to be already widely implemented, but it would be better if Clavimit uses a scheme that we do not have to implement ourself.
The only ones I have found are programmed in C/C++/Assembly (this is the official one: https://github.com/[isec-tugraz/rainier-signatures](https://github.com/isec-tugraz/rainier-signatures))
It is a bit annoying having to handle C/C++, we would have to introduce Web Assembly.
Two of the standards for signature accepted by NIST: ML-DSA (FIPS-204) and SLH-DSA (FIPS-205) are implemented in this JavaScript package: https://github.com/paulmillr/noble-post-quantum/tree/main . What do you think of these?
Yes, they can be used. The first one is based on lattices, which may be more difficult to understand. The second one is based on the pre-image security of hash function, which should be easier.
Ok. Let's then keep this issue for RSA and we open a new one for SLH-DSA post-quantum signature scheme. It would be nice to ship Clavimit version 0.2.x with RSA signatures and 0.3.x with post quantum schemes.
Summary
Add digital signatures to Clavimit messages so that recipients can verify that an encrypted message was produced by the holder of the expected sender private key.
Motivation
Clavimit currently provides confidentiality but does not authenticate the sender of an encrypted message.
Digital signatures would allow the recipient to verify that the encrypted message was signed by the holder of a specific private key and that the signed content has not been modified.
The recipient remains responsible for verifying that the public key used for signature verification actually belongs to the expected sender.
This issue depends on support for multiple Clavimit message format versions, since signed messages will require additional information in the encrypted message format.
Proposed behavior
Encryption
When signature support is enabled:
Decryption and signature verification
When decrypting a signed Clavimit message:
The recipient is responsible for obtaining and verifying the sender's public key through an external trusted channel.
Message format
Signed messages should use a dedicated message format version capable of carrying the signature and any information required for verification.
The new message format version should include a field for the digital signature.
For signed messages, the field contains the generated signature.
For unsigned messages, the field is set to
null.or:
The other fields remain unchanged
{ "version": 2, "encryptedKey": "...", "iv": "...", "ciphertext": "...", "signature": <ignature> }or
{ "version": 2, "encryptedKey": "...", "iv": "...", "ciphertext": "...", "signature": null }This keeps the structure of the message format consistent regardless of whether the sender chooses to sign the message.
Existing message format versions should remain supported.
Out of scope
This issue does not introduce automatic identity verification, public-key directories, certificate authorities, or key-management services.
Clavimit verifies the cryptographic signature against the public key supplied by the user, but does not determine whether that public key belongs to a particular person.