On Thu, 2 Dec 2021 21:31:52 GMT, Martin Balao <mba...@openjdk.org> wrote:
>> As described in JDK-8271566 [1], this patch proposal is intended to fix a >> problem that arises when using DSA keys that have a 256-bits (or larger) G >> parameter for signatures (either signing or verifying). There were some >> incorrect assumptions and hard-coded length values in the code before. >> Please note that, for example, the tuple (2048, 256) for DSA is valid >> according to FIPS PUB 186-4. >> >> Beyond the specific issues in signatures, I decided to provide a broader >> solution and enable key parameter retrieval for other key types (EC, DH) >> when possible. This is, when the key is not sensitive. One thing that I >> should note here is that token keys (those that have the CKA_TOKEN attribute >> equal to 'true') are considered sensitive in this regard, at least by the >> NSS Software Token implementation. I don't have access to other vendor >> implementations but if there is any concern, we can adjust the constraint to >> NSS-only. However, I'm not sure which use-case would require to get private >> keys out of a real token, weakening its security. I'd be more conservative >> here and not query the values if not sure that it will succeed. >> >> No regressions found in jdk/sun/security/pkcs11. A new test added: >> LargerDSAKey. >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8271566 > > Martin Balao has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains six commits: > > - 8271566: DSA signature length value is not accurate in P11Signature > (Webrev.02 based) > - Merge branch 'master' into JDK-8271566 > - Revert 8271566: DSA signature length value is not accurate in P11Signature > - Revert P11Key static inner classes refactorings. > - P11Key static inner classes refactorings. > - 8271566: DSA signature length value is not accurate in P11Signature src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java line 126: > 124: boolean sensitive = false; > 125: boolean extractable = true; > 126: for (CK_ATTRIBUTE attr : attrs) { Just noticed this: add a check for non-null attrs? If null, skip the for-loop. ------------- PR: https://git.openjdk.java.net/jdk/pull/4961
