On 5/27/26 6:47 PM, Andrew Cagney wrote:
I think I've managed to track down why a machine was failing ML_KEM in
libreswan, but it brings up several questions.
First the libreswan bug:
- the IKE_SA_INIT exchange generates a KE DH secret
- this secret is fed into the KDF which returns keymat and a key D
with slot A (I'm not sure where that slot came from)
- the IKE_INTERMEDIATE exchange generates an ADDKE ML_KEM secret with
an ML_KEM slot
- D+ADDKE are then fed into the KDF (CKM_NSS_IKE_PRF_DERIVE) which
barfs (fails gracefully) because ADDKE (.hNewKey) isn't in D's slot
Presumably the fix is to get both D and ADDKE on the same slot:
Q.1 But which is the better slot? D or the one that was for ML_KEM?
Q.2 Why would we only encounter the problem on one machine?
More broadly:
Do slots have any (multi threaded) performance implications?
There shouldn't be. Under the covers in softoken they share most of the
same data structures.
Most NSS functions will try to move operations with two different keys
into the same slot when they are involved in the same operation. This
usually applies to things like key wrap/unwrap. I suspect the derive
call doesn't do that because the other key is passed in as part of the
derive function's parameters. We have a function that should help
/*
* To do joint operations, we often need two keys in the same slot.
* Usually the PKCS #11 wrappers handle this correctly (like for
PK11_WrapKey),
* but sometimes the wrappers don't know about mechanism specific keys in
* the Mechanism params. This function makes sure the two keys are in the
* same slot by copying one or both of the keys into a common slot. This
* functions makes sure the slot can handle the target mechanism. If
the copy
* is warranted, this function will prefer to move the movingKey first,
then
* the preferedKey. If the keys are moved, the new keys are returned in
* newMovingKey and/or newPreferedKey. The application is responsible
* for freeing those keys once the operation is complete.
*/
SECStatus
PK11_SymKeysToSameSlot(CK_MECHANISM_TYPE mech,
CK_ATTRIBUTE_TYPE preferedOperation,
CK_ATTRIBUTE_TYPE movingOperation,
PK11SymKey *preferedKey, PK11SymKey *movingKey,
PK11SymKey **newPreferedKey, PK11SymKey
**newMovingKey)
Note, if the keys are not moved newPreferedKey and newMovingKey will be
NULL.
For
instance, in the above, I've a suspicion that D's slot is being shared
across threads and is very long lived
Andrew
--
You received this message because you are subscribed to the Google Groups
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-tech-crypto/bf155cb4-57a8-44ce-acd9-54ba44d82c62%40redhat.com.
