On Sat, 18 Mar 2023 06:54:37 GMT, Martin Balao <mba...@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
