Lines Matching +full:pre +full:- +full:stored

1 ML-KEM Design
4 This document covers OpenSSL-specific ML-KEM implementation details.
5 **ML-KEM** is specified in [FIPS 203], which includes comprehensive pseudo-code
8 ML-KEM Parameters & Functions
9 -----------------------------
15 The key management and KEM algorithm names are **ML-KEM-512**, **ML-KEM-768**
16 and **ML-KEM-1024**.
20 **ML-KEM** makes extensive use of four **SHA3** primitives: **SHA3-256**,
21 **SHA3-512**, **SHAKE128** and **SHAKE256**.
22 To improve **ML-KEM** execution performance, the EVP handles for these are
23 pre-fetched during **ML-KEM** key initialisation and stored with each key.
26 **ML-KEM** key is duplicated.
28 ML-KEM keys
29 -----------
31 **ML-KEM** is an asymmetric algorithm, and has both public and private keys.
33 agreement, the encoding (*wire-form*) of the public key is clearly defined and
36 It may be noted that the *wire-form* public key is "compressed".
38 of the storage required for ML-KEM public and private keys, the *wire-form* public
39 key, holds a 32-byte seed from which the the matrix is regenerated by the recipient
42 decoding the public key, and stored in memory in the internal form needed for
45 is also pre-computed and stored with the private key, and then need not be
48 possible to save space and compute the matrix elements *just-in-time*, as each
50 This is not currently implemented, and the matrix is pre-computed in full.
55 If we wanted to do *just-in-time* matrix computation for decapsulation, we'd
60 512 bytes in memory for ML-KEM-768, for the full matrix, instead of 512 bytes
61 for a just-in-time element).
71 The IETF voices interest in using the "seed-based" format (the 64-byte (*d*,
79 [FIPS 203] format, but it will be possible to use the "seed-based" private key
80 format by using the (currently test-only) deterministic *keygen* interface.
86 ------------------
92 **OSSL_PKEY_PARAM_ML_KEM_SEED** parameter to a 64-byte octet-string
93 (concatentation of the **d** and **z** values (32-bytes each) in that order).
96 -------
98 **ML-KEM** is meant to be a drop-in replacement for existing KEM algorithms.
101 - **EVP_PKEY_encapsulate_init()**,
102 - **EVP_PKEY_encapsulate()**,
103 - **EVP_PKEY_decapsulate_init()**, and
104 - **EVP_PKEY_decapsulate()**.
106 For the encapsulation operation, a test-only option exists to bypass the random
108 a pre-determined 32-byte random value, by setting of the
112 -------
114 The **ML-KEM** key management and KEM providers interface with the underlying
117 the values expected for the provider's ML-KEM variant (a pointer to the variant
118 parameters is stored with each key).
120 The underlying libcrypto **ML-KEM** APIs are not directly exposed to users,
124 ----------------------------
127 However, we avoid using a *value-barrier* to set the masks that perform
128 constant-time *select* between one of two values.
129 This avoids a 30-50% performance penalty and is expected to be robust even in
137 It should be noted that to avoid chosen-ciphertext attacks, the
139 shared secret (generated in constant-time whether synthetic or successfully
140 decrypted) whenever the input is a well-formed ciphertext.
143 functions fails, in that case all hope of constant-time computation is
145 of chosen-ciphertexts, so this should not be an issue).
153 <!-- Links  -->