forked from Yasushi/putty
-
Notifications
You must be signed in to change notification settings - Fork 7
/
Copy pathmlkem.h
89 lines (82 loc) · 3.55 KB
/
mlkem.h
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
/*
* Internal functions for the ML-KEM cryptosystem, exposed in a header
* that is expected to be included only by mlkem.c and test programs.
*/
#ifndef PUTTY_CRYPTO_MLKEM_H
#define PUTTY_CRYPTO_MLKEM_H
typedef struct mlkem_params mlkem_params;
extern const mlkem_params mlkem_params_512;
extern const mlkem_params mlkem_params_768;
extern const mlkem_params mlkem_params_1024;
/*
* ML-KEM key generation.
*
* The official spec gives two APIs for this function: an outer one
* that invents random data from an implicit PRNG parameter, and an
* inner one that takes the randomness as explicit input for running
* test vectors.
*
* To make side-channel testing easier, I introduce a third API inside
* the latter. The spec's "inner" function takes a parameter 'd'
* containing 32 bytes of randomness, which it immediately expands
* into a 64-byte hash and then uses the two halves of that hash for
* different purposes. My even-more-inner function expects the caller
* to have done that hashing already, and to present the two 32-byte
* half-hashes rho and sigma separately.
*
* Rationale: it would be difficult to make the keygen running time
* independent of rho, becase the required technique for constructing
* a matrix from rho uses rejection sampling, so timing will depend on
* how many samples were rejected. Happily, it's also not _necessary_
* to make the timing independent of rho, because rho is part of the
* _public_ key, so it's sent in clear over the wire anyway. So for
* testsc purposes, it's convenient to regard rho as fixed and vary
* sigma, so that the timing variations due to rho don't show up as
* failures in the test.
*
* Inputs: 'd', 'z', 'rho' and 'sigma' are all 32-byte random strings.
*
* Return: the encryption and decryption keys are written to the two
* provided BinarySinks.
*/
void mlkem_keygen(
BinarySink *ek, BinarySink *dk, const mlkem_params *params);
void mlkem_keygen_internal(
BinarySink *ek, BinarySink *dk, const mlkem_params *params,
const void *d, const void *z);
void mlkem_keygen_rho_sigma(
BinarySink *ek, BinarySink *dk, const mlkem_params *params,
const void *rho, const void *sigma, const void *z);
/*
* ML-KEM key encapsulation, with only two forms, the outer (random)
* and inner (for test vectors) versions from the spec.
*
* Inputs: the encryption key from keygen. 'm' should be a 32-byte
* random string if provided.
*
* Returns: if successful, returns true, and writes to the two
* BinarySinks a ciphertext to send to the other side, and our copy of
* the output shared secret k. If failure, returns false, and the
* strbuf pointers aren't filled in at all.
*/
bool mlkem_encaps(BinarySink *ciphertext, BinarySink *kout,
const mlkem_params *params, ptrlen ek);
bool mlkem_encaps_internal(BinarySink *ciphertext, BinarySink *kout,
const mlkem_params *params, ptrlen ek,
const void *m);
/*
* ML-KEM key decapsulation. This doesn't use any randomness, so even
* the official spec only presents one version of it. (Actually it
* defines two functions, but the outer one adds nothing over the
* inner one.)
*
* Inputs: the decryption key from keygen, and the ciphertext output
* from encapsulation.
*
* Returns: false on validation failure, and true otherwise
* (regardless of whether the ciphertext was implicitly rejected). The
* shared secret k is written to the provided BinarySink.
*/
bool mlkem_decaps(BinarySink *k, const mlkem_params *params,
ptrlen dk, ptrlen c);
#endif /* PUTTY_CRYPTO_MLKEM_H */