Re: the better slot?

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=20
same data structures.

Most NSS functions will try to move operations with two different keys=20
into the same slot when they are involved in the same operation. This=20
usually applies to things like key wrap/unwrap. I suspect the derive=20
call doesn't do that because the other key is passed in as part of the=20
derive function's parameters. We have a function that should help


/*
 =C2=A0* To do joint operations, we often need two keys in the same slot.
 =C2=A0* Usually the PKCS #11 wrappers handle this correctly (like for=20
PK11_WrapKey),
 =C2=A0* but sometimes the wrappers don't know about mechanism specific key=
s in
 =C2=A0* the Mechanism params. This function makes sure the two keys are in=
 the
 =C2=A0* same slot by copying one or both of the keys into a common slot. T=
his
 =C2=A0* functions makes sure the slot can handle the target mechanism. If=
=20
the copy
 =C2=A0* is warranted, this function will prefer to move the movingKey firs=
t,=20
then
 =C2=A0* the preferedKey. If the keys are moved, the new keys are returned =
in
 =C2=A0* newMovingKey and/or newPreferedKey. The application is responsible
 =C2=A0* for freeing those keys once the operation is complete.
 =C2=A0*/
SECStatus
PK11_SymKeysToSameSlot(CK_MECHANISM_TYPE mech,
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0CK_ATTRIBUTE_TYPE preferedOperation,
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0CK_ATTRIBUTE_TYPE movingOperation,
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0PK11SymKey *preferedKey, PK11SymKey *movingKey,
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0PK11SymKey **newPreferedKey, PK11SymKey=20
**newMovingKey)

Note, if the keys are not moved newPreferedKey and newMovingKey will be=20
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
>

--=20
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 e=
mail to [email protected].
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msg=
id/dev-tech-crypto/bf155cb4-57a8-44ce-acd9-54ba44d82c62%40redhat.com.