On Fri, 11 Apr 2025 23:36:17 GMT, Martin Balao <mba...@openjdk.org> wrote:
>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11HKDF.java line
>> 246:
>>
>>> 244: alg.equalsIgnoreCase("Generic")) {
>>> 245: return ki.keyType;
>>> 246: }
>>
>> What is this check for? It's not immediately clear to me why do we look up
>> the keyInfo using `alg` but then again to check to error out when the found
>> keyType is CKK_GENERIC_SECRET && alg not equals "Generic". This seems to
>> directly contradicts the special workaround for "TlsXXX" in my other PR?
>
> For the TlsXXX issue I check the pseudo-mechanism. That works if all
> algorithms are known to the map. I'll check how many we have and see what are
> the pros/cons of having them in the map. I prefer symmetric key algorithms to
> be in the map.
>
> The reason for the check you referred is to block deriving keys such as
> HmacSHA256, PBEWithHmacSHA224AndAES_256, etc. which are not the result of
> HKDF derivations, but of Mac and PBE derivation.
As far as I understand it, `HmacSHA256` is blocked, but not
`PBEWithHmacSHA224AndAES_256`.
### `HmacSHA256`
* Has an `HMACKeyInfo` entry with the following non-static fields:
* `KeyInfo.algo` = `"HmacSHA256"`
* `KeyInfo.keyType` = `CKK_GENERIC_SECRET`
* `KeyInfo.keyGenMech` = `CK_UNAVAILABLE_INFORMATION`
* `HMACKeyInfo.mech` = `CKM_SHA256_HMAC`
* `HMACKeyInfo.keyLen` = `256`
Given `ki.keyType` is `CKK_GENERIC_SECRET` and `alg` is `HmacSHA256`, in
`P11HKDF::getDerivedKeyType` it will enter the first `case` but not the `if`.
So it will finally throw the expected exception:
InvalidAlgorithmParameterException("A key of algorithm 'HmacSHA256' is not
valid for derivation.")
### `PBEWithHmacSHA224AndAES_256`
* Has an `AESPBEKeyInfo` entry with the following non-static fields:
* `KeyInfo.algo` = `"PBEWithHmacSHA224AndAES_256"`
* `KeyInfo.keyType` = `CKK_AES`
* `KeyInfo.keyGenMech` = `CK_UNAVAILABLE_INFORMATION`
* `PBEKeyInfo.kdfMech` = `CKM_PKCS5_PBKD2`
* `PBEKeyInfo.prfMech` = `CKP_PKCS5_PBKD2_HMAC_SHA224`
* `PBEKeyInfo.keyLen` = `256`
* `PBEKeyInfo.extraAttrs` = `new CK_ATTRIBUTE[] { CK_ATTRIBUTE.ENCRYPT_TRUE
}`
Given `ki.keyType` is `CKK_AES`, in `P11HKDF::getDerivedKeyType` it will enter
the first `case` and also the `if`, returning `CKK_AES`. Later, in
`P11KeyGenerator::checkKeySize(..., Token token)`,
`P11KeyGenerator::getSupportedRange` will return `null`, because
`ki.keyGenMech` is `CK_UNAVAILABLE_INFORMATION`. This will make
`P11KeyGenerator::checkKeySize(..., CK_MECHANISM_INFO range)` enter the
`default` case, and finally return the unmodified `keySize`. No exception is
thrown, unless I'm missing something.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2042766732
