NAME

crypto_sign, crypto_check, crypto_sign_public_key — public key signatures

SYNOPSIS

#include <monocypher.h>

void
crypto_sign_public_key(uint8_t public_key[32], const uint8_t secret_key[32]);

void
crypto_sign(uint8_t signature[64], const uint8_t secret_key[32], const uint8_t public_key[32], const uint8_t *message, size_t message_size);

int
crypto_check(const uint8_t signature[64], const uint8_t public_key[32], const uint8_t *message, size_t message_size);

DESCRIPTION

crypto_sign() and crypto_check() provide EdDSA public key signatures and verification.

The arguments are:


signature: The signature.

secret_key: A 32-byte random number, known only to you. See intro(3monocypher) about random number generation (use your operating system's random number generator). Do not use the same private key for both signatures and key exchanges. The public keys are different, and revealing both may leak information.

public_key: The public key, generated from secret_key with crypto_sign_public_key().

message: Message to sign.

message_size: Length of message, in bytes.

signature and message may overlap.

crypto_sign_public_key() computes the public key of the specified secret key.

crypto_sign() signs a message with secret_key. The public key is optional, and will be recomputed if not provided. This recomputation doubles the execution time.

crypto_check() checks that a given signature is genuine. Meaning, only someone who had the private key could have signed the message. It does not run in constant time. It does not have to in most threat models, because nothing is secret: everyone knows the public key, and the signature and message are rarely secret. If the message needs to be secret, use crypto_key_exchange(3monocypher) and crypto_lock_aead(3monocypher) instead.

An incremental interface is available; see crypto_sign_init_first_pass(3monocypher).

RETURN VALUES

crypto_sign_public_key() and crypto_sign() return nothing.

crypto_check() returns 0 for legitimate messages and -1 for forgeries.

EXAMPLES

The following examples assume the existence of arc4random_buf(), which fills the given buffer with cryptographically secure random bytes. If arc4random_buf() does not exist on your system, see intro(3monocypher) for advice about how to generate cryptographically secure random bytes.

Generate a public key from a random secret key:

uint8_t       sk[32]; /* Random secret key   */ 
uint8_t       pk[32]; /* Matching public key */ 
arc4random_buf(sk, 32); 
crypto_sign_public_key(pk, sk); 
/* Wipe the secret key if it is no longer needed */ 
crypto_wipe(sk, 32);

Sign a message:

uint8_t       sk       [32]; /* Secret key from above          */ 
const uint8_t pk       [32]; /* Matching public key            */ 
const uint8_t message  [11] = "Lorem ipsu"; /* Message to sign */ 
uint8_t       signature[64]; 
crypto_sign(signature, sk, pk, message, 10); 
/* Wipe the secret key if it is no longer needed */ 
crypto_wipe(sk, 32);

Check the above:

const uint8_t pk       [32]; /* Their public key              */ 
const uint8_t message  [11] = "Lorem ipsu"; /* Signed message */ 
const uint8_t signature[64]; /* Signature to check            */ 
if (crypto_check(signature, pk, message, 10)) { 
    /* Message is corrupted, abort processing */ 
} else { 
    /* Message is genuine */ 
}

STANDARDS

These functions implement PureEdDSA with Curve25519 and Blake2b, as described in RFC 8032. This is the same as Ed25519, with Blake2b instead of SHA-512.

HISTORY

The crypto_sign(), crypto_check(), and crypto_sign_public_key() functions appeared in Monocypher 0.2.

A critical security vulnerability that caused all-zero signatures to be accepted was introduced in Monocypher 0.3; it was fixed in Monocypher 1.1.1 and 2.0.4.

SECURITY CONSIDERATIONS

Signature malleability

EdDSA signatures are not unique like cryptographic hashes. For any given public key and message, there are many possible valid signatures. Some of them require knowledge of the private key. Others only require knowledge of an existing signature. Observing a valid signature only proves that someone with knowledge of the private key signed the message at some point. Do not rely on any other security property.

Fault injection and power analysis

Fault injection (also known as glitching) and power analysis may be used to manipulate the resulting signature and recover the secret key in some cases. This requires hardware access. If attackers are expected to have such access and have the relevant equipment, you may try use the incremental interface provided by crypto_sign_init_first_pass(3monocypher) to mitigate the side channel attacks. Note that there may still be other power-related side channels (such as if the CPU leaks information when an operation overflows a register) that must be considered.