RFR: 8301553: Support Password-Based Cryptography in SunPKCS11 [v2]

Tue Mar 21 21:25:50 UTC 2023

On Sat, 18 Mar 2023 06:54:37 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> Good question. Looks like a bug. The values should probably be 224 and 256 respectively (output sizes). @franferrax what do you think? We can trace the CKA_VALUE_LEN for these mechanisms in the NSS Software Token to verify it. Also, we should explore if it's possible to add a test for HmacPBESHA512/224 and HmacPBESHA512/256 to TestPBKD. I'll make the change but leave this comment open until we further explore.
>
> I just realized that the underlying native mechanism is the same so I'm not even sure that the NSS Software Token will truncate the output as we expect. This reinforces the need for further exploration and testing. We may need to remove support for these algorithms.

We've given it another look, and realized that in fact this was left there by mistake. I initially thought that we could implement those algorithms by just truncating the `CKM_NSS_PKCS12_PBE_SHA512_HMAC_KEY_GEN` derivation output from `512` to `224` or `256` bits, but never moved ahead with that implementation.

This [chosen `keyLen` divided by `8` ends up passed as the `CKA_VALUE_LEN` attribute](https://github.com/openjdk/jdk/blob/ab7ffd56bb8b93d513023d0136df55a6375c3286/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L421), which the PKCS <span>#</span>11 token can ignore and just use `64` (`512 / 8`), given the mechanism itself indicates the key length. NSS does this, see [`pkcs11c.c:4655-4659`](https://github.com/nss-dev/nss/blob/NSS_3_85_RTM/lib/softoken/pkcs11c.c#L4655-L4659) and [`pkcs11c.c:4421`](https://github.com/nss-dev/nss/blob/NSS_3_85_RTM/lib/softoken/pkcs11c.c#L4421). So changing `512` to `224` or `256` doesn't have any effect.

On the other hand, re-checking this, even if I had developed truncation of the derived key, it wouldn't have worked, because is the output of the pseudo-random hash function what should be truncated instead, in every iteration and step of the derivation.

For this reason, we decided to remove the `HmacPBESHA512/224` and `HmacPBESHA512/256` algorithms from the proposal.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12396#discussion_r1144002498