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> 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://www.rfc-editor.org/rfc/rfc9180.html#name-dh-based-kem-dhkem
>
>
> 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
>
>
>

Reply via email to