CRYPTO_SIGN_INIT_FIRST_PASS(3MONOCYPHER) | 3MONOCYPHER | CRYPTO_SIGN_INIT_FIRST_PASS(3MONOCYPHER) |
crypto_sign_init_first_pass
,
crypto_sign_update
,
crypto_sign_final
,
crypto_sign_init_second_pass
,
crypto_check_init
,
crypto_check_update
,
crypto_check_final
—
#include <monocypher.h>
void
crypto_sign_init_first_pass
(crypto_sign_ctx
*ctx, const uint8_t secret_key[32],
const uint8_t public_key[32]);
void
crypto_sign_update
(crypto_sign_ctx
*ctx, const uint8_t *message,
size_t message_size);
void
crypto_sign_final
(crypto_sign_ctx
*ctx, uint8_t signature[64]);
void
crypto_sign_init_second_pass
(crypto_sign_ctx
*ctx);
void
crypto_check_init
(crypto_check_ctx
*ctx, const uint8_t signature[64],
const uint8_t public_key[32]);
void
crypto_check_update
(crypto_check_ctx
*ctx, const uint8_t *message,
size_t message_size);
int
crypto_check_final
(crypto_check_ctx
*ctx);
The arguments are the same as those described in crypto_sign(3monocypher).
This incremental interface can be used to sign or verify messages too large to fit in a single buffer. The arguments are the same as the direct interface described in crypto_sign(3monocypher).
The direct and incremental interface produce and accept the same signatures.
Signing is done in two passes. This requires five steps:
crypto_sign_init_first_pass
(). The public key is
optional and will be recomputed if not provided. This recomputation
doubles the execution time for short messages.crypto_sign_update
().
Under no circumstances must you forget the first pass.
Forgetting to call crypto_sign_update
() will
appear to work in that it produces valid signatures but also loses all
security because attackers may now recover the secret key.crypto_sign_init_second_pass
().crypto_sign_update
().
The same update function is used for both passes.crypto_sign_final
().
This also wipes the context.Verification requires three steps:
crypto_check_init
().crypto_check_update
().crypto_check_final
().crypto_sign_init_first_pass
(),
crypto_sign_init_second_pass
(),
crypto_sign_update
(),
crypto_sign_final
(),
crypto_check_init
(), and
crypto_check_update
() return nothing.
crypto_check_final
() returns 0 for
legitimate messages and -1 for forgeries.
uint8_t sk [ 32]; /* Secret key */ const uint8_t pk [ 32]; /* Public key (optional) */ const uint8_t message [500]; /* Message to sign */ uint8_t signature[ 64]; /* Output signature */ crypto_sign_ctx ctx; arc4random_buf(sk, 32); crypto_sign_public_key(pk, sk); crypto_sign_init_first_pass((crypto_sign_ctx_abstract*)&ctx, sk, pk); /* Wipe the secret key if no longer needed */ crypto_wipe(sk, 32); for (size_t i = 0; i < 500; i += 100) { crypto_sign_update((crypto_sign_ctx_abstract*)&ctx, message + i, 100); } crypto_sign_init_second_pass((crypto_sign_ctx_abstract*)&ctx); for (size_t i = 0; i < 500; i += 100) { crypto_sign_update((crypto_sign_ctx_abstract*)&ctx, message + i, 100); } crypto_sign_final((crypto_sign_ctx_abstract*)&ctx, signature);
Check the above:
const uint8_t pk [ 32]; /* Public key */ const uint8_t message [500]; /* Message to sign */ const uint8_t signature[ 64]; /* Signature to check */ crypto_check_ctx ctx; crypto_check_init((crypto_sign_ctx_abstract*)&ctx, signature, pk); for (size_t i = 0; i < 500; i += 100) { crypto_check_update((crypto_sign_ctx_abstract*)&ctx, message + i, 100); } if (crypto_check_final((crypto_sign_ctx_abstract*)&ctx)) { /* Message is corrupted, abort processing */ } else { /* Message is genuine */ }
This interface can be used to mitigate attacks that leverage power
analysis and fault injection (glitching) – both of which require
physical access and appropriate equipment. We inject additional randomness
(at least 32 bytes) and enough all-zero padding to fill the hash function's
block size (128 bytes for both BLAKE2b and SHA-512). Note that
crypto_sign_init_first_pass
() already fills 32
bytes, so randomness and padding must fill 32 bytes less
than the block size (96 bytes for BLAKE2b and SHA-512). Access to a
cryptographically secure pseudo-random generator is a requirement for
effective side-channel mitigation. Signing a message with increased
power-related side-channel mitigations:
const uint8_t message [ 500]; /* Message to sign */ uint8_t sk [ 32]; /* Secret key */ const uint8_t pk [ 32]; /* Public key (optional) */ uint8_t signature[ 64]; /* Output signature */ uint8_t buf [128-32] = {0}; /* Mitigation buffer */ crypto_sign_ctx ctx; crypto_sign_ctx_abstract *actx = (crypto_sign_ctx_abstract *)&ctx; arc4random_buf(sk, 32); crypto_sign_public_key(pk, sk); arc4random_buf(buf, 32); /* The rest of buf MUST be zeroes. */ crypto_sign_init_first_pass(actx, sk, pk); crypto_sign_update (actx, buf, sizeof(buf)); crypto_sign_update (actx, message, 500); crypto_sign_init_second_pass(actx); crypto_sign_update (actx, message, 500); crypto_sign_final (actx, signature); crypto_wipe(buf, 32); /* Wipe the secret key if no longer needed */ crypto_wipe(sk, 32);
The example for side-channel mitigation follows the methodology outlined in I-D.draft-mattsson-cfrg-det-sigs-with-noise-02.
crypto_sign_init_first_pass
(),
crypto_sign_update
(),
crypto_sign_final
(),
crypto_sign_init_second_pass
(),
crypto_check_init
(),
crypto_check_update
(), and
crypto_check_final
() functions first appeared in
Monocypher 1.1.0.
Starting with Monocypher 2.0.5, modified signatures abusing the
inherent signature malleability property of EdDSA now cause a non-zero
return value of crypto_check_final
(); in prior
versions, such signatures would be accepted.
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.
crypto_check_final
(). Messages may be stored before
they are verified, but they cannot be trusted. Processing
untrusted messages increases the attack surface of the system. Doing so
securely is hard. Do not process messages before calling
crypto_check_final
().
When signing messages, the security considerations documented in crypto_sign(3monocypher) also apply. If power-related side-channels are part of your threat model, 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.
February 13, 2022 | Debian |