RFR: 8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key [v2]

Martin Balao mbalao at openjdk.org
Fri Apr 11 23:38:26 UTC 2025


On Fri, 11 Apr 2025 21:28:30 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Martin Balao has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Algorithm and key size checking before derivation. Mechanism normalization for TLS.
>>  - Minor import adjustment.
>
> 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.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24526#discussion_r2040428987


More information about the security-dev mailing list