Separate entries with ",", ", ", "; " or a new line for
XN_FLAG_SEP_COMMA_PLUS, XN_FLAG_SEP_CPLUS_SPC, XN_FLAG_SEP_SPLUS_SPC
and XN_FLAG_SEP_MULTILINE, indenting every line for the last one.
Print long names for XN_FLAG_FN_LN, no name for XN_FLAG_FN_NONE and
pad names for XN_FLAG_FN_ALIGN, as OpenSSL does. XN_FLAG_FN_OID still
prints short names as wolfSSL has no OIDs for name attributes.
XN_FLAG_RFC2253 output changes from "CN=a, C=b" to "CN=a,C=b".
XN_FLAG_RFC2253 was defined as 1, the same bit as
ASN1_STRFLGS_ESC_2253, so a caller asking only for RFC 2253 escaping
also got the reversed DN order. OpenVPN master now calls
X509_NAME_print_ex() with XN_FLAG_SEP_CPLUS_SPC | XN_FLAG_FN_SN |
ASN1_STRFLGS_ESC_2253 | ASN1_STRFLGS_UTF8_CONVERT (fix for
CVE-2026-84790) and its ssl_testdriver failed against wolfSSL.
- Define XN_FLAG_RFC2253 and XN_FLAG_MULTILINE as OpenSSL does.
- Reverse the order only on XN_FLAG_DN_REV.
- Implement ASN1_STRFLGS_ESC_2253, ASN1_STRFLGS_ESC_CTRL and
ASN1_STRFLGS_ESC_MSB escaping as OpenSSL does.
- Write values byte for byte. An embedded NUL previously truncated
the value and copied uninitialized heap bytes into the BIO.
- Escaping can triple the value length. Reject lengths where the
buffer size would overflow.
Entries are still always separated by ", " and printed with their
short name. XN_FLAG_MULTILINE was 0xFFFF and behaved like
XN_FLAG_RFC2253; it now escapes control and non-ASCII bytes and does
not reverse the order.
A hardware key store holds keys with a lifetime of their own, and none of the
existing callbacks can manage them. WC_ALGO_TYPE_SETKEY and
WC_ALGO_TYPE_EXPORT_KEY are bound to a wolfCrypt key object and carry material
for that object's own use: neither can name a stored key, ask for one to be
created exportable, or make one outlive the object that used it. Wrapped keys
add a second reason, since a wrapped blob never becomes plaintext on this side
of the boundary at all.
Add a dedicated algorithm type covering the operations that manage a stored
key, whether or not they cross that boundary:
WC_KEYSTORE_IMPORT_PLAIN place plaintext key material into a slot
WC_KEYSTORE_EXPORT_PLAIN read a stored key back as plaintext
WC_KEYSTORE_IMPORT_WRAPPED unwrap a blob directly into a slot
WC_KEYSTORE_EXPORT_WRAPPED wrap a stored key back out
WC_KEYSTORE_DERIVE derive slot to slot without touching RAM
WC_KEYSTORE_DELETE destroy a stored key
WC_KEYSTORE_GET_INFO query what a slot holds
The plaintext pair is what most key stores outside the secure-element class
offer, and it is the shape wc_Pkcs11StoreKey() already implements privately:
that function takes a Pkcs11Token* rather than a devId, so an application using
it is bound to PKCS#11 even though the operation is generic. Devices that hold
keys which may never appear in plaintext decline the pair and offer only the
wrapped form.
Delete is deliberately separate from WC_ALGO_TYPE_FREE: freeing a wolfCrypt key
object must never destroy the hardware key it refers to.
A key reference is not a new naming scheme. It is the identifier
WOLF_PRIVATE_KEY_ID already uses, so the bytes that name a key here are the
bytes wc_ecc_init_id() or wc_AesInit_Id() take to bind an object to that key,
and the bytes read back from key->id afterwards. wolfCrypt copies them through
without inspection.
Two details come from building the NXP EdgeLock port against this surface,
which is what a design like this needs before it is fixed in place.
Every operation that creates a key takes keyType, because a key store has to
know what a key is for before it can set its permissions, and the material
does not always say. Raw bytes carry no metadata, and neither does a bare
RFC 3394 wrap, which is a pure data transformation. A vendor container that
carries its own property word stays authoritative over what it holds and
keyType is then a cross-check, which catches the right blob going into the
wrong kind of slot; a device must refuse a mismatch rather than silently
prefer one source. WC_KEYSTORE_KEY_NONE leaves the choice to the device. The
export operations take no keyType, since the key already exists and GET_INFO
reports it.
attrs travels with every creating operation for the same reason, but as a
source only. A format carrying no attributes of its own leaves attrs as the
device's only word on what the new key may do. A container that carries them
wins and attrs is ignored, and it cannot usefully be cross-checked there:
a container's attributes are inside the wrap and are not known until the key
exists, whereas keyType is checkable up front against the reference being
imported into. wc_KeyStore_GetInfo() is how a caller confirms what an import
produced.
keyType also fixes how plaintext material is encoded, so no further argument
is needed to say. A symmetric type takes the raw key bytes; an asymmetric type
takes DER, a private key as PKCS#8 PrivateKeyInfo and a public key as
SubjectPublicKeyInfo. Stating it matters: WC_KEYSTORE_KEY_ECC_SIGN and a byte
string do not otherwise say whether the bytes are a scalar, SEC1 or PKCS#8,
and two devices could each pick differently and both be defensible.
Keys that act on other keys need naming. Without WC_KEYSTORE_KEY_WRAP and
WC_KEYSTORE_KEY_DERIVE a device asked about a wrapping key can only answer
NONE, which is indistinguishable from an empty slot and defeats the point of
GET_INFO. Measured on hardware, a 256-bit wrapping key reported type 0 with
256 bits, which tells a caller nothing about what it may do with it. Both are
listed ahead of the algorithm types, since they name what a key acts on rather
than which algorithm it serves.
The algorithm types cover what the two other backends this was checked against
actually store. wc_Pkcs11StoreKey() handles RSA, ECC and ML-KEM today, and
wolfHSM's WH_KEY_ALGO_ENUM names RSA, ECC, Curve25519, Ed25519, ML-DSA, ML-KEM,
LMS and XMSS, so a shorter vocabulary would have left the facility unusable to
both for anything but symmetric keys.
An algorithm serving two purposes a key store grants separately is split, since
one key doing both is the key-separation problem and a caller has to be able to
ask for the narrower key. RSA and ECC are the only two: PKCS#11 carries
CKA_SIGN and CKA_DECRYPT independently for RSA, and CKA_SIGN against CKA_DERIVE
for ECC. wolfCrypt's own PKCS#11 layer honours that for ECC, selecting from the
ecc_key flags, but sets both CKA_DECRYPT and CKA_SIGN unconditionally for RSA
because no equivalent RsaKey flag exists; expressing the distinction here is
what would let that be tightened later. The remaining types serve one purpose
each and are not split. Signature use is listed before agreement or transport
use throughout.
Argument order follows one rule: two interchangeable control words are never
left adjacent, because a transposition between them compiles cleanly and
surfaces much later as an unrelated-looking failure. An earlier arrangement had
attrs and kdfType separated only by a pointer and a length, and swapping them
silently created a key without the exportable attribute, whose export then
failed two operations away from the mistake. Beyond that each control word sits
beside what it describes. wc_KeyStore_ImportPlain is the one place the two aims
collide and the first wins: attrs sits at the tail of every creating operation
rather than beside keyType, because WC_KEYSTORE_ATTR_EXPORTABLE and
WC_KEYSTORE_KEY_WRAP are both 1 and a swap would be silent. All three creating
operations therefore read keyRef, keyRefSz, keyType, then what they draw the
key from, then attrs.
kdfType refers to enum wc_KdfType, and WC_KDF_TYPE_NONE asks for the device's
own derivation, which is all many key stores offer.
Attributes are fixed when a key is created; hardware generally burns them in,
so there is no operation here to change them afterwards. They round-trip: a
device that can represent one must report it back through GET_INFO, so a caller
can ask whether an export is permitted rather than attempting one and
interpreting the error. Attributes the device cannot represent read as absent,
and out parameters it does not fill are cleared rather than left holding the
caller's stack.
Gated behind WOLF_CRYPTO_CB_KEYSTORE, with tests in wolfcrypt/test and
tests/api that assert each operation reaches the device carrying the arguments
the caller passed, not merely that the call returned zero.
tests/api/test_tls_bounds.c: fix a residual null deref error path, and an introduced error path leak.
wolfcrypt/src/sha256.c: in Transform_Sha256(), accommodate WOLFSSL_WIDE_BYTE in data copy-in using original construction (no readUnalignedWord32()).
wolfcrypt/test/test.c:
* fix sequence in mldsa_param_test() so that the new NULL payload test follows the last existing test making use of the established sig.
* add missing NULL payload test to xmss_test().
and wolfcrypt/test/test.c: accept the empty message, passed as (NULL, 0), in all
sign and verify entry points -- RFCs 8032, 8554, and 8391, and FIPS 204, 205,
and (pending) 206, all permit empty messages (in fact RFC 8032's first test
vector is for the empty message). Guards now reject a NULL message only with a
nonzero length (wc_XmssKey_Verify()/wc_XmssKey_Sign() additionally had an
off-by-one, rejecting mLen == 0 outright, unlike their LMS siblings); after
validation, a NULL message is canonicalized to a readable stand-in so downstream
consumers -- hash updates and crypto callbacks -- never see a NULL pointer.
wc_ed448_verify_msg_ex() additionally gains previously absent validation of sig
and res, which were dereferenced unchecked.
Add empty-message sign/verify roundtrips to lms_test() (spending one of the 2**5
signatures; the exhaustion loop drops to 31 iterations), xmss_test(),
mldsa_param_test(), slhdsa_test_param() (fast 128f set only -- the code path is
parameter-independent and "s"-set signing is costly), and falcon_test(). Add
(NULL, 0) sign/verify probes to ed25519_test() and ed448_test(), pinned
byte-identical to the existing (msg, 0) known answers (EdDSA is deterministic).
tests/api/test_lms_xmss.c: fix test_wc_XmssDecisionCoverage() to probe mLen < 0,
not mLen <= 0, consistent with preexisting probes in
test_wc_LmsDecisionCoverage().
wc_CryptoCb_Curve25519MakePub took no devId and resolved its device with a
lookup for INVALID_DEVID, falling back to the first registered device. Every
route to an X25519 public point derivation went through it, so a key bound to
one device had its private scalar offered to whichever device happened to be
registered first, with no way to opt out.
Give both wc_CryptoCb_Curve25519MakePub and wc_CryptoCb_Curve25519Generic a
devId parameter and let only a caller that selected no device settle for the
first registered one, matching the curve448 siblings. wc_curve25519_make_key
and wc_curve25519_export_public_ex now derive the point through a devId
carrying helper that reaches the callback only when the key names a device.
The keyless public API has no key to take a devId from, so it offers the
scalar to wc_CryptoCb_DefaultDevID() and keeps its old behaviour, while
honouring WC_NO_DEFAULT_DEVID.
Under WOLFSSL_CURVE25519_BLINDING both wc_curve25519_make_pub and
wc_curve25519_generic fall through to their blinded variant after the
callback declined, which dispatched the same private scalar to the same
device a second time. The fall-through now calls the software half of the
blinded derivation directly, so a declining device is offered the scalar
once.
Under WOLF_CRYPTO_CB_ONLY_CURVE25519 an unbound key passed to
wc_curve25519_export_public_ex now returns NO_VALID_DEVID rather than
reaching the first registered device. Such builds must create keys with
wc_curve25519_init_ex and a real devId.
RFC 9846, 5.5
CheckTLS13AEADSendLimit(): at the AEAD limit while sending early data,
return TOO_MUCH_EARLY_DATA instead of calling Tls13UpdateKeys(). A KeyUpdate
there would go out pre-handshake.
RFC 9846, 6.1
Three alert sites in DoAlert() / DoProcessAlertRecord(): TLS 1.3
user_canceled is now exempt from teardown and session invalidation at any
AlertLevel, not just warning. TLS 1.2 unchanged.
RFC 9846, 4.7.3
New Tls13KeyUpdateLimitReached() helper shared by send and receive
paths. At the 2^48-1 cap, DoTls13KeyUpdate() drops a peer's update_requested
and continues, rather than failing the connection. App-initiated
wolfSSL_update_keys() still returns BAD_STATE_E.
RFC 9846, 4.3
TranslateErrorToAlert() maps BUFFER_E to decode_error as well as
BUFFER_ERROR — one case label covering 27 malformed-extension sites that
previously aborted with no alert sent.
Tests added.
wolfSSL_PKCS7_encode_certs takes the stack only on success. These tests
dropped sk whenever p7 and the BIO were non-NULL, which leaked under
MEM_FAIL_CNT.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
- wolfSSL_BN_rand() calls mp_rshb() only when bits is not a
multiple of 8.
- test_wolfSSL_BN_rand() declares i and seen, and samples 8-bit
TOP_ANY, 16-bit TOP_ANY, and 8-bit TOP_ONE requests to assert
the results are not confined to the low byte.
Issue: F-12559
philljj
Paul Adelsbach
Reda Chouk
Tobias Frauenschläger
Juliusz Sosinowicz
Sean Parkinson
Daniel Pouzzner
JacobBarthelmeh
Marco Oliverio
kaleb-himes
Sameeh Jubran
Josh Holtrop
Yosuke Shimizu