Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v9]
> It's been several years since we increased the default key sizes. Before > shifting to PQC, NSA replaced its Suite B cryptography recommendations with > the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures > (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. > The changes are mostly in keytool, jarsigner and their regression tests, so > @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Use uppercase for 1st letter in some comments. - Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/a48ccef5..8b7bc16a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7652=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7652=07-08 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v8]
On Thu, 24 Mar 2022 06:41:11 GMT, Xue-Lei Andrew Fan wrote: >> Valerie Peng has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Added comment regarding possible deadlocks. > > src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java > line 137: > >> 135: public static final int DEF_ED_KEY_SIZE; >> 136: public static final int DEF_XEC_KEY_SIZE; >> 137: // the logic for finding the max allowable value in >> getDefAESKeySize() > > Capital the 1st letter? Ok~ - PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7]
On Wed, 23 Mar 2022 21:59:02 GMT, Valerie Peng wrote: >> I see. >> >> Would you mind add a comment about the provider loading impact, just in case >> someone else have similar questions in the future? > > Sure, I can do that. Will add a comment about this. Thank you. I have no more comment except a minor nit. - PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v8]
On Wed, 23 Mar 2022 22:48:41 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before >> shifting to PQC, NSA replaced its Suite B cryptography recommendations with >> the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384 for secure hashing >> - AES-256 for symmetric encryption >> - RSA with 3072 bit keys for digital signatures and for key exchange >> - Diffie Hellman (DH) with 3072 bit keys for key exchange >> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures >> (ECDSA) >> >> So, this proposed changes made the suggested key size and algorithm changes. >> The changes are mostly in keytool, jarsigner and their regression tests, so >> @wangweij Could you please take a look? >> >> Thanks! > > Valerie Peng has updated the pull request incrementally with one additional > commit since the last revision: > > Added comment regarding possible deadlocks. Looks good to me. Thanks! src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java line 137: > 135: public static final int DEF_ED_KEY_SIZE; > 136: public static final int DEF_XEC_KEY_SIZE; > 137: // the logic for finding the max allowable value in > getDefAESKeySize() Capital the 1st letter? - Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v8]
> It's been several years since we increased the default key sizes. Before > shifting to PQC, NSA replaced its Suite B cryptography recommendations with > the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures > (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. > The changes are mostly in keytool, jarsigner and their regression tests, so > @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Added comment regarding possible deadlocks. - Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/1eb63292..a48ccef5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7652=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7652=06-07 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7]
On Wed, 23 Mar 2022 21:51:51 GMT, Xue-Lei Andrew Fan wrote: >> My very first prototype is to implement the AES keysize calculation as you >> commented, i.e. in the static block and use an int for DEF_AES_KEY_SIZE. >> However, it is later discovered through testing that this leads to deadlocks >> as this interferes with provider loading. Given that AES key size is just a >> small piece of the whole puzzle, it seems safer to defer this to a later >> point when it's actually needed rather than touching the whole provider >> loading logic just to make this a static int. Performance-wise, this is a >> very small piece, generally should just be the AtomicInteger.get(). > > I see. > > Would you mind add a comment about the provider loading impact, just in case > someone else have similar questions in the future? Sure, I can do that. Will add a comment about this. - PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7]
On Wed, 23 Mar 2022 20:45:22 GMT, Valerie Peng wrote: >> src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java >> line 129: >> >>> 127: return currVal; >>> 128: } >>> 129: >> >> I'm not very sure of this method. Is it performance friendly if making the >> default key size calculation in the static block (from line 142 to the end >> of the file)? Then, the DEF_AES_KEY_SIZE could be a public primitive int. >> >> Or did I miss something? > > My very first prototype is to implement the AES keysize calculation as you > commented, i.e. in the static block and use an int for DEF_AES_KEY_SIZE. > However, it is later discovered through testing that this leads to deadlocks > as this interferes with provider loading. Given that AES key size is just a > small piece of the whole puzzle, it seems safer to defer this to a later > point when it's actually needed rather than touching the whole provider > loading logic just to make this a static int. Performance-wise, this is a > very small piece, generally should just be the AtomicInteger.get(). I see. Would you mind add a comment about the provider loading impact, just in case someone else have similar questions in the future? - PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7]
On Wed, 23 Mar 2022 04:46:48 GMT, Xue-Lei Andrew Fan wrote: >> Valerie Peng has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Minor code refactoring > > src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java > line 129: > >> 127: return currVal; >> 128: } >> 129: > > I'm not very sure of this method. Is it performance friendly if making the > default key size calculation in the static block (from line 142 to the end of > the file)? Then, the DEF_AES_KEY_SIZE could be a public primitive int. > > Or did I miss something? My very first prototype is to implement the AES keysize calculation as you commented, i.e. in the static block and use an int for DEF_AES_KEY_SIZE. However, it is later discovered through testing that this leads to deadlocks as this interferes with provider loading. Given that AES key size is just a small piece of the whole puzzle, it seems safer to defer this to a later point when it's actually needed rather than touching the whole provider loading logic just to make this a static int. Performance-wise, this is a very small piece, generally should just be the AtomicInteger.get(). - PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7]
On Tue, 22 Mar 2022 21:25:28 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before >> shifting to PQC, NSA replaced its Suite B cryptography recommendations with >> the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384 for secure hashing >> - AES-256 for symmetric encryption >> - RSA with 3072 bit keys for digital signatures and for key exchange >> - Diffie Hellman (DH) with 3072 bit keys for key exchange >> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures >> (ECDSA) >> >> So, this proposed changes made the suggested key size and algorithm changes. >> The changes are mostly in keytool, jarsigner and their regression tests, so >> @wangweij Could you please take a look? >> >> Thanks! > > Valerie Peng has updated the pull request incrementally with one additional > commit since the last revision: > > Minor code refactoring src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java line 129: > 127: return currVal; > 128: } > 129: I'm not very sure of this method. Is it performance friendly if making the default key size calculation in the static block (from line 142 to the end of the file)? Then, the DEF_AES_KEY_SIZE could be a public primitive int. Or did I miss something? src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java line 137: > 135: public static final int DEF_ED_KEY_SIZE; > 136: public static final int DEF_XEC_KEY_SIZE; > 137: private static final AtomicInteger DEF_AES_KEY_SIZE; See the previous comment, maybe it could be `public static final int DEF_AES_KEY_SIZE.` - PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7]
On Tue, 22 Mar 2022 21:25:28 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before >> shifting to PQC, NSA replaced its Suite B cryptography recommendations with >> the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384 for secure hashing >> - AES-256 for symmetric encryption >> - RSA with 3072 bit keys for digital signatures and for key exchange >> - Diffie Hellman (DH) with 3072 bit keys for key exchange >> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures >> (ECDSA) >> >> So, this proposed changes made the suggested key size and algorithm changes. >> The changes are mostly in keytool, jarsigner and their regression tests, so >> @wangweij Could you please take a look? >> >> Thanks! > > Valerie Peng has updated the pull request incrementally with one additional > commit since the last revision: > > Minor code refactoring Everything looks fine to me. - Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7]
> It's been several years since we increased the default key sizes. Before > shifting to PQC, NSA replaced its Suite B cryptography recommendations with > the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures > (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. > The changes are mostly in keytool, jarsigner and their regression tests, so > @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Minor code refactoring - Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/c8ae1655..1eb63292 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7652=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7652=05-06 Stats: 20 lines in 1 file changed: 1 ins; 7 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v6]
On Tue, 15 Mar 2022 20:51:25 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before >> shifting to PQC, NSA replaced its Suite B cryptography recommendations with >> the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384 for secure hashing >> - AES-256 for symmetric encryption >> - RSA with 3072 bit keys for digital signatures and for key exchange >> - Diffie Hellman (DH) with 3072 bit keys for key exchange >> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures >> (ECDSA) >> >> So, this proposed changes made the suggested key size and algorithm changes. >> The changes are mostly in keytool, jarsigner and their regression tests, so >> @wangweij Could you please take a look? >> >> Thanks! > > Valerie Peng has updated the pull request incrementally with one additional > commit since the last revision: > > Removed NPE from the catch statement. Could you please please review CSR at: https://bugs.openjdk.java.net/browse/JDK-8282995 Thanks! - PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5]
On Tue, 15 Mar 2022 20:44:20 GMT, Valerie Peng wrote:
>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java
>> line 122:
>>
>>> 120: default -> {
>>> 121: throw new ProviderException
>>> 122: ("Unrecognized algorithm for checking key
>>> size");
>>
>> If it's an unknown key algorithm, is it possible we just ignore it and keep
>> using `minKeyLen` and `maxKeyLen`?
>
> Well, instead of ignore unknown key algorithm, perhaps safer to throw
> Exception so it can be caught and handled during develop time.
> P11KeyPairGenerator class is only used for known algorithms which it is
> registered for, so probably ok to go either way. I'd prefer to play it safe
> and force a review of this block of code when new algorithm is added.
OK.
-
PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v6]
> It's been several years since we increased the default key sizes. Before > shifting to PQC, NSA replaced its Suite B cryptography recommendations with > the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures > (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. > The changes are mostly in keytool, jarsigner and their regression tests, so > @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Removed NPE from the catch statement. - Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/48f562ab..c8ae1655 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7652=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7652=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5]
On Mon, 14 Mar 2022 21:24:15 GMT, Weijun Wang wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update again and undo DSA changes
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java
> line 122:
>
>> 120: default -> {
>> 121: throw new ProviderException
>> 122: ("Unrecognized algorithm for checking key
>> size");
>
> If it's an unknown key algorithm, is it possible we just ignore it and keep
> using `minKeyLen` and `maxKeyLen`?
Well, instead of ignore unknown key algorithm, perhaps safer to throw Exception
so it can be caught and handled during develop time. P11KeyPairGenerator class
is only used for known algorithms which it is registered for, so probably ok to
go either way. I'd prefer to play it safe and force a review of this block of
code when new algorithm is added.
-
PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5]
On Mon, 14 Mar 2022 21:18:56 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update again and undo DSA changes > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java > line 101: > >> 99: // set default key sizes and apply our own algorithm-specific >> limits >> 100: // override lower limit to disallow unsecure keys being >> generated >> 101: // override upper limit to deter DOS attack > > Not a P11 expert, but I assume `algorithm` here is already guaranteed to be > in uppercase? Yes, for P11KeyPairGenerator, its algorithm values are all in uppercase. I verified it with an existing regression test. - PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5]
On Mon, 14 Mar 2022 21:08:30 GMT, Weijun Wang wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update again and undo DSA changes
>
> src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java
> line 121:
>
>> 119: v = max;
>> 120: }
>> 121: } catch (NullPointerException | NoSuchAlgorithmException
>> ne) {
>
> There is no need to mention NPE.
Sure.
-
PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5]
On Mon, 14 Mar 2022 20:08:31 GMT, Valerie Peng wrote:
>> It's been several years since we increased the default key sizes. Before
>> shifting to PQC, NSA replaced its Suite B cryptography recommendations with
>> the Commercial National Security Algorithm Suite which suggests:
>>
>> - SHA-384 for secure hashing
>> - AES-256 for symmetric encryption
>> - RSA with 3072 bit keys for digital signatures and for key exchange
>> - Diffie Hellman (DH) with 3072 bit keys for key exchange
>> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures
>> (ECDSA)
>>
>> So, this proposed changes made the suggested key size and algorithm changes.
>> The changes are mostly in keytool, jarsigner and their regression tests, so
>> @wangweij Could you please take a look?
>>
>> Thanks!
>
> Valerie Peng has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update again and undo DSA changes
Some small comments. Otherwise looks fine.
src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java
line 121:
> 119: v = max;
> 120: }
> 121: } catch (NullPointerException | NoSuchAlgorithmException ne)
> {
There is no need to mention NPE.
src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java
line 101:
> 99: // set default key sizes and apply our own algorithm-specific
> limits
> 100: // override lower limit to disallow unsecure keys being generated
> 101: // override upper limit to deter DOS attack
No a P11 expert, but I assume `algorithm` here is already guaranteed to be in
uppercase?
src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java
line 122:
> 120: default -> {
> 121: throw new ProviderException
> 122: ("Unrecognized algorithm for checking key size");
If it's an unknown key algorithm, is it possible we just ignore it and keep
using `minKeyLen` and `maxKeyLen`?
-
PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5]
> It's been several years since we increased the default key sizes. Before > shifting to PQC, NSA replaced its Suite B cryptography recommendations with > the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures > (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. > The changes are mostly in keytool, jarsigner and their regression tests, so > @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Update again and undo DSA changes - Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/f728aa7d..48f562ab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7652=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7652=03-04 Stats: 45 lines in 9 files changed: 8 ins; 2 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v4]
> It's been several years since we increased the default key sizes. Before > shifting to PQC, NSA replaced its Suite B cryptography recommendations with > the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures > (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. > The changes are mostly in keytool, jarsigner and their regression tests, so > @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Updated to match the latest SignatureUtil.ifcFfcStrength() impl - Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/099a6d92..f728aa7d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7652=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7652=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v3]
On Wed, 9 Mar 2022 19:44:39 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update JarSigner javadoc to make it consistent with previous update > > src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java line 439: > >> 437: * Specifically, if a DSA or RSA key with a key size no less >> than 7680 >> 438: * bits, or an EC key with a key size no less than 512 bits, >> 439: * SHA-512 will be used as the hash function for the signature. > > In this javadoc, SHA-512 for 7680-bit key (7680 is no less than 7680). Right, there are a few places which this is documented. Code and doc aren't closely coupled together plus changed course a few times... I will fix this and double check other files. Thanks! - PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v3]
On Wed, 9 Mar 2022 19:15:36 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before >> shifting to PQC, NSA replaced its Suite B cryptography recommendations with >> the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384 for secure hashing >> - AES-256 for symmetric encryption >> - RSA with 3072 bit keys for digital signatures and for key exchange >> - Diffie Hellman (DH) with 3072 bit keys for key exchange >> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures >> (ECDSA) >> >> So, this proposed changes made the suggested key size and algorithm changes. >> The changes are mostly in keytool, jarsigner and their regression tests, so >> @wangweij Could you please take a look? >> >> Thanks! > > Valerie Peng has updated the pull request incrementally with one additional > commit since the last revision: > > Update JarSigner javadoc to make it consistent with previous update Sorry if my previous comment confused you, the code and javadoc are not consistent now. src/java.base/share/classes/sun/security/util/SignatureUtil.java line 561: > 559: return (isDSA || bitLength >= 624 ? "SHA384" : "SHA256"); > 560: } > 561: } In this method, "SHA-384" for 7680-bit key (7680 > 7680 is false). src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java line 439: > 437: * Specifically, if a DSA or RSA key with a key size no less > than 7680 > 438: * bits, or an EC key with a key size no less than 512 bits, > 439: * SHA-512 will be used as the hash function for the signature. In this javadoc, SHA-512 for 7680-bit key (7680 is no less than 7680). - PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v3]
> It's been several years since we increased the default key sizes. Before > shifting to PQC, NSA replaced its Suite B cryptography recommendations with > the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures > (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. > The changes are mostly in keytool, jarsigner and their regression tests, so > @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Update JarSigner javadoc to make it consistent with previous update - Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/7f6fe4b5..099a6d92 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7652=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7652=01-02 Stats: 16 lines in 2 files changed: 0 ins; 3 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v2]
On Wed, 9 Mar 2022 02:02:51 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before >> shifting to PQC, NSA replaced its Suite B cryptography recommendations with >> the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384 for secure hashing >> - AES-256 for symmetric encryption >> - RSA with 3072 bit keys for digital signatures and for key exchange >> - Diffie Hellman (DH) with 3072 bit keys for key exchange >> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures >> (ECDSA) >> >> So, this proposed changes made the suggested key size and algorithm changes. >> The changes are mostly in keytool, jarsigner and their regression tests, so >> @wangweij Could you please take a look? >> >> Thanks! > > Valerie Peng has updated the pull request incrementally with one additional > commit since the last revision: > > Updated to use SHA-384 as long as the keysize permits. The `JarSigner` API is not updated. - PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v2]
> It's been several years since we increased the default key sizes. Before > shifting to PQC, NSA replaced its Suite B cryptography recommendations with > the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures > (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. > The changes are mostly in keytool, jarsigner and their regression tests, so > @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Updated to use SHA-384 as long as the keysize permits. - Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/27e27836..7f6fe4b5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7652=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7652=00-01 Stats: 27 lines in 7 files changed: 6 ins; 4 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA
On Wed, 2 Mar 2022 00:13:41 GMT, Valerie Peng wrote: > It's been several years since we increased the default key sizes. Before > shifting to PQC, NSA replaced its Suite B cryptography recommendations with > the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures > (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. > The changes are mostly in keytool, jarsigner and their regression tests, so > @wangweij Could you please take a look? > > Thanks! Fair point that the keysize would determine the algorithm used and the default key sizes for keygen. - PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA
On Wed, 2 Mar 2022 04:02:45 GMT, Anthony Scarpino wrote: > I have some compatibility concerns about the AES change breaking code that > expects a SecretKeySpec of 16 bytes. I can see situations where > '.getEncoded()' returns a byte[32] when user code expects a byte[16]. Also, > I'm pretty sure passing a 32 byte SecretKeySpec into an AES_128_GCM op will > throw an exception. I haven't looked at other modes. Well, I am not sure how specifying a 32-byte SecretKeySpec (instance of a SecretKey) with AES Cipher would trigger AES_128_GCM op? Shouldn't the keysize be detected when Cipher.init() is called and then invoking the right op? True that this default key size change would impact callers who do not specify key size but then made the assumption of key being 16-byte. Well, the key generator javadoc did warn about not setting a default, i.e. different providers may have different default key size and that the default key size may change later for the same provider. So, it's not like we have not warned about it... - PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA
On Wed, 2 Mar 2022 00:13:41 GMT, Valerie Peng wrote: > It's been several years since we increased the default key sizes. Before > shifting to PQC, NSA replaced its Suite B cryptography recommendations with > the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures > (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. > The changes are mostly in keytool, jarsigner and their regression tests, so > @wangweij Could you please take a look? > > Thanks! I have some compatibility concerns about the AES change breaking code that expects a SecretKeySpec of 16 bytes. I can see situations where '.getEncoded()' returns a byte[32] when user code expects a byte[16]. Also, I'm pretty sure passing a 32 byte SecretKeySpec into an AES_128_GCM op will throw an exception. I haven't looked at other modes. - PR: https://git.openjdk.java.net/jdk/pull/7652
RFR: 8267319: Use larger default key sizes and algorithms based on CNSA
It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: - SHA-384 for secure hashing - AES-256 for symmetric encryption - RSA with 3072 bit keys for digital signatures and for key exchange - Diffie Hellman (DH) with 3072 bit keys for key exchange - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? Thanks! - Commit messages: - 8267319: Use larger default key sizes and algorithms based on CNSA Changes: https://git.openjdk.java.net/jdk/pull/7652/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7652=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267319 Stats: 479 lines in 29 files changed: 321 ins; 6 del; 152 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652
