The decoders in some cases failed to capture or propagate
information about what is being decoded, causing more work
happen to try unrelated decoders as a fallback.
We now try harder to keep track of the expected object (private key or
public key, if known), and the algorithm determined from the OID of a
PKCS8 object or SPKI. This leads in many cases to fewer decoder
invocations. With so many more algorithms now, trying every decoder
is increasingly best avoided.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26892)
- When a PKCS#8 has both seed and key cross check the implicit
rejection value |z|
- When an import (EVP_PKEY_fromdata call) provides both a private
and public key, fail if the redundant public key does not match
the copy in the private key.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26656)
- The main ASN.1 private key syntax is the one from Russ Housley's post
on the LAMPS list, subsequently amended to tag the seed instead of the
key (each of the three parameter sets will have a fixed size for the
`expandedKey`):
ML-DSA-PrivateKey ::= CHOICE {
seed [0] IMPLICIT OCTET STRING SIZE (64),
expandedKey OCTET STRING SIZE (1632 | 2400 | 3168)
both SEQUENCE {
seed OCTET STRING SIZE (64),
expandedKey OCTET STRING SIZE (1632 | 2400 | 3168) } }
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26639)
- Moved the codec code out of `ml_kem.c` into its own file in
the provider tree. Will be easier to share some code with
ML-DSA, and possible to use PROV_CTX, to do config lookups
directly in the functions doing the work.
- Update and fixes of the EVP_PKEY-ML-KEM(8) documentation, which
had accumulated some stale/inaccurate material, and needed new
text for the "prefer_seed" parameter.
- Test the "prefer_seed=no" behaviour.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/26569)
- On import, if a seed is provided, the keys are regenerated.
- The seed is exported as a separate "seed" parameter, when available.
The "ml-kem.retain_seed" parameter is also exported, when false.
- The seed is optionally dropped after key generation.
* When the "ml-kem.retain_seed" keygen parameter is set to zero.
* When the "ml-kem.retain_seed" keygen parameter is not set to 1,
and the "ml-kem.retain_seed" provider config property is set
explictly false.
- The exported private key parameter "priv" is always the FIPS 203 |dk|.
- Private key decoding from PKCS#8 produces a transient "seed-only" form
of the key, in which "retain_seed" is set to false when the
"ml-kem.retain_seed" provider config property is set explictly false.
The full key is generated during "load" and the seed is retained
or not as specified.
- Import honours the "ml-kem.retain_seed" parameter when specified, or
otherwise honours the provider's "ml-kem.retain_seed" property.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26512)
- Same UX as ML-KEM. The main ASN.1 private key syntax is the one from
Russ Housley's post on the LAMPS list, subsequently amended to tag the
seed instead of the key (each of the three parameter sets will have a
fixed size for the `expandedKey`):
ML-DSA-PrivateKey ::= CHOICE {
seed [0] IMPLICIT OCTET STRING SIZE (32),
expandedKey OCTET STRING SIZE (2560 | 4032 | 4896)
both SEQUENCE {
seed OCTET STRING SIZE (32),
expandedKey OCTET STRING SIZE (2560 | 4032 | 4896) } }
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26638)
At the moment the provider context is only available to
encoders that encrypt, but it is useful more generally.
A similar change has already been merged to "master" on the
decoder side, this is the mirror change for encoders. The
only significant difference is that PEM_ASN1_write_bio needed
to be "extended" (cloned) to allow it to pass the provider context
down to the `k2d` function it uses to encode the data.
I had to "hold my nose" and live with the random "20" added to the data
size in order to accomodate encryption with padding, which may produce
one more cipher block than the input length. This really should ask
the EVP layer about the block length of the cipher, and allocate the
right amount. This should be a separate fix for both the old
PEM_ASN1_write_bio() and the new PEM_ASN1_write_bio_ctx().
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/26475)
fix https://github.com/openssl/openssl/issues/25112
As defined in the C standard:
In all cases the argument is an int, the value of which shall
be representable as an unsigned char or shall equal the value
of the macro EOF. If the argument has any other value, the
behavior is undefined.
This is because they're designed to work with the int values returned
by getc or fgetc; they need extra work to handle a char value.
If EOF is -1 (as it almost always is), with 8-bit bytes, the allowed
inputs to the ctype.h functions are:
{-1, 0, 1, 2, 3, ..., 255}.
However, on platforms where char is signed, such as x86 with the
usual ABI, code like
char *p = ...;
... isspace(*p) ...
may pass in values in the range:
{-128, -127, -126, ..., -2, -1, 0, 1, ..., 127}.
This has two problems:
1. Inputs in the set {-128, -127, -126, ..., -2} are forbidden.
2. The non-EOF byte 0xff is conflated with the value EOF = -1, so
even though the input is not forbidden, it may give the wrong
answer.
Casting char inputs to unsigned char first works around this, by
mapping the (non-EOF character) range {-128, -127, ..., -1} to {128,
129, ..., 255}, leaving no collisions with EOF. So the above
fragment needs to be:
char *p = ...;
... isspace((unsigned char)*p) ...
This patch inserts unsigned char casts where necessary. Most of the
cases I changed, I compile-tested using -Wchar-subscripts -Werror on
NetBSD, which defines the ctype.h functions as macros so that they
trigger the warning when the argument has type char. The exceptions
are under #ifdef __VMS or #ifdef _WIN32. I left alone calls where
the input is int where the cast would obviously be wrong; and I left
alone calls where the input is already unsigned char so the cast is
unnecessary.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/25113)
Caolán McNamara
Simo Sorce
Bob Beck
Pauli
openssl-machine
Pauli
Eugene Syromiatnikov
Alen Yan
slontis
Daniel Frink
Tomas Mraz
Viktor Dukhovni
Richard Levitte
Taylor R Campbell
Jamie Cui