The KEM API has always been using only the private key on the decapsulator side:
Decapsulation, [{\displaystyle k':=\operatorname {Decap} ({\mathit {sk}},c')}] ,
OQS_STATUS (*decaps)(uint8_t *shared_secret, const uint8_t *ciphertext, const
uint8_t *secret_key);
Decap(enc, skR)
int crypto_kem_dec(
unsigned char *ss,
const unsigned char *ct,
const unsigned char *sk
)
KEM.Decapsulator<https://download.java.net/java/early_access/jdk25/docs/api/java.base/javax/crypto/KEM.Decapsulator.html>
newDecapsulator<https://download.java.net/java/early_access/jdk25/docs/api/java.base/javax/crypto/KEM.html#newDecapsulator(java.security.PrivateKey,java.security.spec.AlgorithmParameterSpec)>(PrivateKey<https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/security/PrivateKey.html>
privateKey,
AlgorithmParameterSpec<https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/security/spec/AlgorithmParameterSpec.html>
spec)
Thanks,
Weijun
On Dec 12, 2024, at 02:14, Daniel Jeliński <djelins...@gmail.com> wrote:
Hi Weijun,
I didn't read the entire RFC, but it looks to me that the Decap
function is run on the receiver side, and needs the receiver's private
and public key, both of which are generated by the receiver. Couldn't
our implementation of Decap take the key pair instead of taking the
secret key alone?
Regards,
Daniel
śr., 11 gru 2024 o 18:00 Wei-Jun Wang
<weijun.w...@oracle.com<mailto:weijun.w...@oracle.com>> napisał(a):
Hi Martin,
That’s how DH works. Unfortunately, DHKEM is not simply exposing DH in KEM API.
Its decapsulation function is defined as [1]
def Decap(enc, skR):
pkE = DeserializePublicKey(enc)
dh = DH(skR, pkE)
pkRm = SerializePublicKey(pk(skR))
kem_context = concat(enc, pkRm)
shared_secret = ExtractAndExpand(dh, kem_context)
return shared_secret
Here, the DH output is fed as IKM into a HKDF and the HKDF-Expand info contains
its own public key — pk(skR) — as a part.
Thanks,
Weijun
[1]
https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9180.html*name-dh-based-kem-dhkem__;Iw!!ACWV5N9M2RV99hQ!ONHrzy7dpSw4Ujf0pe9SQL8j-4q8fdxhdC44yYG8DQHju9vHZxooTzBxX6lOWndgrVdDMOJoHi2ewqOJmAGC6Q$
On Dec 11, 2024, at 09:44, Martin Balao <mba...@redhat.com> wrote:
Hi Weijun,
I am not familiar to this algorithm but the typical key-exchange APIs let you
generate a key pair first and, when you invoke the secret encapsulation
mechanism, you use your private key + your counter-part public key. Do you
think this could be the case here?
Regards,
Martin.-
On 12/10/24 00:07, Wei-Jun Wang wrote:
So are you suggesting there is no such a way?
I do notice that in NSS’s own HPKE implementation, the receiver needs to
provide both keys [1]:
SECStatus PK11_HPKE_SetupR(HpkeContext *cx, const SECKEYPublicKey *pkR,
SECKEYPrivateKey *skR,
const SECItem *enc, const SECItem *info);
Maybe they also don’t have a simple way to get pkR from skR.
Thanks,
Weijun
[1]
https://urldefense.com/v3/__https://github.com/nss-dev/nss/blob/e2f270997ff9364aebb688f49b7c28698b70f24d/lib/pk11wrap/pk11pub.h*L788__;Iw!!ACWV5N9M2RV99hQ!N-hg_2MBY8A7Xq5uANI019wCfwrtROskrREyxtRKa8WKXwKZEgtWe1TNH0sMsIFnn9aIkIUBUqOIp7KE$
<https://urldefense.com/v3/__https://github.com/nss-dev/nss/blob/e2f270997ff9364aebb688f49b7c28698b70f24d/lib/pk11wrap/pk11pub.h*L788__;Iw!!ACWV5N9M2RV99hQ!N-hg_2MBY8A7Xq5uANI019wCfwrtROskrREyxtRKa8WKXwKZEgtWe1TNH0sMsIFnn9aIkIUBUqOIp7KE$
>
On Dec 9, 2024, at 21:27, Francisco Ferrari Bihurriet <fferr...@redhat.com>
wrote:
Hi Wei-Jun,
As far as I know, public and private keys are different PKCS#11 objects,
each one with a different CK_OBJECT_HANDLE. See for example how
C_GenerateKeyPair [1] has two output parameters: CK_OBJECT_HANDLE_PTR
phPublicKey amd CK_OBJECT_HANDLE_PTR phPrivateKey.
NSS uses CKA_PUBLIC_KEY_INFO only when wrapping [2] / unwrapping [3]
(C_WrapKey / C_UnwrapKey) RSA-PSS keys (where it stores an ASN1-encoded
SubjectPublicKeyInfo with the algorithm OID and the DER encoding of the
public key).
Here [4] is how SunPKCS11 proceeds after calling C_GenerateKeyPair, by
creating two P11Key objects for each handle (P11PublicKey and
P11PrivateKey).
[1]https://urldefense.com/v3/__https://docs.oasis-open.org/pkcs11/pkcs11-base/v3.0/pkcs11-base-v3.0.html*_Toc29976704__;Iw!!ACWV5N9M2RV99hQ!OmuwCcv-dJsqSgUuLEW8yqzvuB4Qwj5ay4afqgvAfvn3DiGx9lz31XjKDuAt_LABjdrwdCT8FmTTLO6ARjM$
<https://urldefense.com/v3/__https://docs.oasis-open.org/pkcs11/pkcs11-base/v3.0/pkcs11-base-v3.0.html*_Toc29976704__;Iw!!ACWV5N9M2RV99hQ!OmuwCcv-dJsqSgUuLEW8yqzvuB4Qwj5ay4afqgvAfvn3DiGx9lz31XjKDuAt_LABjdrwdCT8FmTTLO6ARjM$>
[2]https://urldefense.com/v3/__https://github.com/nss-dev/nss/blob/NSS_3_101_RTM/lib/softoken/pkcs11c.c*L6038-L6039__;Iw!!ACWV5N9M2RV99hQ!OmuwCcv-dJsqSgUuLEW8yqzvuB4Qwj5ay4afqgvAfvn3DiGx9lz31XjKDuAt_LABjdrwdCT8FmTT9ztKx9Y$
<https://urldefense.com/v3/__https://github.com/nss-dev/nss/blob/NSS_3_101_RTM/lib/softoken/pkcs11c.c*L6038-L6039__;Iw!!ACWV5N9M2RV99hQ!OmuwCcv-dJsqSgUuLEW8yqzvuB4Qwj5ay4afqgvAfvn3DiGx9lz31XjKDuAt_LABjdrwdCT8FmTT9ztKx9Y$>
[3]https://urldefense.com/v3/__https://github.com/nss-dev/nss/blob/NSS_3_101_RTM/lib/softoken/pkcs11c.c*L6604-L6605__;Iw!!ACWV5N9M2RV99hQ!OmuwCcv-dJsqSgUuLEW8yqzvuB4Qwj5ay4afqgvAfvn3DiGx9lz31XjKDuAt_LABjdrwdCT8FmTTdVw8oI8$
<https://urldefense.com/v3/__https://github.com/nss-dev/nss/blob/NSS_3_101_RTM/lib/softoken/pkcs11c.c*L6604-L6605__;Iw!!ACWV5N9M2RV99hQ!OmuwCcv-dJsqSgUuLEW8yqzvuB4Qwj5ay4afqgvAfvn3DiGx9lz31XjKDuAt_LABjdrwdCT8FmTTdVw8oI8$>
[4]https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/jdk-25*1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java*L424-L431__;KyM!!ACWV5N9M2RV99hQ!OmuwCcv-dJsqSgUuLEW8yqzvuB4Qwj5ay4afqgvAfvn3DiGx9lz31XjKDuAt_LABjdrwdCT8FmTTozigB-E$
<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/jdk-25*1/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java*L424-L431__;KyM!!ACWV5N9M2RV99hQ!OmuwCcv-dJsqSgUuLEW8yqzvuB4Qwj5ay4afqgvAfvn3DiGx9lz31XjKDuAt_LABjdrwdCT8FmTTozigB-E$>
Regards,
--
Francisco
On 12/10/24 01:43, Wei-Jun Wang wrote:
Daniel suggested CKA_PUBLIC_KEY_INFO but it’s not available in NSS 3.101.
On Dec 9, 2024, at 08:07, Wei-Jun Wang <weijun.w...@oracle.com> wrote:
Hi PKCS #11 gurus,
DHKEM [1] requires a function
Pk(skX): The KEM public key corresponding to the KEM private key skX.
"The notation pk(skX), depending on its use and the KEM and its
implementation, is either the computation of the public key using the
private key, or just syntax expressing the retrieval of the public
key, assuming it is stored along with the private key object."
For the software side, I can calculate the public key [2] from the
private key. How can I do this in PKCS #11?
Thanks,
Weijun
[1]https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9180.html*name-notation__;Iw!!ACWV5N9M2RV99hQ!OmuwCcv-dJsqSgUuLEW8yqzvuB4Qwj5ay4afqgvAfvn3DiGx9lz31XjKDuAt_LABjdrwdCT8FmTT0-STk6s$
<https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9180.html*name-notation__;Iw!!ACWV5N9M2RV99hQ!OmuwCcv-dJsqSgUuLEW8yqzvuB4Qwj5ay4afqgvAfvn3DiGx9lz31XjKDuAt_LABjdrwdCT8FmTT0-STk6s$>
[2]https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/__;!!ACWV5N9M2RV99hQ!OmuwCcv-dJsqSgUuLEW8yqzvuB4Qwj5ay4afqgvAfvn3DiGx9lz31XjKDuAt_LABjdrwdCT8FmTTH8KrINU$
<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/__;!!ACWV5N9M2RV99hQ!OmuwCcv-dJsqSgUuLEW8yqzvuB4Qwj5ay4afqgvAfvn3DiGx9lz31XjKDuAt_LABjdrwdCT8FmTTH8KrINU$>
adca97b659d725b0dd320322297dcbd1b443a047/src/java.base/share/classes/
sun/security/ec/ECPrivateKeyImpl.java#L209
