Skip to content

Add digital signature verification #12

Description

@LucaBonamino

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:

  • allow the sender to provide their private key for signing;
  • generate a digital signature for the message;
  • include the signature in the appropriate Clavimit message format version;
  • keep the existing encryption process unchanged where possible;
  • clear the signing private key from the UI after the operation completes, whether signing/encryption succeeds or fails.

Decryption and signature verification

When decrypting a signed Clavimit message:

  • allow the recipient to provide the sender's public key;
  • verify the signature using that public key;
  • clearly display whether signature verification succeeded or failed;

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.

signature: <signature>

or:

signature: null

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.

Activity

  1. PabloGFL commented on Sep 7, 2026

    @PabloGFL
    Collaborator

    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.

  2. LucaBonamino commented on Sep 7, 2026

    @LucaBonamino
    CollaboratorAuthor

    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.

  3. PabloGFL commented on Sep 7, 2026

    @PabloGFL
    Collaborator

    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))

  4. LucaBonamino commented on Sep 7, 2026

    @LucaBonamino
    CollaboratorAuthor

    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?

  5. PabloGFL commented on Sep 22, 2026

    @PabloGFL
    Collaborator

    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.

  6. LucaBonamino commented on Sep 23, 2026

    @LucaBonamino
    CollaboratorAuthor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions