From sha.jiang at oracle.com Fri Apr 1 07:58:49 2016 From: sha.jiang at oracle.com (John Jiang) Date: Fri, 1 Apr 2016 15:58:49 +0800 Subject: RFR of JDK-8153239: ProblemList update for sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java Message-ID: <56FE2A38.8020808@oracle.com> Hi, Because of JDK-8137255, it needs to add test sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java to ProblemList. Issue: https://bugs.openjdk.java.net/browse/JDK-8153239 Webrev: http://cr.openjdk.java.net/~jjiang/8153239/webrev.00 Patch: --- a/test/ProblemList.txt Fri Apr 01 14:50:42 2016 +0900 +++ b/test/ProblemList.txt Fri Apr 01 00:52:17 2016 -0700 @@ -282,6 +282,8 @@ sun/security/tools/keytool/autotest.sh 8130302 generic-all +sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java 8137255 generic-all + ############################################################################ # jdk_sound Best regards, John Jiang From vincent.x.ryan at oracle.com Fri Apr 1 09:31:49 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 1 Apr 2016 10:31:49 +0100 Subject: RFR 6483657: MSCAPI provider does not create unique alias names In-Reply-To: <56FD48D5.3050404@oracle.com> References: <56FD48D5.3050404@oracle.com> Message-ID: Your fix looks good. Thanks. > On 31 Mar 2016, at 16:57, Ivan Gerasimov wrote: > > Hello! > > Could you please help review the fix for this long standing issue? > Windows-MY allows non-unique aliases, but our implementation of KeyStore does not take it into account. > > To help to deal with such keystores with multiple same-named aliases it is proposed to internally remap the keystore entries to aliases that artificially made unique. > > I was meaning to create a regression test, but found no easy way to test this behavior, as the keytool program doesn't allow creating same-named aliases. > All existing regression tests pass well however. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-6483657 > WEBREV: http://cr.openjdk.java.net/~igerasim/6483657/00/webrev/ > > With kind regards, > Ivan > From weijun.wang at oracle.com Fri Apr 1 11:34:09 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 1 Apr 2016 19:34:09 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> Message-ID: Hi All Updated webrev at http://cr.openjdk.java.net/~weijun/8051408/webrev.08/ http://cr.openjdk.java.net/~weijun/8051408/webrev.08/spec http://cr.openjdk.java.net/~weijun/8051408/webrev.08/specdiff Spec changes: - More text in @implNote of DrbgParameters.java, which somehow matches the Minimal Documentation Requirements described in 11.1 of NIST SP 800-90Ar1. - DrbgParameters.instantiate(strength,cap,ps) throws NPE if cap is null - SecureRandom.java: no more @implSpec for new methods since impl is in SecureRandomSpi. Also, make the following word changes in all UOE cases: - * @throws UnsupportedOperationException if the implementation - * has not overridden this method. + * @throws UnsupportedOperationException if the underlying provider + * implementation has not overridden this method. "drbg" security property changes: - delimiter is now ",". Otherwise, "SHA-512/256" is ambiguous. - AbstractDrbg#toString and DrbgParameters$Instantiate#toString also use "," now. - default value is "", thus each aspect uses its own default as described in the comment. - examples Code changes: - DRBG.java: more check for the "drbg" security property, one aspect cannot be set twice, and strength must be positive - HashDrbg.java optimization * Use MessageDigest#digest(output,offset,length) instead of digest()+arraycopy. (BTW, why is DigestException a checked exception?) -- a little useful * addBytes() now updates its first argument, therefore less round of adding -- very useful * store "new byte[1]" and "new byte[]{1}" as constants -- a little useful - MoreDrbgParameters: now including mech, so it can fully cover the "drbg" security property. It still includes non-publicly configurable items like entropy source and nonce, that the DRBG (known-answer) Test Vectors require. Thanks Max From Xuelei.Fan at Oracle.COM Fri Apr 1 15:53:05 2016 From: Xuelei.Fan at Oracle.COM (Xuelei Fan) Date: Fri, 1 Apr 2016 08:53:05 -0700 Subject: Code Review Request 8072452 Support DHE sizes up to 8192-bits Message-ID: <56FE9961.8090806@Oracle.COM> Hi, Please review this improvement update to support DHE sizes up to 8192-bits and DSA sizes up to 3072-bits: http://cr.openjdk.java.net/~xuelei/8072452/webrev.00 This updated extends to support 3072-bits DH and DSA parameters generation, and pre-computed DH parameters up to 8192 bits and pre-computed DSA parameters up to 3072-bits. Thanks, Xuelei From anthony.scarpino at oracle.com Fri Apr 1 17:11:37 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 1 Apr 2016 10:11:37 -0700 Subject: RFR 8098580: drainRefQueueBounds() puts pressure on pool.size() In-Reply-To: <56FAC484.8030007@oracle.com> References: <56D617C9.1040905@oracle.com> <56FAC484.8030007@oracle.com> Message-ID: <56FEABC9.4020103@oracle.com> I updated the webrev: http://cr.openjdk.java.net/~ascarpino/8098580/webrev.01/ Comments below.... On 03/29/2016 11:08 AM, Valerie Peng wrote: > Hi, Tony, > > > - line 243, 'be' should be "by"? Yes, by. > - line 271, why use SESSION_MAX - 1 instead of just SESSION_MAX? The > check on line 286 make sure that the queue will not be empty. Actually, > the comment has "until only one is left", but the condition is ">1", so > shouldn't it be "until 2 left"? This is not what u changed, just noticed > it and wonder if I read the code wrong. Yes, I believe you are correct, the -1 should be removed > > > - line 1114 and 1115, can we rename these 2 variables? The terms session > and token are all over this SessionKeyRef class. Some are local, some > are member fields. It'd make the code much more easier to follow if they > are named something less common, say "sess" or "tok". Sure. > - line 1126 - 1127, it's clearer to have {} to clearly separate the code. Oops.. Didn't notice it was missing.. > - After the while-true loop (line 1116 - 1134), don't you have to call > token.releaseSession(session) again? Otherwise, the most recently > allocated op session seems to not released back to the pool. Yes, you are right. > - There was a session.token.isValid() check in the older dispose() > method but not in the new one. Shouldn't we still check before getting a > new op session? I put the check back in so that it will avoid doing a pkcs11 operations if the token isn't available. > - The two dispose methods do entirely different things, it'd be better > to name them differently. Ok.. I changed the one that takes the session to disposeNative. > Thanks, > Valerie > > On 3/1/2016 2:29 PM, Anthony Scarpino wrote: >> Hi, >> >> I need a review of this change to SunPKCS11 where it's a bit smarter >> in disposing of native library object by reusing the same pkcs11 >> session is possible. Additionally changes to the session pool to fix >> a performance bottleneck. >> >> http://cr.openjdk.java.net/~ascarpino/8098580/webrev/ >> >> thanks >> >> Tony >> From ecki at zusammenkunft.net Fri Apr 1 21:36:22 2016 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 1 Apr 2016 23:36:22 +0200 Subject: Code Review Request 8072452 Support DHE sizes up to 8192-bits In-Reply-To: <56FE9961.8090806@Oracle.COM> References: <56FE9961.8090806@Oracle.COM> Message-ID: <20160401233622.0000209e.ecki@zusammenkunft.net> Hello Xuelei, glad to see this. :) --java.base/share/classes/sun/security/ssl/DHCrypt.java Does the comment "// FEDHE" stand for FFDHE (JDK-8140436)? maybe name the variables ffdheXXXX instead of pXXXX? (they might be directly used clients to verify well known parameters) Unrelated to the change: What about reomving p512 and p768 from the cache. In normal scenarios they are disabled, but if somebody enables the weak sizes he would benefit from dynamic generation (and not much time is needed). Line 154: just an observation, the other places in this file request 'JsseJce.get*("DiffieHellmann"' but the KeyFactory is requested by name "DH". --java.base/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java For my taste it would be good to document why generation of modulus primes >1024 bit is not supported. Is this a performance issue or a problem with the security of the generator?) --java.base/share/classes/com/sun/crypto/provider/DHParameterGenerator.java Line 64+70: Does not support 8k? --java.base/share/classes/sun/security/provider/ParameterCache.java Observation unrelated to the patch: Would it make sense in DHCrypt to reference the parametes from ParamterCache and not have 2 distinguished places where same (if any) constants are defined? (the differente caches can still exist) Line 68+94+168 - the 3072bit case is provided, should also be supporte? Line 291+333 - in case you need to have another revision there is a nit: blank lines are used in all other places before the xxxCache.put Another observation not related to your change: DHParameterGenerator:141+157+DSAParameterGenerator:152 is it intentional that two use provider SUN, SunJCE and one does not specify a provider? Greetings Bernd Am Fri, 1 Apr 2016 08:53:05 -0700 schrieb Xuelei Fan : > Hi, > > Please review this improvement update to support DHE sizes up to > 8192-bits and DSA sizes up to 3072-bits: > > http://cr.openjdk.java.net/~xuelei/8072452/webrev.00 > > This updated extends to support 3072-bits DH and DSA parameters > generation, and pre-computed DH parameters up to 8192 bits and > pre-computed DSA parameters up to 3072-bits. > > Thanks, > Xuelei From valerie.peng at oracle.com Mon Apr 4 23:36:47 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 04 Apr 2016 16:36:47 -0700 Subject: RFR 8098580: drainRefQueueBounds() puts pressure on pool.size() In-Reply-To: <56FEABC9.4020103@oracle.com> References: <56D617C9.1040905@oracle.com> <56FAC484.8030007@oracle.com> <56FEABC9.4020103@oracle.com> Message-ID: <5702FA8F.6010508@oracle.com> Updated webrev looks fine~ Thanks, Valerie On 4/1/2016 10:11 AM, Anthony Scarpino wrote: > I updated the webrev: > http://cr.openjdk.java.net/~ascarpino/8098580/webrev.01/ > > Comments below.... > > On 03/29/2016 11:08 AM, Valerie Peng wrote: >> Hi, Tony, >> >> >> - line 243, 'be' should be "by"? > > Yes, by. > >> - line 271, why use SESSION_MAX - 1 instead of just SESSION_MAX? The >> check on line 286 make sure that the queue will not be empty. Actually, >> the comment has "until only one is left", but the condition is ">1", so >> shouldn't it be "until 2 left"? This is not what u changed, just noticed >> it and wonder if I read the code wrong. > > Yes, I believe you are correct, the -1 should be removed > >> >> >> - line 1114 and 1115, can we rename these 2 variables? The terms session >> and token are all over this SessionKeyRef class. Some are local, some >> are member fields. It'd make the code much more easier to follow if they >> are named something less common, say "sess" or "tok". > > Sure. > > >> - line 1126 - 1127, it's clearer to have {} to clearly separate the >> code. > > Oops.. Didn't notice it was missing.. > >> - After the while-true loop (line 1116 - 1134), don't you have to call >> token.releaseSession(session) again? Otherwise, the most recently >> allocated op session seems to not released back to the pool. > > Yes, you are right. > > >> - There was a session.token.isValid() check in the older dispose() >> method but not in the new one. Shouldn't we still check before getting a >> new op session? > > I put the check back in so that it will avoid doing a pkcs11 > operations if the token isn't available. > >> - The two dispose methods do entirely different things, it'd be better >> to name them differently. > > Ok.. I changed the one that takes the session to disposeNative. > >> Thanks, >> Valerie >> >> On 3/1/2016 2:29 PM, Anthony Scarpino wrote: >>> Hi, >>> >>> I need a review of this change to SunPKCS11 where it's a bit smarter >>> in disposing of native library object by reusing the same pkcs11 >>> session is possible. Additionally changes to the session pool to fix >>> a performance bottleneck. >>> >>> http://cr.openjdk.java.net/~ascarpino/8098580/webrev/ >>> >>> thanks >>> >>> Tony >>> > From xuelei.fan at oracle.com Tue Apr 5 00:48:56 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 5 Apr 2016 08:48:56 +0800 Subject: Code Review Request 8072452 Support DHE sizes up to 8192-bits In-Reply-To: <20160401233622.0000209e.ecki@zusammenkunft.net> References: <56FE9961.8090806@Oracle.COM> <20160401233622.0000209e.ecki@zusammenkunft.net> Message-ID: <57030B78.9040200@oracle.com> Updated webrev: http://cr.openjdk.java.net/~xuelei/8072452/webrev.01 On 4/2/2016 5:36 AM, Bernd Eckenfels wrote: > Hello Xuelei, > > glad to see this. :) > > > --java.base/share/classes/sun/security/ssl/DHCrypt.java > > Does the comment "// FEDHE" stand for FFDHE (JDK-8140436)? Good catch! Updated to "FFDHE". > maybe name the variables ffdheXXXX instead of pXXXX? (they might be > directly used clients to verify well known parameters) > 'p' in "pXXX" means the prime modulus p of DH parameters. If using ffdheXXX, there are more than 80 characters in the line. I would prefer to use pXXX instead. > > Unrelated to the change: What about reomving p512 and p768 from the > cache. In normal scenarios they are disabled, but if somebody enables > the weak sizes he would benefit from dynamic generation (and not much > time is needed). > In general, the dynamic generation is still slow for a server. 512 and 768 should be used for corner cases only at present. > > Line 154: just an observation, the other places in this file request > 'JsseJce.get*("DiffieHellmann"' but the KeyFactory is requested by name > "DH". > "DH" is an alias of "DiffieHellmann". Nice to use the formal name. > > --java.base/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java > > For my taste it would be good to document why generation of > modulus primes >1024 bit is not supported. Is this a performance issue > or a problem with the security of the generator?) > Performance issue, very slow. Updated the comment for the reason. > > --java.base/share/classes/com/sun/crypto/provider/DHParameterGenerator.java > > Line 64+70: Does not support 8k? > Not yet because the performance issue. > > --java.base/share/classes/sun/security/provider/ParameterCache.java > > Observation unrelated to the patch: Would it make sense in DHCrypt to > reference the parametes from ParamterCache and not have 2 distinguished > places where same (if any) constants are defined? (the differente > caches can still exist) > Better to use different groups for different protocols. The groups used in DHCrypt are for SSL/TLS connections only, which would better be different from the groups defined in ParameterCache. For the same constants (defined by 2409/3526), it would be nice to update to use different safe primes later. > Line 68+94+168 - the 3072bit case is provided, should also be supporte? > Good catch! > Line 291+333 - in case you need to have another revision there is a > nit: blank lines are used in all other places before the xxxCache.put > Yes. > Another observation not related to your change: > DHParameterGenerator:141+157+DSAParameterGenerator:152 is it > intentional that two use provider SUN, SunJCE and one does not specify > a provider? > I think so. Algorithm parameters normally can be provider independent. Thanks a lot for the review. Regards, Xuelei > Greetings > Bernd > > > Am Fri, 1 Apr 2016 08:53:05 -0700 > schrieb Xuelei Fan : > >> Hi, >> >> Please review this improvement update to support DHE sizes up to >> 8192-bits and DSA sizes up to 3072-bits: >> >> http://cr.openjdk.java.net/~xuelei/8072452/webrev.00 >> >> This updated extends to support 3072-bits DH and DSA parameters >> generation, and pre-computed DH parameters up to 8192 bits and >> pre-computed DSA parameters up to 3072-bits. >> >> Thanks, >> Xuelei > From weijun.wang at oracle.com Tue Apr 5 02:34:58 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 5 Apr 2016 10:34:58 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> Message-ID: <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> Updated webrev again at http://cr.openjdk.java.net/~weijun/8051408/webrev.09/ http://cr.openjdk.java.net/~weijun/8051408/webrev.09/spec http://cr.openjdk.java.net/~weijun/8051408/webrev.09/specdiff The only change is that SecureRandomInstantiateParameters, SecureRandomNextBytesParameters and SecureRandomReseedParameters are removed and only a single SecureRandomParameters is added. There seems no reason to introduce 3 marker interfaces. Thanks Max > On Apr 1, 2016, at 7:34 PM, Wang Weijun wrote: > > Hi All > > Updated webrev at > > http://cr.openjdk.java.net/~weijun/8051408/webrev.08/ > http://cr.openjdk.java.net/~weijun/8051408/webrev.08/spec > http://cr.openjdk.java.net/~weijun/8051408/webrev.08/specdiff > > Spec changes: > > - More text in @implNote of DrbgParameters.java, which somehow matches the Minimal Documentation Requirements described in 11.1 of NIST SP 800-90Ar1. > > - DrbgParameters.instantiate(strength,cap,ps) throws NPE if cap is null > > - SecureRandom.java: no more @implSpec for new methods since impl is in SecureRandomSpi. Also, make the following word changes in all UOE cases: > > - * @throws UnsupportedOperationException if the implementation > - * has not overridden this method. > + * @throws UnsupportedOperationException if the underlying provider > + * implementation has not overridden this method. > > "drbg" security property changes: > > - delimiter is now ",". Otherwise, "SHA-512/256" is ambiguous. > > - AbstractDrbg#toString and DrbgParameters$Instantiate#toString also use "," now. > > - default value is "", thus each aspect uses its own default as described in the comment. > > - examples > > Code changes: > > - DRBG.java: more check for the "drbg" security property, one aspect cannot be set twice, > and strength must be positive > > - HashDrbg.java optimization > > * Use MessageDigest#digest(output,offset,length) instead of digest()+arraycopy. > (BTW, why is DigestException a checked exception?) -- a little useful > > * addBytes() now updates its first argument, therefore less round of adding -- very useful > > * store "new byte[1]" and "new byte[]{1}" as constants -- a little useful > > - MoreDrbgParameters: now including mech, so it can fully cover the "drbg" security property. It still includes non-publicly configurable items like entropy source and nonce, that the DRBG (known-answer) Test Vectors require. > > Thanks > Max > From sean.mullan at oracle.com Tue Apr 5 12:28:19 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 5 Apr 2016 08:28:19 -0400 Subject: New JEP Draft for review: "Disable SHA-1 Certificates" Message-ID: <5703AF63.7040004@oracle.com> We are seeking feedback on a new JEP Draft ("Disable SHA-1 Certificates) that is initially targeted to JDK 9: http://openjdk.java.net/jeps/8149555 The goal of the JEP is to improve the default security configuration of the JDK by disabling X.509 certificate chains with SHA-1 based signatures. Backports to earlier releases will be targeted at a later date after more communication, discussion and testing. Thanks, Sean From sean.coffey at oracle.com Tue Apr 5 13:13:34 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 5 Apr 2016 14:13:34 +0100 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> Message-ID: <5703B9FE.9000709@oracle.com> A few comments from supportability side of the table. ============= sun/security/provider/AbstractDrbg.java > + if (dp.getStrength() > strength) { > + throw new IllegalArgumentException("strength too high"); > + } > + if (result.length > maxNbLength) { > + throw new IllegalArgumentException("result too long"); > + } Please print these bad strengths / results in the exception. Similar corrections are needed in the engineConfigure method : > 608 if (config.getStrength() > highestSecurity) { > 609 throw new IllegalArgumentException("strength too big"); > 610 } > 611 if (config.getPersonalizationString() != null && config.getPersonalizationString().length > maxPsLength) { > 612 throw new IllegalArgumentException("ps too long"); > 613 } > throw new IllegalArgumentException("unknown params type"); can you print the type of params that was passed in ? (X 2 calls) > + if (dp.getAdditionalInput() != null && dp.getAdditionalInput().length > maxAiLength) { > + throw new IllegalArgumentException("ai too long"); Please print ai value. > + // This SEI does not support pr > + throw new IllegalArgumentException(); Cou you put your comment in the body of the IllegalArgumentException ? ============= sun/security/provider/CtrDrbg.java + try { + aesLimit = Cipher.getMaxAllowedKeyLength("AES"); + } catch (Exception e) { + // should not happen + throw new AssertionError("Cannot detect AES"); + } Just to be safe, can you add e as Throwable variable for AssertionError ? > + if (input.length != seedLen) { > + // Should not happen > + throw new IllegalArgumentException("input must be of seedlen bytes"); can you print the lengths expected ? ============= sun/security/provider/DRBG.java > + if (strength < 0) { > + throw new IllegalArgumentException( > + "strength in drbg cannot be negative"); > + } Let's print the value of the 'part' string in this exception. + } else { + throw new IllegalArgumentException("Unsupported params"); + } can you print the type of params that were passed in ? + default: + throw new IllegalArgumentException("Unsupported mech"); + } can yuo print the mech value encoutered ? ============= sun/security/provider/HashDrbg.java > + } catch (DigestException e) { > + throw new AssertionError("will not happen"); > + } Famous last words ;) Can you add e as Throwable cause to AssertionError ? (happens in two areas) Regards, Sean. On 05/04/2016 03:34, Wang Weijun wrote: > Updated webrev again at > > http://cr.openjdk.java.net/~weijun/8051408/webrev.09/ > http://cr.openjdk.java.net/~weijun/8051408/webrev.09/spec > http://cr.openjdk.java.net/~weijun/8051408/webrev.09/specdiff > > The only change is that SecureRandomInstantiateParameters, SecureRandomNextBytesParameters and SecureRandomReseedParameters are removed and only a single SecureRandomParameters is added. There seems no reason to introduce 3 marker interfaces. > > Thanks > Max > > >> On Apr 1, 2016, at 7:34 PM, Wang Weijun wrote: >> >> Hi All >> >> Updated webrev at >> >> http://cr.openjdk.java.net/~weijun/8051408/webrev.08/ >> http://cr.openjdk.java.net/~weijun/8051408/webrev.08/spec >> http://cr.openjdk.java.net/~weijun/8051408/webrev.08/specdiff >> >> Spec changes: >> >> - More text in @implNote of DrbgParameters.java, which somehow matches the Minimal Documentation Requirements described in 11.1 of NIST SP 800-90Ar1. >> >> - DrbgParameters.instantiate(strength,cap,ps) throws NPE if cap is null >> >> - SecureRandom.java: no more @implSpec for new methods since impl is in SecureRandomSpi. Also, make the following word changes in all UOE cases: >> >> - * @throws UnsupportedOperationException if the implementation >> - * has not overridden this method. >> + * @throws UnsupportedOperationException if the underlying provider >> + * implementation has not overridden this method. >> >> "drbg" security property changes: >> >> - delimiter is now ",". Otherwise, "SHA-512/256" is ambiguous. >> >> - AbstractDrbg#toString and DrbgParameters$Instantiate#toString also use "," now. >> >> - default value is "", thus each aspect uses its own default as described in the comment. >> >> - examples >> >> Code changes: >> >> - DRBG.java: more check for the "drbg" security property, one aspect cannot be set twice, >> and strength must be positive >> >> - HashDrbg.java optimization >> >> * Use MessageDigest#digest(output,offset,length) instead of digest()+arraycopy. >> (BTW, why is DigestException a checked exception?) -- a little useful >> >> * addBytes() now updates its first argument, therefore less round of adding -- very useful >> >> * store "new byte[1]" and "new byte[]{1}" as constants -- a little useful >> >> - MoreDrbgParameters: now including mech, so it can fully cover the "drbg" security property. It still includes non-publicly configurable items like entropy source and nonce, that the DRBG (known-answer) Test Vectors require. >> >> Thanks >> Max >> From weijun.wang at oracle.com Tue Apr 5 13:35:47 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 5 Apr 2016 21:35:47 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <5703B9FE.9000709@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <5703B9FE.9000709@oracle.com> Message-ID: Thanks for the review. All comments accepted. --Max > On Apr 5, 2016, at 9:13 PM, Se?n Coffey wrote: > > A few comments from supportability side of the table. > > ============= > sun/security/provider/AbstractDrbg.java > >> + if (dp.getStrength() > strength) { >> + throw new IllegalArgumentException("strength too high"); >> + } >> + if (result.length > maxNbLength) { >> + throw new IllegalArgumentException("result too long"); >> + } > Please print these bad strengths / results in the exception. > > Similar corrections are needed in the engineConfigure method : > >> 608 if (config.getStrength() > highestSecurity) { >> 609 throw new IllegalArgumentException("strength too big"); >> 610 } >> 611 if (config.getPersonalizationString() != null && config.getPersonalizationString().length > maxPsLength) { >> 612 throw new IllegalArgumentException("ps too long"); >> 613 } > >> throw new IllegalArgumentException("unknown params type"); > can you print the type of params that was passed in ? (X 2 calls) > > >> + if (dp.getAdditionalInput() != null && dp.getAdditionalInput().length > maxAiLength) { >> + throw new IllegalArgumentException("ai too long"); > Please print ai value. > > >> + // This SEI does not support pr >> + throw new IllegalArgumentException(); > Cou you put your comment in the body of the IllegalArgumentException ? > > ============= > sun/security/provider/CtrDrbg.java > > + try { > + aesLimit = Cipher.getMaxAllowedKeyLength("AES"); > + } catch (Exception e) { > + // should not happen > + throw new AssertionError("Cannot detect AES"); > + } > > Just to be safe, can you add e as Throwable variable for AssertionError ? > > >> + if (input.length != seedLen) { >> + // Should not happen >> + throw new IllegalArgumentException("input must be of seedlen bytes"); > > can you print the lengths expected ? > ============= > sun/security/provider/DRBG.java > >> + if (strength < 0) { >> + throw new IllegalArgumentException( >> + "strength in drbg cannot be negative"); >> + } > Let's print the value of the 'part' string in this exception. > > + } else { > + throw new IllegalArgumentException("Unsupported params"); > + } > > can you print the type of params that were passed in ? > > + default: > + throw new IllegalArgumentException("Unsupported mech"); > + } > > can yuo print the mech value encoutered ? > ============= > sun/security/provider/HashDrbg.java > >> + } catch (DigestException e) { >> + throw new AssertionError("will not happen"); >> + } > > Famous last words ;) > Can you add e as Throwable cause to AssertionError ? (happens in two areas) > > Regards, > Sean. > > On 05/04/2016 03:34, Wang Weijun wrote: >> Updated webrev again at >> >> http://cr.openjdk.java.net/~weijun/8051408/webrev.09/ >> http://cr.openjdk.java.net/~weijun/8051408/webrev.09/spec >> http://cr.openjdk.java.net/~weijun/8051408/webrev.09/specdiff >> >> The only change is that SecureRandomInstantiateParameters, SecureRandomNextBytesParameters and SecureRandomReseedParameters are removed and only a single SecureRandomParameters is added. There seems no reason to introduce 3 marker interfaces. >> >> Thanks >> Max From svetlana.nikandrova at oracle.com Tue Apr 5 13:58:53 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Tue, 05 Apr 2016 16:58:53 +0300 Subject: [8u-dev] Request for Review + Request for Approval for Backport : 8048147: Privilege tests with JAAS Subject.doAs + 8076486 (test's fix) Message-ID: <5703C49D.1050409@oracle.com> Hello, please review and approve the backport of tests enhancement: Original test from https://bugs.openjdk.java.net/browse/JDK-8048147 jdk 9 review: http://mail.openjdk.java.net/pipermail/security-dev/2015-March/011902.html jdk 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7969f7b6465e was combined with it's fix: https://bugs.openjdk.java.net/browse/JDK-8076486 jdk 9 review: http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012111.html jdk 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fff8ab918557 Webrev: http://cr.openjdk.java.net/~snikandrova/8048147/webrev.00/ The test's code differs from jdk9 as InputStream's transferTo method was introduced in jdk 9. I rewrite that part as: + try (FileInputStream fis = new FileInputStream( + TEST_CLASSES + FS + file)) { + byte[] buffer = new byte[1024]; + int read; + while ((read = fis.read(buffer, 0, buffer.length)) > 0) { + jos.write(buffer, 0, read); + } + } All the other code is identical. Tested with JPRT. Thank you, Svetlana From sean.coffey at oracle.com Tue Apr 5 18:23:22 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 5 Apr 2016 19:23:22 +0100 Subject: RFR : 8153531: Improve exception messaging for RSAClientKeyExchange Message-ID: <5704029A.4090707@oracle.com> Some trivial updates to exception messages that should ease debugging for future issues: https://bugs.openjdk.java.net/browse/JDK-8153531 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8153531/webrev/ one edit I thought I'd highlight: I've converted this exception into an SSLException to make use of the 2 arg constructor : > ! throw new SSLProtocolException( > ! "Unable to process PreMasterSecret, may be too big"); I could use the initCause approach if necessary but figured that it didn't matter. -- Regards, Sean. -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue Apr 5 23:21:09 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 6 Apr 2016 07:21:09 +0800 Subject: RFR : 8153531: Improve exception messaging for RSAClientKeyExchange In-Reply-To: <5704029A.4090707@oracle.com> References: <5704029A.4090707@oracle.com> Message-ID: <57044865.8010105@oracle.com> Looks fine to me. Please keep each line bellow 80 characters. Thanks, Xuelei On 4/6/2016 2:23 AM, Se?n Coffey wrote: > Some trivial updates to exception messages that should ease debugging > for future issues: > > https://bugs.openjdk.java.net/browse/JDK-8153531 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8153531/webrev/ > > one edit I thought I'd highlight: > > I've converted this exception into an SSLException to make use of the 2 > arg constructor : > >> ! throw new SSLProtocolException( >> ! "Unable to process PreMasterSecret, may be too big"); > I could use the initCause approach if necessary but figured that it > didn't matter. > > -- > Regards, > Sean. > From sha.jiang at oracle.com Wed Apr 6 13:04:47 2016 From: sha.jiang at oracle.com (John Jiang) Date: Wed, 6 Apr 2016 21:04:47 +0800 Subject: RFR of JDK-8153239: ProblemList update for sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java In-Reply-To: <56FE2A38.8020808@oracle.com> References: <56FE2A38.8020808@oracle.com> Message-ID: <5705096F.6050002@oracle.com> Hi, This test failed several times, and it's better to put it to ProblemList until the issue is resolved. Please review this patch, thanks! Best regards, John Jiang On 2016/4/1 15:58, John Jiang wrote: > Hi, > Because of JDK-8137255, it needs to add test > sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java to > ProblemList. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8153239 > Webrev: http://cr.openjdk.java.net/~jjiang/8153239/webrev.00 > > Patch: > --- a/test/ProblemList.txt Fri Apr 01 14:50:42 2016 +0900 > +++ b/test/ProblemList.txt Fri Apr 01 00:52:17 2016 -0700 > @@ -282,6 +282,8 @@ > > sun/security/tools/keytool/autotest.sh 8130302 generic-all > > +sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java 8137255 > generic-all > + > ############################################################################ > > > # jdk_sound > > Best regards, > John Jiang > From xuelei.fan at oracle.com Wed Apr 6 13:15:02 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 6 Apr 2016 21:15:02 +0800 Subject: RFR of JDK-8153239: ProblemList update for sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java In-Reply-To: <5705096F.6050002@oracle.com> References: <56FE2A38.8020808@oracle.com> <5705096F.6050002@oracle.com> Message-ID: <57050BD6.3000706@oracle.com> Looks fine to me. Xuelei On 4/6/2016 9:04 PM, John Jiang wrote: > Hi, > This test failed several times, and it's better to put it to ProblemList > until the issue is resolved. > Please review this patch, thanks! > > Best regards, > John Jiang > > On 2016/4/1 15:58, John Jiang wrote: >> Hi, >> Because of JDK-8137255, it needs to add test >> sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java to >> ProblemList. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8153239 >> Webrev: http://cr.openjdk.java.net/~jjiang/8153239/webrev.00 >> >> Patch: >> --- a/test/ProblemList.txt Fri Apr 01 14:50:42 2016 +0900 >> +++ b/test/ProblemList.txt Fri Apr 01 00:52:17 2016 -0700 >> @@ -282,6 +282,8 @@ >> >> sun/security/tools/keytool/autotest.sh 8130302 generic-all >> >> +sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java 8137255 >> generic-all >> + >> ############################################################################ >> >> >> # jdk_sound >> >> Best regards, >> John Jiang >> > From weijun.wang at oracle.com Wed Apr 6 14:19:50 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 6 Apr 2016 22:19:50 +0800 Subject: RFR: draft-ietf-kitten-rfc5653bis-03 JGSS-API References: <20160406135854.24895.32289.idtracker@ietfa.amsl.com> Message-ID: I just posted a new version of rfc5653bis. The major changes in this I-D (compared to RFC 5653) are: 1. public byte[] GSSException#getOutputToken(). If initSecContext or acceptSecContext fail, the exception could contain a token that can be sent to the peer. For kerberos 5, this is normally a KRB-ERROR message. 2. All stream-based GSSContext methods are removed. Reason: "The wire protocol should be defined by an application and not a library. It's also impossible to implement these methods correctly when the token has no self-framing (where the end cannot be determined) or the library has no knowledge of the token format (for example, as a bridge talking to another GSS library)". The #1 above was already in draft-ietf-kitten-rfc5653bis-02, #2 is new in -03. Thanks Max > Begin forwarded message: > > A new version of I-D, draft-ietf-kitten-rfc5653bis-03.txt > has been successfully submitted by Wang Weijun and posted to the > IETF repository. > > Name: draft-ietf-kitten-rfc5653bis > Revision: 03 > Title: Generic Security Service API Version 2: Java Bindings Update > Document date: 2016-04-05 > Group: kitten > Pages: 96 > URL: https://www.ietf.org/internet-drafts/draft-ietf-kitten-rfc5653bis-03.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-kitten-rfc5653bis/ > Htmlized: https://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-03 > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-rfc5653bis-03 > > Abstract: > The Generic Security Services Application Program Interface (GSS-API) > offers application programmers uniform access to security services > atop a variety of underlying cryptographic mechanisms. This document > updates the Java bindings for the GSS-API that are specified in > "Generic Security Service API Version 2 : Java Bindings Update" (RFC > 5653). This document obsoletes RFC 5653 by adding a new output token > field to the GSSException class so that when the initSecContext or > acceptSecContext methods of the GSSContext class fails it has a > chance to emit an error token which can be sent to the peer for > debugging or informational purpose. The stream-based GSSContext > methods are also removed in this version. > > The GSS-API is described at a language-independent conceptual level > in "Generic Security Service Application Program Interface Version 2, > Update 1" (RFC 2743). The GSS-API allows a caller application to > authenticate a principal identity, to delegate rights to a peer, and > to apply security services such as confidentiality and integrity on a > per-message basis. Examples of security mechanisms defined for GSS- > API are "The Simple Public-Key GSS-API Mechanism" (RFC 2025) and "The > Kerberos Version 5 Generic Security Service Application Program > Interface (GSS-API) Mechanism: Version 2" (RFC 4121). > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > From anthony.scarpino at oracle.com Wed Apr 6 21:23:43 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 6 Apr 2016 14:23:43 -0700 Subject: RFR 8152205: jdk.security.provider.preferred is ambiguously documented Message-ID: <57057E5F.2050601@oracle.com> I need a review of this very simple doc clarification. Calling out jdk.security.provider.preferred as a "security property" instead of just a "property". http://cr.openjdk.java.net/~ascarpino/8152205/webrev/ thanks. Tony From xuelei.fan at oracle.com Wed Apr 6 22:47:39 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 7 Apr 2016 06:47:39 +0800 Subject: RFR 8152205: jdk.security.provider.preferred is ambiguously documented In-Reply-To: <57057E5F.2050601@oracle.com> References: <57057E5F.2050601@oracle.com> Message-ID: <5705920B.4070106@oracle.com> Looks fine to me. Xuelei On 4/7/2016 5:23 AM, Anthony Scarpino wrote: > I need a review of this very simple doc clarification. Calling out > jdk.security.provider.preferred as a "security property" instead of just > a "property". > > http://cr.openjdk.java.net/~ascarpino/8152205/webrev/ > > thanks. > > Tony From xuelei.fan at oracle.com Wed Apr 6 22:52:31 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 7 Apr 2016 06:52:31 +0800 Subject: Code Review Request 8144566, Custom HostnameVerifier disables SNI extension In-Reply-To: <569EDF8A.5000603@oracle.com> References: <56642AD3.6010904@oracle.com> <56662275.5000007@oracle.com> <5666C93E.6010306@oracle.com> <569EDF8A.5000603@oracle.com> Message-ID: <5705932F.7030901@oracle.com> Ping ... On 1/20/2016 9:14 AM, Xuelei Fan wrote: > Ping ... > > On 12/8/2015 8:12 PM, Xuelei Fan wrote: >> Good catch! >> >> I copied the comment here: >> >> ---------- >> SocketFactory sslsf = SSLSocketFactory.getDefault(); >> SSLSocket ssls = (SSLSocket) sslsf.createSocket(); >> ssls.connect(new InetSocketAddress( >> "bugs.openjdk.java.net", 443), 0); >> ssls.startHandshake(); >> >> No SNI is sent in this case. >> ---------- >> >> Although this is not a regression, but this is a very good catch. >> >> However, I don't think the code path is a best practice, as the actual >> behavior depends on providers behaviors and platform behaviors too much. >> I would recommend to use SSLParameters.setServerNames() to specify the >> server names explicitly. >> >> But, best effort should be made for the default server names for such >> code paths. Here is the webrev that also fixes this code path issue: >> >> http://cr.openjdk.java.net/~xuelei/8144566/webrev.01/ >> >> The fix gets a little bit complicated because of the need to consider >> the SSLParameters.setServerNames() impact in the code path: >> >> SSLSocket ssls = (SSLSocket) sslsf.createSocket(); >> >> // before the connection, need to consider the impact: >> // Get the SSLParameters from the socket, or create on the fly? >> // Call ssls.setSSLParameters(params) or not? >> ssls.connect(socketAddress); >> >> // after the connection, need to consider the impact: >> // Call ssls.setSSLParameters(params) or not? >> >> Basically, the implementation honors the server name set by >> SSLParameters.setServerNames(). >> >> Bernd's comment: >>> Isnt this codepath used as a workaround for dynamically disabling >>> SNI? Using connect(host..) instead of SSLSocket(host) was at >>> least a common, well known workaround. >> If the code path is really used in practice, the >> SSLParameters.setServerNames() would better be called actually to >> disable SNI explicitly. >> >> SocketFactory sslsf = SSLSocketFactory.getDefault(); >> SSLSocket ssls = (SSLSocket) sslsf.createSocket(); >> ssls.connect(new InetSocketAddress( >> "bugs.openjdk.java.net", 443), 0); >> sslParameters.setServerNames(emptyList); >> ssls.setSSLParameters(sslParameters); >> ssls.startHandshake(); >> >> Thank you, Bernd and Brad, for the feedback. >> >> Thanks, >> Xuelei >> >> On 12/8/2015 8:21 AM, Bradford Wetmore wrote: >>> >>> Please see my comment in the bug. I haven't verified this, but it seems >>> the problem might be generic to the codepath through SSLSocket, not just >>> Https. >>> >>> Brad >>> >>> >>> >>> >>> >>> On 12/6/2015 4:32 AM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> Please review the update for JDK-8144566: >>>> >>>> http://cr.openjdk.java.net/~xuelei/8144566/webrev.00/ >>>> >>>> For HttpsURLConnection, the server name may be set after the TLS >>>> connection and handshake has been initialized. As may result in that >>>> the server name does not present at TLS ClientHello messages. >>>> >>>> This fix resets the server name for the initialized handshake for above >>>> cases. >>>> >>>> Thanks, >>>> Xuelei >>>> >> > From bradford.wetmore at oracle.com Thu Apr 7 00:23:54 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 6 Apr 2016 17:23:54 -0700 Subject: RFR 8152205: jdk.security.provider.preferred is ambiguously documented In-Reply-To: <5705920B.4070106@oracle.com> References: <57057E5F.2050601@oracle.com> <5705920B.4070106@oracle.com> Message-ID: <5705A89A.7000103@oracle.com> If I was doing this from scratch, I would probably capitalize it to indicate it's a java.security.Security property and add inside the @code. {@code jdk.security.provider.preferred} security -> {@code jdk.security.provider.preferred Security} But I see it done that way in other places, so this is fine. Brad On 4/6/2016 3:47 PM, Xuelei Fan wrote: > Looks fine to me. > > Xuelei > > On 4/7/2016 5:23 AM, Anthony Scarpino wrote: >> I need a review of this very simple doc clarification. Calling out >> jdk.security.provider.preferred as a "security property" instead of just >> a "property". >> >> http://cr.openjdk.java.net/~ascarpino/8152205/webrev/ >> >> thanks. >> >> Tony > From weijun.wang at oracle.com Thu Apr 7 01:40:14 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 7 Apr 2016 09:40:14 +0800 Subject: RFR 8152205: jdk.security.provider.preferred is ambiguously documented In-Reply-To: <5705A89A.7000103@oracle.com> References: <57057E5F.2050601@oracle.com> <5705920B.4070106@oracle.com> <5705A89A.7000103@oracle.com> Message-ID: <288B522F-61DF-444A-B462-FFE089391998@oracle.com> In my DRBG changeset, I use this style: {@code jdk.security.provider.preferred} {@linkplain Security#getProperty(String) security property} --Max > On Apr 7, 2016, at 8:23 AM, Bradford Wetmore wrote: > > If I was doing this from scratch, I would probably capitalize it to indicate it's a java.security.Security property and add inside the @code. > > {@code jdk.security.provider.preferred} security > -> > {@code jdk.security.provider.preferred Security} > > But I see it done that way in other places, so this is fine. > > Brad > > > > On 4/6/2016 3:47 PM, Xuelei Fan wrote: >> Looks fine to me. >> >> Xuelei >> >> On 4/7/2016 5:23 AM, Anthony Scarpino wrote: >>> I need a review of this very simple doc clarification. Calling out >>> jdk.security.provider.preferred as a "security property" instead of just >>> a "property". >>> >>> http://cr.openjdk.java.net/~ascarpino/8152205/webrev/ >>> >>> thanks. >>> >>> Tony >> From amy.lu at oracle.com Thu Apr 7 03:42:46 2016 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 7 Apr 2016 11:42:46 +0800 Subject: JDK 9 RFR of JDK-8153695: Problem list sun/security/pkcs11/Provider/Login.sh for linux-all Message-ID: <5705D736.9040805@oracle.com> sun/security/pkcs11/Provider/Login.sh This test is known to fail at Linux platform (JDK-8153545). Please review the patch to put the test to ProblemList.txt for linux-all until mentioned issue (JDK-8153545) is resolved. Tested with jtreg -listtests bug: https://bugs.openjdk.java.net/browse/JDK-8153695 webrev: http://cr.openjdk.java.net/~amlu/8153695/webrev.00/ Thanks, Amy --- old/test/ProblemList.txt 2016-04-07 11:36:18.000000000 +0800 +++ new/test/ProblemList.txt 2016-04-07 11:36:18.000000000 +0800 @@ -238,7 +238,7 @@ sun/security/pkcs11/MessageDigest/ReinitDigest.java 8077138,8023434 windows-all sun/security/pkcs11/MessageDigest/TestCloning.java 8077138,8023434 windows-all sun/security/pkcs11/Provider/ConfigQuotedString.sh 8077138,8023434 windows-all -sun/security/pkcs11/Provider/Login.sh 8077138,8023434 windows-all +sun/security/pkcs11/Provider/Login.sh 8077138,8023434,8153545 windows-all,linux-all sun/security/pkcs11/SampleTest.java 8077138,8023434 windows-all sun/security/pkcs11/Secmod/AddPrivateKey.java 8077138,8023434 windows-all sun/security/pkcs11/Secmod/AddTrustedCert.java 8077138,8023434 windows-all -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.x.ryan at oracle.com Thu Apr 7 06:50:08 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 7 Apr 2016 07:50:08 +0100 Subject: JDK 9 RFR of JDK-8153695: Problem list sun/security/pkcs11/Provider/Login.sh for linux-all In-Reply-To: <5705D736.9040805@oracle.com> References: <5705D736.9040805@oracle.com> Message-ID: <92FE8E7D-31E4-45DC-B93A-A81502162085@oracle.com> That looks fine to me. Thanks. > On 7 Apr 2016, at 04:42, Amy Lu wrote: > > sun/security/pkcs11/Provider/Login.sh > This test is known to fail at Linux platform (JDK-8153545). > > Please review the patch to put the test to ProblemList.txt for linux-all until mentioned issue (JDK-8153545) is resolved. > Tested with jtreg -listtests > > bug: https://bugs.openjdk.java.net/browse/JDK-8153695 > webrev: http://cr.openjdk.java.net/~amlu/8153695/webrev.00/ > > Thanks, > Amy > > > --- old/test/ProblemList.txt 2016-04-07 11:36:18.000000000 +0800 > +++ new/test/ProblemList.txt 2016-04-07 11:36:18.000000000 +0800 > @@ -238,7 +238,7 @@ > sun/security/pkcs11/MessageDigest/ReinitDigest.java 8077138,8023434 windows-all > sun/security/pkcs11/MessageDigest/TestCloning.java 8077138,8023434 windows-all > sun/security/pkcs11/Provider/ConfigQuotedString.sh 8077138,8023434 windows-all > -sun/security/pkcs11/Provider/Login.sh 8077138,8023434 windows-all > +sun/security/pkcs11/Provider/Login.sh 8077138,8023434,8153545 windows-all,linux-all > sun/security/pkcs11/SampleTest.java 8077138,8023434 windows-all > sun/security/pkcs11/Secmod/AddPrivateKey.java 8077138,8023434 windows-all > sun/security/pkcs11/Secmod/AddTrustedCert.java 8077138,8023434 windows-all > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Thu Apr 7 09:12:44 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 7 Apr 2016 10:12:44 +0100 Subject: RFR : 8153531: Improve exception messaging for RSAClientKeyExchange In-Reply-To: <57044865.8010105@oracle.com> References: <5704029A.4090707@oracle.com> <57044865.8010105@oracle.com> Message-ID: <5706248C.5060701@oracle.com> Thanks. Line width adjustments made and changes pushed : http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0b18ad7184bc Regards, Sean. On 06/04/2016 00:21, Xuelei Fan wrote: > Looks fine to me. Please keep each line bellow 80 characters. > > Thanks, > Xuelei > > > On 4/6/2016 2:23 AM, Se?n Coffey wrote: >> Some trivial updates to exception messages that should ease debugging >> for future issues: >> >> https://bugs.openjdk.java.net/browse/JDK-8153531 >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8153531/webrev/ >> >> one edit I thought I'd highlight: >> >> I've converted this exception into an SSLException to make use of the 2 >> arg constructor : >> >>> ! throw new SSLProtocolException( >>> ! "Unable to process PreMasterSecret, may be too big"); >> I could use the initCause approach if necessary but figured that it >> didn't matter. >> >> -- >> Regards, >> Sean. >> From weijun.wang at oracle.com Thu Apr 7 13:58:33 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 7 Apr 2016 21:58:33 +0800 Subject: [8u-dev] Request for Review + Request for Approval for Backport : 8048147: Privilege tests with JAAS Subject.doAs + 8076486 (test's fix) In-Reply-To: <5703C49D.1050409@oracle.com> References: <5703C49D.1050409@oracle.com> Message-ID: <17214084-9688-4106-9434-81C1B4C3FD5F@oracle.com> The jdk8 changeset looks fine. Thanks, Max > On Apr 5, 2016, at 9:58 PM, Svetlana Nikandrova wrote: > > Hello, > > please review and approve the backport of tests enhancement: > Original test from > https://bugs.openjdk.java.net/browse/JDK-8048147 > jdk 9 review: http://mail.openjdk.java.net/pipermail/security-dev/2015-March/011902.html > jdk 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7969f7b6465e > > was combined with it's fix: > https://bugs.openjdk.java.net/browse/JDK-8076486 > jdk 9 review: http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012111.html > jdk 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fff8ab918557 > > Webrev: > http://cr.openjdk.java.net/~snikandrova/8048147/webrev.00/ > > The test's code differs from jdk9 as InputStream's transferTo method was introduced in jdk 9. I rewrite that part as: > > + try (FileInputStream fis = new FileInputStream( > + TEST_CLASSES + FS + file)) { > + byte[] buffer = new byte[1024]; > + int read; > + while ((read = fis.read(buffer, 0, buffer.length)) > 0) { > + jos.write(buffer, 0, read); > + } > + } > > > All the other code is identical. Tested with JPRT. > > Thank you, > Svetlana From weijun.wang at oracle.com Thu Apr 7 14:00:53 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 7 Apr 2016 22:00:53 +0800 Subject: [8u-dev] Request for Review + Request for Approval for Backport : 8048147: Privilege tests with JAAS Subject.doAs + 8076486 (test's fix) In-Reply-To: <5703C49D.1050409@oracle.com> References: <5703C49D.1050409@oracle.com> Message-ID: <564FEF40-BD32-49EA-8CAB-4470F1222C31@oracle.com> The jdk8 changeset looks fine. Thanks, Max > On Apr 5, 2016, at 9:58 PM, Svetlana Nikandrova wrote: > > Hello, > > please review and approve the backport of tests enhancement: > Original test from > https://bugs.openjdk.java.net/browse/JDK-8048147 > jdk 9 review: http://mail.openjdk.java.net/pipermail/security-dev/2015-March/011902.html > jdk 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7969f7b6465e > > was combined with it's fix: > https://bugs.openjdk.java.net/browse/JDK-8076486 > jdk 9 review: http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012111.html > jdk 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fff8ab918557 > > Webrev: > http://cr.openjdk.java.net/~snikandrova/8048147/webrev.00/ > > The test's code differs from jdk9 as InputStream's transferTo method was introduced in jdk 9. I rewrite that part as: > > + try (FileInputStream fis = new FileInputStream( > + TEST_CLASSES + FS + file)) { > + byte[] buffer = new byte[1024]; > + int read; > + while ((read = fis.read(buffer, 0, buffer.length)) > 0) { > + jos.write(buffer, 0, read); > + } > + } > > > All the other code is identical. Tested with JPRT. > > Thank you, > Svetlana From sean.coffey at oracle.com Thu Apr 7 14:15:48 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 7 Apr 2016 15:15:48 +0100 Subject: [8u-dev] Request for Review + Request for Approval for Backport : 8048147: Privilege tests with JAAS Subject.doAs + 8076486 (test's fix) In-Reply-To: <564FEF40-BD32-49EA-8CAB-4470F1222C31@oracle.com> References: <5703C49D.1050409@oracle.com> <564FEF40-BD32-49EA-8CAB-4470F1222C31@oracle.com> Message-ID: <57066B94.2070508@oracle.com> Approved for jdk8u-dev. Regards, Sean. On 07/04/2016 15:00, Wang Weijun wrote: > The jdk8 changeset looks fine. > > Thanks, > Max > >> On Apr 5, 2016, at 9:58 PM, Svetlana Nikandrova wrote: >> >> Hello, >> >> please review and approve the backport of tests enhancement: >> Original test from >> https://bugs.openjdk.java.net/browse/JDK-8048147 >> jdk 9 review: http://mail.openjdk.java.net/pipermail/security-dev/2015-March/011902.html >> jdk 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7969f7b6465e >> >> was combined with it's fix: >> https://bugs.openjdk.java.net/browse/JDK-8076486 >> jdk 9 review: http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012111.html >> jdk 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fff8ab918557 >> >> Webrev: >> http://cr.openjdk.java.net/~snikandrova/8048147/webrev.00/ >> >> The test's code differs from jdk9 as InputStream's transferTo method was introduced in jdk 9. I rewrite that part as: >> >> + try (FileInputStream fis = new FileInputStream( >> + TEST_CLASSES + FS + file)) { >> + byte[] buffer = new byte[1024]; >> + int read; >> + while ((read = fis.read(buffer, 0, buffer.length)) > 0) { >> + jos.write(buffer, 0, read); >> + } >> + } >> >> >> All the other code is identical. Tested with JPRT. >> >> Thank you, >> Svetlana From bradford.wetmore at oracle.com Thu Apr 7 18:42:16 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 7 Apr 2016 11:42:16 -0700 Subject: RFR 8152205: jdk.security.provider.preferred is ambiguously documented In-Reply-To: <288B522F-61DF-444A-B462-FFE089391998@oracle.com> References: <57057E5F.2050601@oracle.com> <5705920B.4070106@oracle.com> <5705A89A.7000103@oracle.com> <288B522F-61DF-444A-B462-FFE089391998@oracle.com> Message-ID: <5706AA08.3060600@oracle.com> On 4/6/2016 6:40 PM, Wang Weijun wrote: > In my DRBG changeset, I use this style: > > {@code jdk.security.provider.preferred} {@linkplain Security#getProperty(String) security property} I like this or {@code jdk.security.provider.preferred} {@link Security#getProperty(String) Security) Brad > > > >> On Apr 7, 2016, at 8:23 AM, Bradford Wetmore wrote: >> >> If I was doing this from scratch, I would probably capitalize it to indicate it's a java.security.Security property and add inside the @code. >> >> {@code jdk.security.provider.preferred} security >> -> >> {@code jdk.security.provider.preferred Security} >> >> But I see it done that way in other places, so this is fine. >> >> Brad >> >> >> >> On 4/6/2016 3:47 PM, Xuelei Fan wrote: >>> Looks fine to me. >>> >>> Xuelei >>> >>> On 4/7/2016 5:23 AM, Anthony Scarpino wrote: >>>> I need a review of this very simple doc clarification. Calling out >>>> jdk.security.provider.preferred as a "security property" instead of just >>>> a "property". >>>> >>>> http://cr.openjdk.java.net/~ascarpino/8152205/webrev/ >>>> >>>> thanks. >>>> >>>> Tony >>> > From amanda.jiang at oracle.com Fri Apr 8 05:09:28 2016 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Thu, 7 Apr 2016 22:09:28 -0700 Subject: RFR 8153545: sun/security/pkcs11/Provider/Login.sh fails on Linux Message-ID: <57073D08.9020007@oracle.com> Hi All, Please help to review following changeset which fixes test bug for sun/security/pkcs11/Provider/Login.sh and another similar failed test. Bug: https://bugs.openjdk.java.net/browse/JDK-8153545 Changest: http://cr.openjdk.java.net/~amjiang/8153545/webrev.01/ Thanks, Amanda From weijun.wang at oracle.com Fri Apr 8 07:28:48 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 8 Apr 2016 15:28:48 +0800 Subject: RFR 8153545: sun/security/pkcs11/Provider/Login.sh fails on Linux In-Reply-To: <57073D08.9020007@oracle.com> References: <57073D08.9020007@oracle.com> Message-ID: <80FBE556-3CA4-4C0B-85E4-D771936E01E0@oracle.com> Hi Amanda I am not familiar with the tests, but it looks like the 1st args argument should be "sm" [1] to enable the security manager, not "true". If PKCS11Test always uses args as command and optional argument(s), maybe you should throw an exception if the command is unknown. Thanks Max [1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/cac52c9da800/test/sun/security/pkcs11/PKCS11Test.java#l184 > On Apr 8, 2016, at 1:09 PM, Amanda Jiang wrote: > > Hi All, > > Please help to review following changeset which fixes test bug for sun/security/pkcs11/Provider/Login.sh and another similar failed test. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153545 > Changest: http://cr.openjdk.java.net/~amjiang/8153545/webrev.01/ > > Thanks, > Amanda From rajan.halade at oracle.com Fri Apr 8 21:27:29 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Fri, 8 Apr 2016 14:27:29 -0700 Subject: RFR: [9]: 8055351: sun/security/provider/DSA/TestAlgParameterGenerator.java failed with interrupted! (timed out?) Message-ID: <57082241.2070302@oracle.com> Please help with your review of following patch to TestAlgParameterGenerator test. It allows test more time to run, not run in othervm, and few more trivial updates. Bug: https://bugs.openjdk.java.net/browse/JDK-8055351 Webrev: http://cr.openjdk.java.net/~rhalade/8055351/webrev.00/ Thanks, Rajan From valerie.peng at oracle.com Fri Apr 8 22:08:09 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 08 Apr 2016 15:08:09 -0700 Subject: RFR: [9]: 8055351: sun/security/provider/DSA/TestAlgParameterGenerator.java failed with interrupted! (timed out?) In-Reply-To: <57082241.2070302@oracle.com> References: <57082241.2070302@oracle.com> Message-ID: <57082BC9.2090006@oracle.com> Maybe you can just remove the comments on 103 and 104 for now. How did u come to the 600 timeout value? Just curious. Rest looks fine. Thanks, Valerie On 4/8/2016 2:27 PM, Rajan Halade wrote: > Please help with your review of following patch to > TestAlgParameterGenerator test. It allows test more time to run, not > run in othervm, and few more trivial updates. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8055351 > Webrev: http://cr.openjdk.java.net/~rhalade/8055351/webrev.00/ > > Thanks, > Rajan From amanda.jiang at oracle.com Sat Apr 9 00:20:39 2016 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Fri, 8 Apr 2016 17:20:39 -0700 Subject: RFR 8153545: sun/security/pkcs11/Provider/Login.sh fails on Linux In-Reply-To: <80FBE556-3CA4-4C0B-85E4-D771936E01E0@oracle.com> References: <57073D08.9020007@oracle.com> <80FBE556-3CA4-4C0B-85E4-D771936E01E0@oracle.com> Message-ID: <57084AD7.70707@oracle.com> Hi Max, Thanks for reviewing, you are right, "sm" should be the correct argument. I updated the test argument and PKCS11Test, please check the new webrev: http://cr.openjdk.java.net/~amjiang/8153545/webrev.02/ Thanks, Amanda On 16/4/8 ??12:28, Wang Weijun wrote: > Hi Amanda > > I am not familiar with the tests, but it looks like the 1st args argument should be "sm" [1] to enable the security manager, not "true". > > If PKCS11Test always uses args as command and optional argument(s), maybe you should throw an exception if the command is unknown. > > Thanks > Max > > [1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/cac52c9da800/test/sun/security/pkcs11/PKCS11Test.java#l184 > > >> On Apr 8, 2016, at 1:09 PM, Amanda Jiang wrote: >> >> Hi All, >> >> Please help to review following changeset which fixes test bug for sun/security/pkcs11/Provider/Login.sh and another similar failed test. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153545 >> Changest: http://cr.openjdk.java.net/~amjiang/8153545/webrev.01/ >> >> Thanks, >> Amanda From weijun.wang at oracle.com Sat Apr 9 08:46:33 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 9 Apr 2016 16:46:33 +0800 Subject: RFR 8153545: sun/security/pkcs11/Provider/Login.sh fails on Linux In-Reply-To: <57084AD7.70707@oracle.com> References: <57073D08.9020007@oracle.com> <80FBE556-3CA4-4C0B-85E4-D771936E01E0@oracle.com> <57084AD7.70707@oracle.com> Message-ID: <70F6B1A9-F8F1-492F-90DC-3308D0621F46@oracle.com> Hi Amanda, This is better. On the other hand, I read the bug report and am not sure if this is the correct way to fix it. Maybe the ("java.security.SecurityPermission" "putProviderProperty.SunDeploy-MozillaJSS") permission should be granted? Or maybe this is a source bug? Artem reported that the problem is only on linux-x86. It's better we get a consistent behavior across platforms. Thanks, Max > On Apr 9, 2016, at 8:20 AM, Amanda Jiang wrote: > > Hi Max, > > Thanks for reviewing, you are right, "sm" should be the correct argument. > I updated the test argument and PKCS11Test, please check the new webrev: > http://cr.openjdk.java.net/~amjiang/8153545/webrev.02/ > > Thanks, > Amanda > > On 16/4/8 ??12:28, Wang Weijun wrote: >> Hi Amanda >> >> I am not familiar with the tests, but it looks like the 1st args argument should be "sm" [1] to enable the security manager, not "true". >> >> If PKCS11Test always uses args as command and optional argument(s), maybe you should throw an exception if the command is unknown. >> >> Thanks >> Max >> >> [1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/cac52c9da800/test/sun/security/pkcs11/PKCS11Test.java#l184 >> >> >>> On Apr 8, 2016, at 1:09 PM, Amanda Jiang wrote: >>> >>> Hi All, >>> >>> Please help to review following changeset which fixes test bug for sun/security/pkcs11/Provider/Login.sh and another similar failed test. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153545 >>> Changest: http://cr.openjdk.java.net/~amjiang/8153545/webrev.01/ >>> >>> Thanks, >>> Amanda > From anthony.scarpino at oracle.com Mon Apr 11 15:59:35 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 11 Apr 2016 08:59:35 -0700 Subject: RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions In-Reply-To: <56D477F3.9030802@oracle.com> References: <56D477F3.9030802@oracle.com> Message-ID: <570BC9E7.4020806@oracle.com> I believe I have addressed all previous comments and some changes were made to rename cacerts to jdkCA and how it works AnchorCertificates.java http://cr.openjdk.java.net/~ascarpino/8140422/webrev.03/ Tony On 02/29/2016 08:55 AM, Anthony Scarpino wrote: > I need a code review of this change: > > http://cr.openjdk.java.net/~ascarpino/8140422/webrev/ > > Currently CertPath algorithm restrictions allow or deny all > certificates. This change adds the ability to reject certificate chains > that contain a restricted algorithm and the chain terminates at a root > CA; therefore, allowing a self-signed or chain that does not terminate > at a root CA. > > https://bugs.openjdk.java.net/browse/JDK-8140422 > > Thanks > > Tony > From anthony.scarpino at oracle.com Mon Apr 11 15:59:44 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 11 Apr 2016 08:59:44 -0700 Subject: RFR 8152205: jdk.security.provider.preferred is ambiguously documented In-Reply-To: <5706AA08.3060600@oracle.com> References: <57057E5F.2050601@oracle.com> <5705920B.4070106@oracle.com> <5705A89A.7000103@oracle.com> <288B522F-61DF-444A-B462-FFE089391998@oracle.com> <5706AA08.3060600@oracle.com> Message-ID: <570BC9F0.2060500@oracle.com> Ok.. I changed it to: {@code jdk.security.provider.preferred} {@link Security#getProperty(String) Security} I updated it at the same link if someone wants to double check my work http://cr.openjdk.java.net/~ascarpino/8152205/webrev/ Tony On 04/07/2016 11:42 AM, Bradford Wetmore wrote: > On 4/6/2016 6:40 PM, Wang Weijun wrote: >> In my DRBG changeset, I use this style: >> >> {@code jdk.security.provider.preferred} {@linkplain >> Security#getProperty(String) security property} > > I like this or > > {@code jdk.security.provider.preferred} {@link > Security#getProperty(String) Security) > > Brad > > >> >> >> >>> On Apr 7, 2016, at 8:23 AM, Bradford Wetmore >>> wrote: >>> >>> If I was doing this from scratch, I would probably capitalize it to >>> indicate it's a java.security.Security property and add inside the >>> @code. >>> >>> {@code jdk.security.provider.preferred} security >>> -> >>> {@code jdk.security.provider.preferred Security} >>> >>> But I see it done that way in other places, so this is fine. >>> >>> Brad >>> >>> >>> >>> On 4/6/2016 3:47 PM, Xuelei Fan wrote: >>>> Looks fine to me. >>>> >>>> Xuelei >>>> >>>> On 4/7/2016 5:23 AM, Anthony Scarpino wrote: >>>>> I need a review of this very simple doc clarification. Calling out >>>>> jdk.security.provider.preferred as a "security property" instead of >>>>> just >>>>> a "property". >>>>> >>>>> http://cr.openjdk.java.net/~ascarpino/8152205/webrev/ >>>>> >>>>> thanks. >>>>> >>>>> Tony >>>> >> From rajan.halade at oracle.com Mon Apr 11 17:31:47 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Mon, 11 Apr 2016 10:31:47 -0700 Subject: RFR: [9]: 8055351: sun/security/provider/DSA/TestAlgParameterGenerator.java failed with interrupted! (timed out?) In-Reply-To: <57082BC9.2090006@oracle.com> References: <57082241.2070302@oracle.com> <57082BC9.2090006@oracle.com> Message-ID: <570BDF83.4090203@oracle.com> On 4/8/16 3:08 PM, Valerie Peng wrote: > > Maybe you can just remove the comments on 103 and 104 for now. I think this comment has good information. If okay, I will like to retain it. > How did u come to the 600 timeout value? Just curious. Nothing specific, it is hard to decide acceptable timeout value here. Thanks, Rajan > Rest looks fine. > Thanks, > Valerie > > On 4/8/2016 2:27 PM, Rajan Halade wrote: >> Please help with your review of following patch to >> TestAlgParameterGenerator test. It allows test more time to run, not >> run in othervm, and few more trivial updates. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8055351 >> Webrev: http://cr.openjdk.java.net/~rhalade/8055351/webrev.00/ >> >> Thanks, >> Rajan From artem.smotrakov at oracle.com Mon Apr 11 17:33:53 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 11 Apr 2016 10:33:53 -0700 Subject: RFR 8153545: sun/security/pkcs11/Provider/Login.sh fails on Linux In-Reply-To: <70F6B1A9-F8F1-492F-90DC-3308D0621F46@oracle.com> References: <57073D08.9020007@oracle.com> <80FBE556-3CA4-4C0B-85E4-D771936E01E0@oracle.com> <57084AD7.70707@oracle.com> <70F6B1A9-F8F1-492F-90DC-3308D0621F46@oracle.com> Message-ID: <570BE001.4070502@oracle.com> Hi Max, The policy files already have SecurityPermission "putProviderProperty.*", PKCS11Test class is quite complex. PKCS11Test needs to be run without specifying -Djava.secutity.manager. In PKCS11Test.main(), if args[0] is "sm", then the class enables a security manager right before actual test cases run (it was done to avoid granting lots of permissions because PKCS11Tests does some work before actual test cases run). http://hg.openjdk.java.net/jdk9/dev/jdk/file/bb8379287f37/test/sun/security/pkcs11/PKCS11Test.java#l156 ... try { if (enableSM) { System.setSecurityManager(new SecurityManager()); } long start = System.currentTimeMillis(); System.out.printf( "Running test with provider %s (security manager %s) ...%n", p.getName(), enableSM ? "enabled" : "disabled"); ... http://hg.openjdk.java.net/jdk9/dev/jdk/file/bb8379287f37/test/sun/security/pkcs11/PKCS11Test.java#l182 ... public static void main(PKCS11Test test, String[] args) throws Exception { if (args != null) { if (args.length > 0 && "sm".equals(args[0])) { test.enableSM = true; } if (test.enableSM) { System.setProperty("java.security.policy", (args.length > 1) ? BASE + SEP + args[1] : DEFAULT_POLICY); } } ... It also overrides "java.security.policy" if a security manager is set. If there is no args[1] element, it sets it as DEFAULT_POLICY which doesn't exist for this test. As a result, a wrong policy is used, and ACE occurs. That's why correct policy file name should be passed in args[1]. Artem On 04/09/2016 01:46 AM, Wang Weijun wrote: > Hi Amanda, > > This is better. > > On the other hand, I read the bug report and am not sure if this is the correct way to fix it. Maybe the ("java.security.SecurityPermission" "putProviderProperty.SunDeploy-MozillaJSS") permission should be granted? Or maybe this is a source bug? Artem reported that the problem is only on linux-x86. It's better we get a consistent behavior across platforms. > > Thanks, > Max > >> On Apr 9, 2016, at 8:20 AM, Amanda Jiang wrote: >> >> Hi Max, >> >> Thanks for reviewing, you are right, "sm" should be the correct argument. >> I updated the test argument and PKCS11Test, please check the new webrev: >> http://cr.openjdk.java.net/~amjiang/8153545/webrev.02/ >> >> Thanks, >> Amanda >> >> On 16/4/8 ??12:28, Wang Weijun wrote: >>> Hi Amanda >>> >>> I am not familiar with the tests, but it looks like the 1st args argument should be "sm" [1] to enable the security manager, not "true". >>> >>> If PKCS11Test always uses args as command and optional argument(s), maybe you should throw an exception if the command is unknown. >>> >>> Thanks >>> Max >>> >>> [1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/cac52c9da800/test/sun/security/pkcs11/PKCS11Test.java#l184 >>> >>> >>>> On Apr 8, 2016, at 1:09 PM, Amanda Jiang wrote: >>>> >>>> Hi All, >>>> >>>> Please help to review following changeset which fixes test bug for sun/security/pkcs11/Provider/Login.sh and another similar failed test. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153545 >>>> Changest: http://cr.openjdk.java.net/~amjiang/8153545/webrev.01/ >>>> >>>> Thanks, >>>> Amanda From amanda.jiang at oracle.com Mon Apr 11 22:12:47 2016 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Mon, 11 Apr 2016 15:12:47 -0700 Subject: RFR 8153545: sun/security/pkcs11/Provider/Login.sh fails on Linux In-Reply-To: <70F6B1A9-F8F1-492F-90DC-3308D0621F46@oracle.com> References: <57073D08.9020007@oracle.com> <80FBE556-3CA4-4C0B-85E4-D771936E01E0@oracle.com> <57084AD7.70707@oracle.com> <70F6B1A9-F8F1-492F-90DC-3308D0621F46@oracle.com> Message-ID: <570C215F.8090407@oracle.com> Hi Max, Please see details in line. On 16/4/9 ??1:46, Wang Weijun wrote: > Hi Amanda, > > This is better. > > On the other hand, I read the bug report and am not sure if this is the correct way to fix it. Maybe the ("java.security.SecurityPermission" "putProviderProperty.SunDeploy-MozillaJSS") permission should be granted? SecurityPermission "putProviderProperty.*" is granted in the policy files(Login.policy and Basic.policy), and those policy files are parsed to PKCS11Test class as arguments. Please check details in Artem's reply to this email thread. > Or maybe this is a source bug? Artem reported that the problem is only on linux-x86. It's better we get a consistent behavior across platforms. This bug is not only happened on Linux-x86, at least we found same failures on Linux-x86, Linux-x64 and MacOSX so far. More reported failures are recorded at bug : https://bugs.openjdk.java.net/browse/JDK-8153545 I will submit a JPRT run with latest 9-dev repo and my changesset, to make sure this fix will work on all platform. Thanks, Amanda > > Thanks, > Max > >> On Apr 9, 2016, at 8:20 AM, Amanda Jiang wrote: >> >> Hi Max, >> >> Thanks for reviewing, you are right, "sm" should be the correct argument. >> I updated the test argument and PKCS11Test, please check the new webrev: >> http://cr.openjdk.java.net/~amjiang/8153545/webrev.02/ >> >> Thanks, >> Amanda >> >> On 16/4/8 ??12:28, Wang Weijun wrote: >>> Hi Amanda >>> >>> I am not familiar with the tests, but it looks like the 1st args argument should be "sm" [1] to enable the security manager, not "true". >>> >>> If PKCS11Test always uses args as command and optional argument(s), maybe you should throw an exception if the command is unknown. >>> >>> Thanks >>> Max >>> >>> [1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/cac52c9da800/test/sun/security/pkcs11/PKCS11Test.java#l184 >>> >>> >>>> On Apr 8, 2016, at 1:09 PM, Amanda Jiang wrote: >>>> >>>> Hi All, >>>> >>>> Please help to review following changeset which fixes test bug for sun/security/pkcs11/Provider/Login.sh and another similar failed test. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153545 >>>> Changest: http://cr.openjdk.java.net/~amjiang/8153545/webrev.01/ >>>> >>>> Thanks, >>>> Amanda From rajan.halade at oracle.com Mon Apr 11 23:44:01 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Mon, 11 Apr 2016 16:44:01 -0700 Subject: RFR: [9]: 8153829: javax/net/ssl/Stapling/HttpsUrlConnClient.java fails intermittently with NullPointerException Message-ID: <570C36C1.3080809@oracle.com> Please help with your review of following patch to OCSP stapling tests. HttpsUrlConnClient test failed intermittently with NPE because OCSP server was not ready. With this patch, SimpleOCSPServer indicates server ready to accept connections. Similar fix is applied to other tests in this area. Bug: https://bugs.openjdk.java.net/browse/JDK-8153829 Webrev: http://cr.openjdk.java.net/~rhalade/8153829/webrev.00/ Thanks, Rajan From weijun.wang at oracle.com Tue Apr 12 01:26:28 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 12 Apr 2016 09:26:28 +0800 Subject: RFR 8153545: sun/security/pkcs11/Provider/Login.sh fails on Linux In-Reply-To: <570C215F.8090407@oracle.com> References: <57073D08.9020007@oracle.com> <80FBE556-3CA4-4C0B-85E4-D771936E01E0@oracle.com> <57084AD7.70707@oracle.com> <70F6B1A9-F8F1-492F-90DC-3308D0621F46@oracle.com> <570C215F.8090407@oracle.com> Message-ID: <1FAC1883-27F9-496B-8370-C5B4E3FD1AB4@oracle.com> Hi Amanda and Artem, >>> http://cr.openjdk.java.net/~amjiang/8153545/webrev.02/ So, if "Clazz sm [policy]" is the preferred way to launch a test and we don't care about access controls outside the main(Provider) method, I'm OK with the fix. There is a KeyStore/Solaris.sh test using -Djava.security.manager. Should it be modified in the same way? Thanks, Max From xuelei.fan at oracle.com Tue Apr 12 11:08:59 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 12 Apr 2016 19:08:59 +0800 Subject: RFR: [9]: 8153829: javax/net/ssl/Stapling/HttpsUrlConnClient.java fails intermittently with NullPointerException In-Reply-To: <570C36C1.3080809@oracle.com> References: <570C36C1.3080809@oracle.com> Message-ID: <570CD74B.7050103@oracle.com> Looks fine to me except two minor comments: test/java/security/testlibrary/SimpleOCSPServer.java ------------- 254 serverReady = false; For safe, I may put line 215-254 into a try-final block. test/javax/net/ssl/Stapling/HttpsUrlConnClient.java ------------- 301 // Wait 5 seconds for server ready The comment says "5 seconds", but the actual implementation is 1 second. 5 seconds may reduce the frequency of intermittent failure. I would like to use 5 second wait and update the implementation (line 305-307). Similar to other test cases. Thanks, Xuelei On 4/12/2016 7:44 AM, Rajan Halade wrote: > Please help with your review of following patch to OCSP stapling tests. > HttpsUrlConnClient test failed intermittently with NPE because OCSP > server was not ready. With this patch, SimpleOCSPServer indicates server > ready to accept connections. Similar fix is applied to other tests in > this area. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153829 > Webrev: http://cr.openjdk.java.net/~rhalade/8153829/webrev.00/ > > Thanks, > Rajan From rajan.halade at oracle.com Tue Apr 12 14:53:50 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 12 Apr 2016 07:53:50 -0700 Subject: RFR: [9]: 8153829: javax/net/ssl/Stapling/HttpsUrlConnClient.java fails intermittently with NullPointerException In-Reply-To: <570CD74B.7050103@oracle.com> References: <570C36C1.3080809@oracle.com> <570CD74B.7050103@oracle.com> Message-ID: <570D0BFE.4020907@oracle.com> On 4/12/16 4:08 AM, Xuelei Fan wrote: > Looks fine to me except two minor comments: > > test/java/security/testlibrary/SimpleOCSPServer.java > ------------- > 254 serverReady = false; > For safe, I may put line 215-254 into a try-final block. Fixed this and uploaded correct webrev http://cr.openjdk.java.net/~rhalade/8153829/webrev.01/, thanks! - Rajan > > test/javax/net/ssl/Stapling/HttpsUrlConnClient.java > ------------- > 301 // Wait 5 seconds for server ready > The comment says "5 seconds", but the actual implementation is 1 second. > 5 seconds may reduce the frequency of intermittent failure. I would > like to use 5 second wait and update the implementation (line 305-307). > > Similar to other test cases. > > Thanks, > Xuelei > > > On 4/12/2016 7:44 AM, Rajan Halade wrote: >> Please help with your review of following patch to OCSP stapling tests. >> HttpsUrlConnClient test failed intermittently with NPE because OCSP >> server was not ready. With this patch, SimpleOCSPServer indicates server >> ready to accept connections. Similar fix is applied to other tests in >> this area. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153829 >> Webrev: http://cr.openjdk.java.net/~rhalade/8153829/webrev.00/ >> >> Thanks, >> Rajan From xuelei.fan at oracle.com Tue Apr 12 15:03:23 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 12 Apr 2016 23:03:23 +0800 Subject: RFR: [9]: 8153829: javax/net/ssl/Stapling/HttpsUrlConnClient.java fails intermittently with NullPointerException In-Reply-To: <570D0BFE.4020907@oracle.com> References: <570C36C1.3080809@oracle.com> <570CD74B.7050103@oracle.com> <570D0BFE.4020907@oracle.com> Message-ID: <570D0E3B.2070107@oracle.com> > http://cr.openjdk.java.net/~rhalade/8153829/webrev.01/ Looks fine to me. Thanks! Xuelei On 4/12/2016 10:53 PM, Rajan Halade wrote: > > > On 4/12/16 4:08 AM, Xuelei Fan wrote: >> Looks fine to me except two minor comments: >> >> test/java/security/testlibrary/SimpleOCSPServer.java >> ------------- >> 254 serverReady = false; >> For safe, I may put line 215-254 into a try-final block. > Fixed this and uploaded correct webrev > http://cr.openjdk.java.net/~rhalade/8153829/webrev.01/, thanks! > > - Rajan >> >> test/javax/net/ssl/Stapling/HttpsUrlConnClient.java >> ------------- >> 301 // Wait 5 seconds for server ready >> The comment says "5 seconds", but the actual implementation is 1 second. >> 5 seconds may reduce the frequency of intermittent failure. I would >> like to use 5 second wait and update the implementation (line 305-307). >> >> Similar to other test cases. >> >> Thanks, >> Xuelei >> >> >> On 4/12/2016 7:44 AM, Rajan Halade wrote: >>> Please help with your review of following patch to OCSP stapling tests. >>> HttpsUrlConnClient test failed intermittently with NPE because OCSP >>> server was not ready. With this patch, SimpleOCSPServer indicates server >>> ready to accept connections. Similar fix is applied to other tests in >>> this area. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153829 >>> Webrev: http://cr.openjdk.java.net/~rhalade/8153829/webrev.00/ >>> >>> Thanks, >>> Rajan > From sean.mullan at oracle.com Tue Apr 12 19:39:55 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 12 Apr 2016 15:39:55 -0400 Subject: RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions In-Reply-To: <570BC9E7.4020806@oracle.com> References: <56D477F3.9030802@oracle.com> <570BC9E7.4020806@oracle.com> Message-ID: <570D4F0B.50307@oracle.com> On 04/11/2016 11:59 AM, Anthony Scarpino wrote: > I believe I have addressed all previous comments and some changes were > made to rename cacerts to jdkCA and how it works AnchorCertificates.java > > http://cr.openjdk.java.net/~ascarpino/8140422/webrev.03/ * CertConstraintParameters 31 * This class is a wrapper for keeping state and passing objects betweenPKIX, s/betweenPKIX/between PKIX/ * AnchorCertificates The comments on lines 40-44 need to be updated now that you have changed the implementation. Also you don't really need the surrounding double quotes. --Sean > > Tony > > On 02/29/2016 08:55 AM, Anthony Scarpino wrote: >> I need a code review of this change: >> >> http://cr.openjdk.java.net/~ascarpino/8140422/webrev/ >> >> Currently CertPath algorithm restrictions allow or deny all >> certificates. This change adds the ability to reject certificate chains >> that contain a restricted algorithm and the chain terminates at a root >> CA; therefore, allowing a self-signed or chain that does not terminate >> at a root CA. >> >> https://bugs.openjdk.java.net/browse/JDK-8140422 >> >> Thanks >> >> Tony >> > From valerie.peng at oracle.com Wed Apr 13 00:26:00 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 12 Apr 2016 17:26:00 -0700 Subject: Code Review Request 8072452 Support DHE sizes up to 8192-bits In-Reply-To: <56FE9961.8090806@Oracle.COM> References: <56FE9961.8090806@Oracle.COM> Message-ID: <570D9218.2050200@oracle.com> Hi Xuelei, Mostly look good, just some comments in line... line 95-100, so essentially, we will use the built-in parameters as much as possible and if none available, we will try to generate the parameters for key sizes <= 1024, right? The current comment is a little hard to parse. Maybe we can just explain it as below? // Use the built-in parameters (ranging from 512 to 8192) when available this.params = ParameterCache.getCachedDHParameterSpec(keysize); // Due to performance issue, only support DH parameters generation // up to 1024 bits if ((this.params == null) && (keysize > 1024)) { - line 212, redundant? - line 277-303, the "params"argument for this particular method is always null for non-RSA algorithms based on the usage. It is commented on line 232 and several other places as indicated by the "// XXX sanity check params" comments. So, more code changes will be needed here. Either you can add another boolean hasParams and rely on that argument, or change the specified argument type from RSAKeyGenParameterSpec to a generic one and then cast it later when it is needed. - line 141 - 146 and line 1548 - 1554 are identical. Seems to me that they can be customized a little as they are for different variable assignment. The "customizedDHKeySize" variable on line 147 is from user, right? Maybe what you really mean is something like the following? // DH parameter generation can be extremely slow, best to use one of the // supported pre-computed DH parameters (see DHCrypt class) As for line 1548 - 1554, it can be as simple as: // DH parameter generation can be extremely slow, make sure to use one of the // supported pre-computed DH parameters (see DHCrypt class) - line 148, can customizedDHKeySize be 1024? The old code accepts it but the new code will error out. Is there a reason for rejecting 1024? The check only rejects "<1024" but yet the exception message says the value should be larger than 1024. Lastly, "should larger" => "should be larger" (line 150). I will look at the tests next and send u comments separately. Thanks, Valerie On 4/1/2016 8:53 AM, Xuelei Fan wrote: > Hi, > > Please review this improvement update to support DHE sizes up to > 8192-bits and DSA sizes up to 3072-bits: > > http://cr.openjdk.java.net/~xuelei/8072452/webrev.00 > > This updated extends to support 3072-bits DH and DSA parameters > generation, and pre-computed DH parameters up to 8192 bits and > pre-computed DSA parameters up to 3072-bits. > > Thanks, > Xuelei From xuelei.fan at oracle.com Wed Apr 13 00:36:39 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 13 Apr 2016 08:36:39 +0800 Subject: RFR 8152205: jdk.security.provider.preferred is ambiguously documented In-Reply-To: <570BC9F0.2060500@oracle.com> References: <57057E5F.2050601@oracle.com> <5705920B.4070106@oracle.com> <5705A89A.7000103@oracle.com> <288B522F-61DF-444A-B462-FFE089391998@oracle.com> <5706AA08.3060600@oracle.com> <570BC9F0.2060500@oracle.com> Message-ID: <570D9497.1050704@oracle.com> Looks fine to me. Thanks, Xuelei On 4/11/2016 11:59 PM, Anthony Scarpino wrote: > Ok.. I changed it to: > {@code jdk.security.provider.preferred} {@link > Security#getProperty(String) Security} > > I updated it at the same link if someone wants to double check my work > http://cr.openjdk.java.net/~ascarpino/8152205/webrev/ > > Tony > > On 04/07/2016 11:42 AM, Bradford Wetmore wrote: >> On 4/6/2016 6:40 PM, Wang Weijun wrote: >>> In my DRBG changeset, I use this style: >>> >>> {@code jdk.security.provider.preferred} {@linkplain >>> Security#getProperty(String) security property} >> >> I like this or >> >> {@code jdk.security.provider.preferred} {@link >> Security#getProperty(String) Security) >> >> Brad >> >> >>> >>> >>> >>>> On Apr 7, 2016, at 8:23 AM, Bradford Wetmore >>>> wrote: >>>> >>>> If I was doing this from scratch, I would probably capitalize it to >>>> indicate it's a java.security.Security property and add inside the >>>> @code. >>>> >>>> {@code jdk.security.provider.preferred} security >>>> -> >>>> {@code jdk.security.provider.preferred Security} >>>> >>>> But I see it done that way in other places, so this is fine. >>>> >>>> Brad >>>> >>>> >>>> >>>> On 4/6/2016 3:47 PM, Xuelei Fan wrote: >>>>> Looks fine to me. >>>>> >>>>> Xuelei >>>>> >>>>> On 4/7/2016 5:23 AM, Anthony Scarpino wrote: >>>>>> I need a review of this very simple doc clarification. Calling out >>>>>> jdk.security.provider.preferred as a "security property" instead of >>>>>> just >>>>>> a "property". >>>>>> >>>>>> http://cr.openjdk.java.net/~ascarpino/8152205/webrev/ >>>>>> >>>>>> thanks. >>>>>> >>>>>> Tony >>>>> >>> > From amanda.jiang at oracle.com Wed Apr 13 04:00:03 2016 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Tue, 12 Apr 2016 21:00:03 -0700 Subject: RFR 8153545: sun/security/pkcs11/Provider/Login.sh fails on Linux In-Reply-To: <1FAC1883-27F9-496B-8370-C5B4E3FD1AB4@oracle.com> References: <57073D08.9020007@oracle.com> <80FBE556-3CA4-4C0B-85E4-D771936E01E0@oracle.com> <57084AD7.70707@oracle.com> <70F6B1A9-F8F1-492F-90DC-3308D0621F46@oracle.com> <570C215F.8090407@oracle.com> <1FAC1883-27F9-496B-8370-C5B4E3FD1AB4@oracle.com> Message-ID: <570DC443.9040300@oracle.com> Hi Max, I think it would be better to update Solaris.sh with same format of other scripts, please check the latest changeset: http://cr.openjdk.java.net/~amjiang/8153545/webrev.03/ JPRT run is completed and all 3 tests has been passed in all platforms ( except Login.sh is excluded from windows platform by other bug) http://scaaa637.us.oracle.com/archive/2016/04/2016-04-13-012305.javase.dev2/logs/ Thanks, Amanda On 16/4/11 ??6:26, Wang Weijun wrote: > Hi Amanda and Artem, > >>>> http://cr.openjdk.java.net/~amjiang/8153545/webrev.02/ > So, if "Clazz sm [policy]" is the preferred way to launch a test and we don't care about access controls outside the main(Provider) method, I'm OK with the fix. > > There is a KeyStore/Solaris.sh test using -Djava.security.manager. Should it be modified in the same way? > > Thanks, > Max > > From xuelei.fan at oracle.com Wed Apr 13 14:23:26 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 13 Apr 2016 22:23:26 +0800 Subject: Code Review Request 8072452 Support DHE sizes up to 8192-bits In-Reply-To: <570D9218.2050200@oracle.com> References: <56FE9961.8090806@Oracle.COM> <570D9218.2050200@oracle.com> Message-ID: <570E565E.2000104@oracle.com> Hi Valerie, All comments are good to me and accepted in the new webrev: http://cr.openjdk.java.net/~xuelei/8072452/webrev.02/ On 4/13/2016 8:26 AM, Valerie Peng wrote: > Hi Xuelei, > > Mostly look good, just some comments in line... > > > > line 95-100, so essentially, we will use the built-in parameters as much > as possible and if none available, we will try to generate the > parameters for key sizes <= 1024, right? The current comment is a little > hard to parse. Maybe we can just explain it as below? > // Use the built-in parameters (ranging from 512 to 8192) when > available > this.params = ParameterCache.getCachedDHParameterSpec(keysize); > // Due to performance issue, only support DH parameters generation > // up to 1024 bits > if ((this.params == null) && (keysize > 1024)) { > Updated. > > > - line 212, redundant? Yes. Updated. > > > - line 277-303, the "params"argument for this particular method is > always null for non-RSA algorithms based on the usage. It is commented > on line 232 and several other places as indicated by the "// XXX sanity > check params" comments. So, more code changes will be needed here. > Either you can add another boolean hasParams and rely on that argument, > or change the specified argument type from RSAKeyGenParameterSpec to a > generic one and then cast it later when it is needed. > Good catch! Updated per the latter proposal. > > - line 141 - 146 and line 1548 - 1554 are identical. Seems to me that > they can be customized a little as they are for different variable > assignment. The "customizedDHKeySize" variable on line 147 is from user, > right? Maybe what you really mean is something like the following? > // DH parameter generation can be extremely slow, best to use one of > the > // supported pre-computed DH parameters (see DHCrypt class) > As for line 1548 - 1554, it can be as simple as: > // DH parameter generation can be extremely slow, make sure to use > one of the > // supported pre-computed DH parameters (see DHCrypt class) Updated. > - line 148, can customizedDHKeySize be 1024? The old code accepts it but > the new code will error out. Is there a reason for rejecting 1024? The > check only rejects "<1024" but yet the exception message says the value > should be larger than 1024. > Lastly, "should larger" => "should be larger" (line 150). > 1024 bits should not be rejected. Updated the exception message. Thanks for the comments! Xuelei > I will look at the tests next and send u comments separately. > Thanks, > Valerie > On 4/1/2016 8:53 AM, Xuelei Fan wrote: >> Hi, >> >> Please review this improvement update to support DHE sizes up to >> 8192-bits and DSA sizes up to 3072-bits: >> >> http://cr.openjdk.java.net/~xuelei/8072452/webrev.00 >> >> This updated extends to support 3072-bits DH and DSA parameters >> generation, and pre-computed DH parameters up to 8192 bits and >> pre-computed DSA parameters up to 3072-bits. >> >> Thanks, >> Xuelei From weijun.wang at oracle.com Wed Apr 13 14:23:26 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 13 Apr 2016 22:23:26 +0800 Subject: RFR 8153545: sun/security/pkcs11/Provider/Login.sh fails on Linux In-Reply-To: <570DC443.9040300@oracle.com> References: <57073D08.9020007@oracle.com> <80FBE556-3CA4-4C0B-85E4-D771936E01E0@oracle.com> <57084AD7.70707@oracle.com> <70F6B1A9-F8F1-492F-90DC-3308D0621F46@oracle.com> <570C215F.8090407@oracle.com> <1FAC1883-27F9-496B-8370-C5B4E3FD1AB4@oracle.com> <570DC443.9040300@oracle.com> Message-ID: Everything looks fine. Thanks Max > On Apr 13, 2016, at 12:00 PM, Amanda Jiang wrote: > > Hi Max, > > I think it would be better to update Solaris.sh with same format of other scripts, please check the latest changeset: > http://cr.openjdk.java.net/~amjiang/8153545/webrev.03/ > JPRT run is completed and all 3 tests has been passed in all platforms ( except Login.sh is excluded from windows platform by other bug) > Thanks, > Amanda > > On 16/4/11 ??6:26, Wang Weijun wrote: >> Hi Amanda and Artem, >> >>>>> http://cr.openjdk.java.net/~amjiang/8153545/webrev.02/ >> So, if "Clazz sm [policy]" is the preferred way to launch a test and we don't care about access controls outside the main(Provider) method, I'm OK with the fix. >> >> There is a KeyStore/Solaris.sh test using -Djava.security.manager. Should it be modified in the same way? >> >> Thanks, >> Max >> >> > From anthony.scarpino at oracle.com Wed Apr 13 16:49:37 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 13 Apr 2016 09:49:37 -0700 Subject: RFR 8152205: jdk.security.provider.preferred is ambiguously documented In-Reply-To: <570D9497.1050704@oracle.com> References: <57057E5F.2050601@oracle.com> <5705920B.4070106@oracle.com> <5705A89A.7000103@oracle.com> <288B522F-61DF-444A-B462-FFE089391998@oracle.com> <5706AA08.3060600@oracle.com> <570BC9F0.2060500@oracle.com> <570D9497.1050704@oracle.com> Message-ID: <570E78A1.7040709@oracle.com> Thanks Tony On 04/12/2016 05:36 PM, Xuelei Fan wrote: > Looks fine to me. > > Thanks, > Xuelei > > On 4/11/2016 11:59 PM, Anthony Scarpino wrote: >> Ok.. I changed it to: >> {@code jdk.security.provider.preferred} {@link >> Security#getProperty(String) Security} >> >> I updated it at the same link if someone wants to double check my work >> http://cr.openjdk.java.net/~ascarpino/8152205/webrev/ >> >> Tony >> >> On 04/07/2016 11:42 AM, Bradford Wetmore wrote: >>> On 4/6/2016 6:40 PM, Wang Weijun wrote: >>>> In my DRBG changeset, I use this style: >>>> >>>> {@code jdk.security.provider.preferred} {@linkplain >>>> Security#getProperty(String) security property} >>> >>> I like this or >>> >>> {@code jdk.security.provider.preferred} {@link >>> Security#getProperty(String) Security) >>> >>> Brad >>> >>> >>>> >>>> >>>> >>>>> On Apr 7, 2016, at 8:23 AM, Bradford Wetmore >>>>> wrote: >>>>> >>>>> If I was doing this from scratch, I would probably capitalize it to >>>>> indicate it's a java.security.Security property and add inside the >>>>> @code. >>>>> >>>>> {@code jdk.security.provider.preferred} security >>>>> -> >>>>> {@code jdk.security.provider.preferred Security} >>>>> >>>>> But I see it done that way in other places, so this is fine. >>>>> >>>>> Brad >>>>> >>>>> >>>>> >>>>> On 4/6/2016 3:47 PM, Xuelei Fan wrote: >>>>>> Looks fine to me. >>>>>> >>>>>> Xuelei >>>>>> >>>>>> On 4/7/2016 5:23 AM, Anthony Scarpino wrote: >>>>>>> I need a review of this very simple doc clarification. Calling out >>>>>>> jdk.security.provider.preferred as a "security property" instead of >>>>>>> just >>>>>>> a "property". >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ascarpino/8152205/webrev/ >>>>>>> >>>>>>> thanks. >>>>>>> >>>>>>> Tony >>>>>> >>>> >> > From rajan.halade at oracle.com Wed Apr 13 19:24:57 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Wed, 13 Apr 2016 12:24:57 -0700 Subject: RFR: [9]: 8154196: Mark javax/net/ssl/DTLS/CipherSuite.java as intermittently failing Message-ID: <570E9D09.3020908@oracle.com> The test javax/net/ssl/DTLS/CipherSuite.java has been seen to fail intermittently, see bug 8132320, 8130460. The test should be marked accordingly. diff -r 32bb1700f683 test/javax/net/ssl/DTLS/CipherSuite.java --- a/test/javax/net/ssl/DTLS/CipherSuite.java Tue Apr 05 21:18:01 2016 +0100 +++ b/test/javax/net/ssl/DTLS/CipherSuite.java Wed Apr 13 12:21:48 2016 -0700 @@ -27,6 +27,7 @@ /* * @test * @bug 8043758 + * @key intermittent * @summary Datagram Transport Layer Security (DTLS) * @modules java.base/sun.security.util * @build DTLSOverDatagram Thanks, Rajan From Xuelei.Fan at Oracle.Com Wed Apr 13 20:47:27 2016 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Thu, 14 Apr 2016 04:47:27 +0800 Subject: RFR: [9]: 8154196: Mark javax/net/ssl/DTLS/CipherSuite.java as intermittently failing In-Reply-To: <570E9D09.3020908@oracle.com> References: <570E9D09.3020908@oracle.com> Message-ID: <24496425-E19A-4C0A-B4C6-87FA887B724B@Oracle.Com> OK xuelei > On Apr 14, 2016, at 3:24 AM, Rajan Halade wrote: > > The test javax/net/ssl/DTLS/CipherSuite.java has been seen to fail intermittently, see bug 8132320, 8130460. > > The test should be marked accordingly. > > diff -r 32bb1700f683 test/javax/net/ssl/DTLS/CipherSuite.java > --- a/test/javax/net/ssl/DTLS/CipherSuite.java Tue Apr 05 21:18:01 2016 +0100 > +++ b/test/javax/net/ssl/DTLS/CipherSuite.java Wed Apr 13 12:21:48 2016 -0700 > @@ -27,6 +27,7 @@ > /* > * @test > * @bug 8043758 > + * @key intermittent > * @summary Datagram Transport Layer Security (DTLS) > * @modules java.base/sun.security.util > * @build DTLSOverDatagram > > Thanks, > Rajan From valerie.peng at oracle.com Wed Apr 13 23:25:04 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 13 Apr 2016 16:25:04 -0700 Subject: Code Review Request 8072452 Support DHE sizes up to 8192-bits In-Reply-To: <570E565E.2000104@oracle.com> References: <56FE9961.8090806@Oracle.COM> <570D9218.2050200@oracle.com> <570E565E.2000104@oracle.com> Message-ID: <570ED550.5050509@oracle.com> Here are some comments for the test changes: - Not testing key size 768? - line 82, would be useful to indicate version here, e.g. NSS (as of version xxx) has a hard coded ... - line 27, 4096 should be 8192? - format changes only? No test for (3072, 256)? - line 50, dhp8192(8191) looks like a typo? - line 66, do we really need to generate the key pair here? - line 71, seem redundant and potentially confusing as it's aligned differently comparing to line70? - line 63, why test for KeyAgreement here instead of KeyPairGenerator? - line 53, dhp8192(8191) looks like a typo? - line 64, why test for KeyAgreement here instead of KeyPairGenerator? - line 75, do we really need to generate the key pair here? - line 80, seem redundant and potentially confusing as it's aligned differently comparing to line79? - Use "Param" instead of "Para" in the test name "SupportedDSAParaGen"? - Just curious, have u tried the specified timeout value across different platforms? - The file is new but the copyright year starts from 2012? As for the updated sources, all changes look fine. But while I was looking at src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java, I have some more questions: - line 145, do we need to check for upper limit here? It used to have 2048, should it be 8192 now? If yes, then line 1526 need to be enhanced too. - line 1551, now that more DH sizes are supported, shouldn't we make some changes here? Now it's either 1024 or 2048. The older impl on line 1550 uses 1024 as the lower limit and 2048 as the upper limit and will keep the value as is if it's in-between the limits. If there is a reason to keep 2048 as the upper limit, it'd be useful to add some comment here for clarification. Thanks, Valerie On 4/13/2016 7:23 AM, Xuelei Fan wrote: > Hi Valerie, > > All comments are good to me and accepted in the new webrev: > > http://cr.openjdk.java.net/~xuelei/8072452/webrev.02/ > > On 4/13/2016 8:26 AM, Valerie Peng wrote: >> Hi Xuelei, >> >> Mostly look good, just some comments in line... >> >> >> >> line 95-100, so essentially, we will use the built-in parameters as much >> as possible and if none available, we will try to generate the >> parameters for key sizes<= 1024, right? The current comment is a little >> hard to parse. Maybe we can just explain it as below? >> // Use the built-in parameters (ranging from 512 to 8192) when >> available >> this.params = ParameterCache.getCachedDHParameterSpec(keysize); >> // Due to performance issue, only support DH parameters generation >> // up to 1024 bits >> if ((this.params == null)&& (keysize> 1024)) { >> > Updated. > >> >> >> - line 212, redundant? > Yes. Updated. > >> >> >> - line 277-303, the "params"argument for this particular method is >> always null for non-RSA algorithms based on the usage. It is commented >> on line 232 and several other places as indicated by the "// XXX sanity >> check params" comments. So, more code changes will be needed here. >> Either you can add another boolean hasParams and rely on that argument, >> or change the specified argument type from RSAKeyGenParameterSpec to a >> generic one and then cast it later when it is needed. >> > Good catch! Updated per the latter proposal. > >> >> - line 141 - 146 and line 1548 - 1554 are identical. Seems to me that >> they can be customized a little as they are for different variable >> assignment. The "customizedDHKeySize" variable on line 147 is from user, >> right? Maybe what you really mean is something like the following? >> // DH parameter generation can be extremely slow, best to use one of >> the >> // supported pre-computed DH parameters (see DHCrypt class) >> As for line 1548 - 1554, it can be as simple as: >> // DH parameter generation can be extremely slow, make sure to use >> one of the >> // supported pre-computed DH parameters (see DHCrypt class) > Updated. > >> - line 148, can customizedDHKeySize be 1024? The old code accepts it but >> the new code will error out. Is there a reason for rejecting 1024? The >> check only rejects "<1024" but yet the exception message says the value >> should be larger than 1024. >> Lastly, "should larger" => "should be larger" (line 150). >> > 1024 bits should not be rejected. Updated the exception message. > > Thanks for the comments! > > Xuelei > >> I will look at the tests next and send u comments separately. >> Thanks, >> Valerie >> On 4/1/2016 8:53 AM, Xuelei Fan wrote: >>> Hi, >>> >>> Please review this improvement update to support DHE sizes up to >>> 8192-bits and DSA sizes up to 3072-bits: >>> >>> http://cr.openjdk.java.net/~xuelei/8072452/webrev.00 >>> >>> This updated extends to support 3072-bits DH and DSA parameters >>> generation, and pre-computed DH parameters up to 8192 bits and >>> pre-computed DSA parameters up to 3072-bits. >>> >>> Thanks, >>> Xuelei From xuelei.fan at oracle.com Thu Apr 14 11:12:05 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 14 Apr 2016 19:12:05 +0800 Subject: Code Review Request 8072452 Support DHE sizes up to 8192-bits In-Reply-To: <570ED550.5050509@oracle.com> References: <56FE9961.8090806@Oracle.COM> <570D9218.2050200@oracle.com> <570E565E.2000104@oracle.com> <570ED550.5050509@oracle.com> Message-ID: <570F7B05.6070101@oracle.com> Thanks for the comments. Here is the new webrev: http://cr.openjdk.java.net/~xuelei/8072452/webrev.03/ On 4/14/2016 7:25 AM, Valerie Peng wrote: > Here are some comments for the test changes: > > > - Not testing key size 768? > - line 82, would be useful to indicate version here, e.g. NSS (as of > version xxx) has a hard coded ... > - line 27, 4096 should be 8192? > Updated. > > - format changes only? No test for (3072, 256)? > I removed the update of this file. > > - line 50, dhp8192(8191) looks like a typo? > - line 66, do we really need to generate the key pair here? > - line 71, seem redundant and potentially confusing as it's aligned > differently comparing to line70? > Updated. > > - line 63, why test for KeyAgreement here instead of KeyPairGenerator? > Better to use KeyPairGenerator. Updated. > > - line 53, dhp8192(8191) looks like a typo? > - line 64, why test for KeyAgreement here instead of KeyPairGenerator? > - line 75, do we really need to generate the key pair here? > - line 80, seem redundant and potentially confusing as it's aligned > differently comparing to line79? > Updated. > > - Use "Param" instead of "Para" in the test name "SupportedDSAParaGen"? Hm, nice name. > - Just curious, have u tried the specified timeout value across > different platforms? Not really, I only tested on JPRT and the solaris-sparc desktop. This test may be intermittent timeout failure in some circumstances. I added the intermittent key tag. > - The file is new but the copyright year starts from 2012? > Updated. > As for the updated sources, all changes look fine. But while I was > looking at > src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java, I > have some more questions: > - line 145, do we need to check for upper limit here? It used to have > 2048, should it be 8192 now? If yes, then line 1526 need to be enhanced > too. I was wondering to remove the limit in case third party's implementation support more size. Not necessary. Updated and limited to 8192 bits. > - line 1551, now that more DH sizes are supported, shouldn't we make > some changes here? Now it's either 1024 or 2048. The older impl on line > 1550 uses 1024 as the lower limit and 2048 as the upper limit and will > keep the value as is if it's in-between the limits. If there is a reason > to keep 2048 as the upper limit, it'd be useful to add some comment here > for clarification. > This is mainly for compatibility and interoperability impact. Some old deployed application may not support DH key size bigger than 2048. I added back the comments. Thanks, Xuelei > Thanks, > Valerie > > On 4/13/2016 7:23 AM, Xuelei Fan wrote: >> Hi Valerie, >> >> All comments are good to me and accepted in the new webrev: >> >> http://cr.openjdk.java.net/~xuelei/8072452/webrev.02/ >> >> On 4/13/2016 8:26 AM, Valerie Peng wrote: >>> Hi Xuelei, >>> >>> Mostly look good, just some comments in line... >>> >>> >>> >>> >>> line 95-100, so essentially, we will use the built-in parameters as much >>> as possible and if none available, we will try to generate the >>> parameters for key sizes<= 1024, right? The current comment is a little >>> hard to parse. Maybe we can just explain it as below? >>> // Use the built-in parameters (ranging from 512 to 8192) when >>> available >>> this.params = ParameterCache.getCachedDHParameterSpec(keysize); >>> // Due to performance issue, only support DH parameters generation >>> // up to 1024 bits >>> if ((this.params == null)&& (keysize> 1024)) { >>> >> Updated. >> >>> >>> >>> >>> - line 212, redundant? >> Yes. Updated. >> >>> >>> >>> >>> - line 277-303, the "params"argument for this particular method is >>> always null for non-RSA algorithms based on the usage. It is commented >>> on line 232 and several other places as indicated by the "// XXX sanity >>> check params" comments. So, more code changes will be needed here. >>> Either you can add another boolean hasParams and rely on that argument, >>> or change the specified argument type from RSAKeyGenParameterSpec to a >>> generic one and then cast it later when it is needed. >>> >> Good catch! Updated per the latter proposal. >> >>> >>> - line 141 - 146 and line 1548 - 1554 are identical. Seems to me that >>> they can be customized a little as they are for different variable >>> assignment. The "customizedDHKeySize" variable on line 147 is from user, >>> right? Maybe what you really mean is something like the following? >>> // DH parameter generation can be extremely slow, best to use >>> one of >>> the >>> // supported pre-computed DH parameters (see DHCrypt class) >>> As for line 1548 - 1554, it can be as simple as: >>> // DH parameter generation can be extremely slow, make sure to use >>> one of the >>> // supported pre-computed DH parameters (see DHCrypt class) >> Updated. >> >>> - line 148, can customizedDHKeySize be 1024? The old code accepts it but >>> the new code will error out. Is there a reason for rejecting 1024? The >>> check only rejects "<1024" but yet the exception message says the value >>> should be larger than 1024. >>> Lastly, "should larger" => "should be larger" (line 150). >>> >> 1024 bits should not be rejected. Updated the exception message. >> >> Thanks for the comments! >> >> Xuelei >> >>> I will look at the tests next and send u comments separately. >>> Thanks, >>> Valerie >>> On 4/1/2016 8:53 AM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> Please review this improvement update to support DHE sizes up to >>>> 8192-bits and DSA sizes up to 3072-bits: >>>> >>>> http://cr.openjdk.java.net/~xuelei/8072452/webrev.00 >>>> >>>> This updated extends to support 3072-bits DH and DSA parameters >>>> generation, and pre-computed DH parameters up to 8192 bits and >>>> pre-computed DSA parameters up to 3072-bits. >>>> >>>> Thanks, >>>> Xuelei From sean.coffey at oracle.com Thu Apr 14 17:33:52 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 14 Apr 2016 18:33:52 +0100 Subject: Code Review Request 8072452 Support DHE sizes up to 8192-bits In-Reply-To: <570F7B05.6070101@oracle.com> References: <56FE9961.8090806@Oracle.COM> <570D9218.2050200@oracle.com> <570E565E.2000104@oracle.com> <570ED550.5050509@oracle.com> <570F7B05.6070101@oracle.com> Message-ID: <570FD480.70903@oracle.com> without sounding like a broken record(!), can I ask that new exceptions provide better information (where possible) ? com/sun/crypto/provider/DHKeyPairGenerator.java > + throw new InvalidParameterException( > + "Keysize must be multiple of 64, and can only range " + > + "from 512 to 8192 (inclusive)"); This is a new checkKeySize method - we should print what keysize was attempted in the exception message! Granted - the code was borrowed from old code but hopefully you can improve while here. likewise in com/sun/crypto/provider/DHParameterGenerator.java (print the keysize in InvalidParameterException) Can we improve this exception message while here also ? > + if ((exponentSize <= 0) || (exponentSize >= primeSize)) { > + throw new InvalidAlgorithmParameterException( > + "Exponent size must be positive and less than modulus size"); > + } catch (Exception ex) { > + throw new ProviderException("Unexpected exception: " + ex); Could we use the two arg constructor for ProviderException above and pass ex as Throwable ? === sun/security/provider/DSAParameterGenerator.java > + ("Prime size should be 512 - 1024, or 2048, 3072"); again, could we print the strength variable in above exception ? === sun/security/ssl/ServerHandshaker.java > throw new IllegalArgumentException( > - "Customized DH key size should be positive integer " + > - "between 1024 and 2048 bits, inclusive"); > + "Customized DH key size should not be less " + > + "than 1024 bits"); Can we print customizedDHKeySize value ? === sun/security/pkcs11/P11KeyPairGenerator.java Let's get the keySize printed in all InvalidAlgorithmParameterException calls that you're editing. Thanks, Sean. On 14/04/2016 12:12, Xuelei Fan wrote: > Thanks for the comments. Here is the new webrev: > http://cr.openjdk.java.net/~xuelei/8072452/webrev.03/ > > On 4/14/2016 7:25 AM, Valerie Peng wrote: >> Here are some comments for the test changes: >> >> >> - Not testing key size 768? >> - line 82, would be useful to indicate version here, e.g. NSS (as of >> version xxx) has a hard coded ... >> - line 27, 4096 should be 8192? >> > Updated. > >> >> - format changes only? No test for (3072, 256)? >> > I removed the update of this file. > >> >> - line 50, dhp8192(8191) looks like a typo? >> - line 66, do we really need to generate the key pair here? >> - line 71, seem redundant and potentially confusing as it's aligned >> differently comparing to line70? >> > Updated. > >> >> - line 63, why test for KeyAgreement here instead of KeyPairGenerator? >> > Better to use KeyPairGenerator. Updated. > >> >> - line 53, dhp8192(8191) looks like a typo? >> - line 64, why test for KeyAgreement here instead of KeyPairGenerator? >> - line 75, do we really need to generate the key pair here? >> - line 80, seem redundant and potentially confusing as it's aligned >> differently comparing to line79? >> > Updated. > >> >> - Use "Param" instead of "Para" in the test name "SupportedDSAParaGen"? > Hm, nice name. > >> - Just curious, have u tried the specified timeout value across >> different platforms? > Not really, I only tested on JPRT and the solaris-sparc desktop. This > test may be intermittent timeout failure in some circumstances. I added > the intermittent key tag. > >> - The file is new but the copyright year starts from 2012? >> > Updated. > >> As for the updated sources, all changes look fine. But while I was >> looking at >> src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java, I >> have some more questions: >> - line 145, do we need to check for upper limit here? It used to have >> 2048, should it be 8192 now? If yes, then line 1526 need to be enhanced >> too. > I was wondering to remove the limit in case third party's implementation > support more size. Not necessary. Updated and limited to 8192 bits. > >> - line 1551, now that more DH sizes are supported, shouldn't we make >> some changes here? Now it's either 1024 or 2048. The older impl on line >> 1550 uses 1024 as the lower limit and 2048 as the upper limit and will >> keep the value as is if it's in-between the limits. If there is a reason >> to keep 2048 as the upper limit, it'd be useful to add some comment here >> for clarification. >> > This is mainly for compatibility and interoperability impact. Some old > deployed application may not support DH key size bigger than 2048. I > added back the comments. > > Thanks, > Xuelei > >> Thanks, >> Valerie >> >> On 4/13/2016 7:23 AM, Xuelei Fan wrote: >>> Hi Valerie, >>> >>> All comments are good to me and accepted in the new webrev: >>> >>> http://cr.openjdk.java.net/~xuelei/8072452/webrev.02/ >>> >>> On 4/13/2016 8:26 AM, Valerie Peng wrote: >>>> Hi Xuelei, >>>> >>>> Mostly look good, just some comments in line... >>>> >>>> >>>> >>>> >>>> line 95-100, so essentially, we will use the built-in parameters as much >>>> as possible and if none available, we will try to generate the >>>> parameters for key sizes<= 1024, right? The current comment is a little >>>> hard to parse. Maybe we can just explain it as below? >>>> // Use the built-in parameters (ranging from 512 to 8192) when >>>> available >>>> this.params = ParameterCache.getCachedDHParameterSpec(keysize); >>>> // Due to performance issue, only support DH parameters generation >>>> // up to 1024 bits >>>> if ((this.params == null)&& (keysize> 1024)) { >>>> >>> Updated. >>> >>>> >>>> >>>> >>>> - line 212, redundant? >>> Yes. Updated. >>> >>>> >>>> >>>> >>>> - line 277-303, the "params"argument for this particular method is >>>> always null for non-RSA algorithms based on the usage. It is commented >>>> on line 232 and several other places as indicated by the "// XXX sanity >>>> check params" comments. So, more code changes will be needed here. >>>> Either you can add another boolean hasParams and rely on that argument, >>>> or change the specified argument type from RSAKeyGenParameterSpec to a >>>> generic one and then cast it later when it is needed. >>>> >>> Good catch! Updated per the latter proposal. >>> >>>> >>>> - line 141 - 146 and line 1548 - 1554 are identical. Seems to me that >>>> they can be customized a little as they are for different variable >>>> assignment. The "customizedDHKeySize" variable on line 147 is from user, >>>> right? Maybe what you really mean is something like the following? >>>> // DH parameter generation can be extremely slow, best to use >>>> one of >>>> the >>>> // supported pre-computed DH parameters (see DHCrypt class) >>>> As for line 1548 - 1554, it can be as simple as: >>>> // DH parameter generation can be extremely slow, make sure to use >>>> one of the >>>> // supported pre-computed DH parameters (see DHCrypt class) >>> Updated. >>> >>>> - line 148, can customizedDHKeySize be 1024? The old code accepts it but >>>> the new code will error out. Is there a reason for rejecting 1024? The >>>> check only rejects "<1024" but yet the exception message says the value >>>> should be larger than 1024. >>>> Lastly, "should larger" => "should be larger" (line 150). >>>> >>> 1024 bits should not be rejected. Updated the exception message. >>> >>> Thanks for the comments! >>> >>> Xuelei >>> >>>> I will look at the tests next and send u comments separately. >>>> Thanks, >>>> Valerie >>>> On 4/1/2016 8:53 AM, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> Please review this improvement update to support DHE sizes up to >>>>> 8192-bits and DSA sizes up to 3072-bits: >>>>> >>>>> http://cr.openjdk.java.net/~xuelei/8072452/webrev.00 >>>>> >>>>> This updated extends to support 3072-bits DH and DSA parameters >>>>> generation, and pre-computed DH parameters up to 8192 bits and >>>>> pre-computed DSA parameters up to 3072-bits. >>>>> >>>>> Thanks, >>>>> Xuelei From rajan.halade at oracle.com Thu Apr 14 19:44:08 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Thu, 14 Apr 2016 12:44:08 -0700 Subject: RFR: [9]: 8151834: Test SmallPrimeExponentP.java times out intermittently Message-ID: <570FF308.30300@oracle.com> Hi Max, Please review this patch to fix SmallPrimeExponentP test. It now uses fixed seed value to generate keypair. I did several rounds of testing on different machines to make sure that primes 63/65 are generated in fixed number of iterations. Other updates to test are done to include detailed summary and to log debug information. Bug: https://bugs.openjdk.java.net/browse/JDK-8151834 Webrev: http://cr.openjdk.java.net/~rhalade/8151834/webrev.00/ Thank you for your help with the fix to have constant seed. Thanks, Rajan From weijun.wang at oracle.com Thu Apr 14 19:51:14 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 15 Apr 2016 03:51:14 +0800 Subject: RFR: [9]: 8151834: Test SmallPrimeExponentP.java times out intermittently In-Reply-To: <570FF308.30300@oracle.com> References: <570FF308.30300@oracle.com> Message-ID: Looks good. Btw, since there is already the @requires tag, I think lines 52-56 are no longer needed. Thanks Max > ? 2016?4?15??03:44?Rajan Halade ??? > > Hi Max, > > Please review this patch to fix SmallPrimeExponentP test. It now uses fixed seed value to generate keypair. I did several rounds of testing on different machines to make sure that primes 63/65 are generated in fixed number of iterations. Other updates to test are done to include detailed summary and to log debug information. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151834 > Webrev: http://cr.openjdk.java.net/~rhalade/8151834/webrev.00/ > > Thank you for your help with the fix to have constant seed. > > Thanks, > Rajan From rajan.halade at oracle.com Thu Apr 14 19:59:41 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Thu, 14 Apr 2016 12:59:41 -0700 Subject: RFR: [9]: 8151834: Test SmallPrimeExponentP.java times out intermittently In-Reply-To: References: <570FF308.30300@oracle.com> Message-ID: <570FF6AD.7010406@oracle.com> Thanks for the comment, I have removed extra check. http://cr.openjdk.java.net/~rhalade/8151834/webrev.01/ Thanks, Rajan On 4/14/16 12:51 PM, Wang Weijun wrote: > Looks good. > > Btw, since there is already the @requires tag, I think lines 52-56 are no longer needed. > > Thanks > Max > >> ? 2016?4?15??03:44?Rajan Halade ??? >> >> Hi Max, >> >> Please review this patch to fix SmallPrimeExponentP test. It now uses fixed seed value to generate keypair. I did several rounds of testing on different machines to make sure that primes 63/65 are generated in fixed number of iterations. Other updates to test are done to include detailed summary and to log debug information. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8151834 >> Webrev: http://cr.openjdk.java.net/~rhalade/8151834/webrev.00/ >> >> Thank you for your help with the fix to have constant seed. >> >> Thanks, >> Rajan From valerie.peng at oracle.com Thu Apr 14 22:45:41 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 14 Apr 2016 15:45:41 -0700 Subject: Code Review Request 8072452 Support DHE sizes up to 8192-bits In-Reply-To: <570F7B05.6070101@oracle.com> References: <56FE9961.8090806@Oracle.COM> <570D9218.2050200@oracle.com> <570E565E.2000104@oracle.com> <570ED550.5050509@oracle.com> <570F7B05.6070101@oracle.com> Message-ID: <57101D95.6010705@oracle.com> I have no more comments. Thanks, Valerie On 4/14/2016 4:12 AM, Xuelei Fan wrote: > Thanks for the comments. Here is the new webrev: > http://cr.openjdk.java.net/~xuelei/8072452/webrev.03/ > > On 4/14/2016 7:25 AM, Valerie Peng wrote: >> Here are some comments for the test changes: >> >> >> - Not testing key size 768? >> - line 82, would be useful to indicate version here, e.g. NSS (as of >> version xxx) has a hard coded ... >> - line 27, 4096 should be 8192? >> > Updated. > >> >> - format changes only? No test for (3072, 256)? >> > I removed the update of this file. > >> >> - line 50, dhp8192(8191) looks like a typo? >> - line 66, do we really need to generate the key pair here? >> - line 71, seem redundant and potentially confusing as it's aligned >> differently comparing to line70? >> > Updated. > >> >> - line 63, why test for KeyAgreement here instead of KeyPairGenerator? >> > Better to use KeyPairGenerator. Updated. > >> >> - line 53, dhp8192(8191) looks like a typo? >> - line 64, why test for KeyAgreement here instead of KeyPairGenerator? >> - line 75, do we really need to generate the key pair here? >> - line 80, seem redundant and potentially confusing as it's aligned >> differently comparing to line79? >> > Updated. > >> >> - Use "Param" instead of "Para" in the test name "SupportedDSAParaGen"? > Hm, nice name. > >> - Just curious, have u tried the specified timeout value across >> different platforms? > Not really, I only tested on JPRT and the solaris-sparc desktop. This > test may be intermittent timeout failure in some circumstances. I added > the intermittent key tag. > >> - The file is new but the copyright year starts from 2012? >> > Updated. > >> As for the updated sources, all changes look fine. But while I was >> looking at >> src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java, I >> have some more questions: >> - line 145, do we need to check for upper limit here? It used to have >> 2048, should it be 8192 now? If yes, then line 1526 need to be enhanced >> too. > I was wondering to remove the limit in case third party's implementation > support more size. Not necessary. Updated and limited to 8192 bits. > >> - line 1551, now that more DH sizes are supported, shouldn't we make >> some changes here? Now it's either 1024 or 2048. The older impl on line >> 1550 uses 1024 as the lower limit and 2048 as the upper limit and will >> keep the value as is if it's in-between the limits. If there is a reason >> to keep 2048 as the upper limit, it'd be useful to add some comment here >> for clarification. >> > This is mainly for compatibility and interoperability impact. Some old > deployed application may not support DH key size bigger than 2048. I > added back the comments. > > Thanks, > Xuelei > >> Thanks, >> Valerie >> >> On 4/13/2016 7:23 AM, Xuelei Fan wrote: >>> Hi Valerie, >>> >>> All comments are good to me and accepted in the new webrev: >>> >>> http://cr.openjdk.java.net/~xuelei/8072452/webrev.02/ >>> >>> On 4/13/2016 8:26 AM, Valerie Peng wrote: >>>> Hi Xuelei, >>>> >>>> Mostly look good, just some comments in line... >>>> >>>> >>>> >>>> >>>> line 95-100, so essentially, we will use the built-in parameters as much >>>> as possible and if none available, we will try to generate the >>>> parameters for key sizes<= 1024, right? The current comment is a little >>>> hard to parse. Maybe we can just explain it as below? >>>> // Use the built-in parameters (ranging from 512 to 8192) when >>>> available >>>> this.params = ParameterCache.getCachedDHParameterSpec(keysize); >>>> // Due to performance issue, only support DH parameters generation >>>> // up to 1024 bits >>>> if ((this.params == null)&& (keysize> 1024)) { >>>> >>> Updated. >>> >>>> >>>> >>>> >>>> - line 212, redundant? >>> Yes. Updated. >>> >>>> >>>> >>>> >>>> - line 277-303, the "params"argument for this particular method is >>>> always null for non-RSA algorithms based on the usage. It is commented >>>> on line 232 and several other places as indicated by the "// XXX sanity >>>> check params" comments. So, more code changes will be needed here. >>>> Either you can add another boolean hasParams and rely on that argument, >>>> or change the specified argument type from RSAKeyGenParameterSpec to a >>>> generic one and then cast it later when it is needed. >>>> >>> Good catch! Updated per the latter proposal. >>> >>>> >>>> - line 141 - 146 and line 1548 - 1554 are identical. Seems to me that >>>> they can be customized a little as they are for different variable >>>> assignment. The "customizedDHKeySize" variable on line 147 is from user, >>>> right? Maybe what you really mean is something like the following? >>>> // DH parameter generation can be extremely slow, best to use >>>> one of >>>> the >>>> // supported pre-computed DH parameters (see DHCrypt class) >>>> As for line 1548 - 1554, it can be as simple as: >>>> // DH parameter generation can be extremely slow, make sure to use >>>> one of the >>>> // supported pre-computed DH parameters (see DHCrypt class) >>> Updated. >>> >>>> - line 148, can customizedDHKeySize be 1024? The old code accepts it but >>>> the new code will error out. Is there a reason for rejecting 1024? The >>>> check only rejects "<1024" but yet the exception message says the value >>>> should be larger than 1024. >>>> Lastly, "should larger" => "should be larger" (line 150). >>>> >>> 1024 bits should not be rejected. Updated the exception message. >>> >>> Thanks for the comments! >>> >>> Xuelei >>> >>>> I will look at the tests next and send u comments separately. >>>> Thanks, >>>> Valerie >>>> On 4/1/2016 8:53 AM, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> Please review this improvement update to support DHE sizes up to >>>>> 8192-bits and DSA sizes up to 3072-bits: >>>>> >>>>> http://cr.openjdk.java.net/~xuelei/8072452/webrev.00 >>>>> >>>>> This updated extends to support 3072-bits DH and DSA parameters >>>>> generation, and pre-computed DH parameters up to 8192 bits and >>>>> pre-computed DSA parameters up to 3072-bits. >>>>> >>>>> Thanks, >>>>> Xuelei From rajan.halade at oracle.com Fri Apr 15 00:04:03 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Thu, 14 Apr 2016 17:04:03 -0700 Subject: RFR: [9]: 8137231: sun/security/rsa/SpecTest.java timeout with Agent error: java.lang.Exception Message-ID: <57102FF3.4060808@oracle.com> Please provide your review of following patch to SpecTest.java test. This test purpose shouldn't require generating extra key pair with different public exponent value. Bug: https://bugs.openjdk.java.net/browse/JDK-8137231 Webrev: http://cr.openjdk.java.net/~rhalade/8137231/webrev.00/ Thanks, Rajan From xuelei.fan at oracle.com Fri Apr 15 01:41:28 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 15 Apr 2016 09:41:28 +0800 Subject: Code Review Request 8072452 Support DHE sizes up to 8192-bits In-Reply-To: <570FD480.70903@oracle.com> References: <56FE9961.8090806@Oracle.COM> <570D9218.2050200@oracle.com> <570E565E.2000104@oracle.com> <570ED550.5050509@oracle.com> <570F7B05.6070101@oracle.com> <570FD480.70903@oracle.com> Message-ID: <571046C8.2000102@oracle.com> Good points! I made the update accordingly. http://cr.openjdk.java.net/~xuelei/8072452/webrev.04/ Thanks, Xuelei On 4/15/2016 1:33 AM, Se?n Coffey wrote: > without sounding like a broken record(!), can I ask that new exceptions > provide better information (where possible) ? > > com/sun/crypto/provider/DHKeyPairGenerator.java > >> + throw new InvalidParameterException( >> + "Keysize must be multiple of 64, and can only >> range " + >> + "from 512 to 8192 (inclusive)"); > This is a new checkKeySize method - we should print what keysize was > attempted in the exception message! Granted - the code was borrowed from > old code but hopefully you can improve while here. > > likewise in com/sun/crypto/provider/DHParameterGenerator.java (print the > keysize in InvalidParameterException) > > Can we improve this exception message while here also ? >> + if ((exponentSize <= 0) || (exponentSize >= primeSize)) { >> + throw new InvalidAlgorithmParameterException( >> + "Exponent size must be positive and less than modulus >> size"); > >> + } catch (Exception ex) { >> + throw new ProviderException("Unexpected exception: " + ex); > > Could we use the two arg constructor for ProviderException above and > pass ex as Throwable ? > > === > > sun/security/provider/DSAParameterGenerator.java >> + ("Prime size should be 512 - 1024, or 2048, 3072"); > > again, could we print the strength variable in above exception ? > > === > > sun/security/ssl/ServerHandshaker.java > >> throw new IllegalArgumentException( >> - "Customized DH key size should be positive >> integer " + >> - "between 1024 and 2048 bits, inclusive"); >> + "Customized DH key size should not be less " + >> + "than 1024 bits"); > > Can we print customizedDHKeySize value ? > > === > > sun/security/pkcs11/P11KeyPairGenerator.java > > Let's get the keySize printed in all InvalidAlgorithmParameterException > calls that you're editing. > > Thanks, > Sean. > > On 14/04/2016 12:12, Xuelei Fan wrote: >> Thanks for the comments. Here is the new webrev: >> http://cr.openjdk.java.net/~xuelei/8072452/webrev.03/ >> >> On 4/14/2016 7:25 AM, Valerie Peng wrote: >>> Here are some comments for the test changes: >>> >>> >>> - Not testing key size 768? >>> - line 82, would be useful to indicate version here, e.g. NSS (as of >>> version xxx) has a hard coded ... >>> - line 27, 4096 should be 8192? >>> >> Updated. >> >>> >>> - format changes only? No test for (3072, 256)? >>> >> I removed the update of this file. >> >>> >>> - line 50, dhp8192(8191) looks like a typo? >>> - line 66, do we really need to generate the key pair here? >>> - line 71, seem redundant and potentially confusing as it's aligned >>> differently comparing to line70? >>> >> Updated. >> >>> >>> - line 63, why test for KeyAgreement here instead of KeyPairGenerator? >>> >> Better to use KeyPairGenerator. Updated. >> >>> >>> - line 53, dhp8192(8191) looks like a typo? >>> - line 64, why test for KeyAgreement here instead of KeyPairGenerator? >>> - line 75, do we really need to generate the key pair here? >>> - line 80, seem redundant and potentially confusing as it's aligned >>> differently comparing to line79? >>> >> Updated. >> >>> >>> - Use "Param" instead of "Para" in the test name "SupportedDSAParaGen"? >> Hm, nice name. >> >>> - Just curious, have u tried the specified timeout value across >>> different platforms? >> Not really, I only tested on JPRT and the solaris-sparc desktop. This >> test may be intermittent timeout failure in some circumstances. I added >> the intermittent key tag. >> >>> - The file is new but the copyright year starts from 2012? >>> >> Updated. >> >>> As for the updated sources, all changes look fine. But while I was >>> looking at >>> src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java, I >>> have some more questions: >>> - line 145, do we need to check for upper limit here? It used to have >>> 2048, should it be 8192 now? If yes, then line 1526 need to be enhanced >>> too. >> I was wondering to remove the limit in case third party's implementation >> support more size. Not necessary. Updated and limited to 8192 bits. >> >>> - line 1551, now that more DH sizes are supported, shouldn't we make >>> some changes here? Now it's either 1024 or 2048. The older impl on line >>> 1550 uses 1024 as the lower limit and 2048 as the upper limit and will >>> keep the value as is if it's in-between the limits. If there is a reason >>> to keep 2048 as the upper limit, it'd be useful to add some comment here >>> for clarification. >>> >> This is mainly for compatibility and interoperability impact. Some old >> deployed application may not support DH key size bigger than 2048. I >> added back the comments. >> >> Thanks, >> Xuelei >> >>> Thanks, >>> Valerie >>> >>> On 4/13/2016 7:23 AM, Xuelei Fan wrote: >>>> Hi Valerie, >>>> >>>> All comments are good to me and accepted in the new webrev: >>>> >>>> http://cr.openjdk.java.net/~xuelei/8072452/webrev.02/ >>>> >>>> On 4/13/2016 8:26 AM, Valerie Peng wrote: >>>>> Hi Xuelei, >>>>> >>>>> Mostly look good, just some comments in line... >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> line 95-100, so essentially, we will use the built-in parameters as >>>>> much >>>>> as possible and if none available, we will try to generate the >>>>> parameters for key sizes<= 1024, right? The current comment is a >>>>> little >>>>> hard to parse. Maybe we can just explain it as below? >>>>> // Use the built-in parameters (ranging from 512 to 8192) when >>>>> available >>>>> this.params = ParameterCache.getCachedDHParameterSpec(keysize); >>>>> // Due to performance issue, only support DH parameters >>>>> generation >>>>> // up to 1024 bits >>>>> if ((this.params == null)&& (keysize> 1024)) { >>>>> >>>> Updated. >>>> >>>>> >>>>> >>>>> >>>>> >>>>> - line 212, redundant? >>>> Yes. Updated. >>>> >>>>> >>>>> >>>>> >>>>> >>>>> - line 277-303, the "params"argument for this particular method is >>>>> always null for non-RSA algorithms based on the usage. It is commented >>>>> on line 232 and several other places as indicated by the "// XXX >>>>> sanity >>>>> check params" comments. So, more code changes will be needed here. >>>>> Either you can add another boolean hasParams and rely on that >>>>> argument, >>>>> or change the specified argument type from RSAKeyGenParameterSpec to a >>>>> generic one and then cast it later when it is needed. >>>>> >>>> Good catch! Updated per the latter proposal. >>>> >>>>> >>>>> - line 141 - 146 and line 1548 - 1554 are identical. Seems to me that >>>>> they can be customized a little as they are for different variable >>>>> assignment. The "customizedDHKeySize" variable on line 147 is from >>>>> user, >>>>> right? Maybe what you really mean is something like the following? >>>>> // DH parameter generation can be extremely slow, best to use >>>>> one of >>>>> the >>>>> // supported pre-computed DH parameters (see DHCrypt class) >>>>> As for line 1548 - 1554, it can be as simple as: >>>>> // DH parameter generation can be extremely slow, make sure >>>>> to use >>>>> one of the >>>>> // supported pre-computed DH parameters (see DHCrypt class) >>>> Updated. >>>> >>>>> - line 148, can customizedDHKeySize be 1024? The old code accepts >>>>> it but >>>>> the new code will error out. Is there a reason for rejecting 1024? The >>>>> check only rejects "<1024" but yet the exception message says the >>>>> value >>>>> should be larger than 1024. >>>>> Lastly, "should larger" => "should be larger" (line 150). >>>>> >>>> 1024 bits should not be rejected. Updated the exception message. >>>> >>>> Thanks for the comments! >>>> >>>> Xuelei >>>> >>>>> I will look at the tests next and send u comments separately. >>>>> Thanks, >>>>> Valerie >>>>> On 4/1/2016 8:53 AM, Xuelei Fan wrote: >>>>>> Hi, >>>>>> >>>>>> Please review this improvement update to support DHE sizes up to >>>>>> 8192-bits and DSA sizes up to 3072-bits: >>>>>> >>>>>> http://cr.openjdk.java.net/~xuelei/8072452/webrev.00 >>>>>> >>>>>> This updated extends to support 3072-bits DH and DSA parameters >>>>>> generation, and pre-computed DH parameters up to 8192 bits and >>>>>> pre-computed DSA parameters up to 3072-bits. >>>>>> >>>>>> Thanks, >>>>>> Xuelei > From sean.coffey at oracle.com Fri Apr 15 07:19:40 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 15 Apr 2016 08:19:40 +0100 Subject: Code Review Request 8072452 Support DHE sizes up to 8192-bits In-Reply-To: <571046C8.2000102@oracle.com> References: <56FE9961.8090806@Oracle.COM> <570D9218.2050200@oracle.com> <570E565E.2000104@oracle.com> <570ED550.5050509@oracle.com> <570F7B05.6070101@oracle.com> <570FD480.70903@oracle.com> <571046C8.2000102@oracle.com> Message-ID: <5710960C.2090700@oracle.com> Looks good! Thanks, Sean. On 15/04/2016 02:41, Xuelei Fan wrote: > Good points! I made the update accordingly. > > http://cr.openjdk.java.net/~xuelei/8072452/webrev.04/ > > Thanks, > Xuelei > > On 4/15/2016 1:33 AM, Se?n Coffey wrote: >> without sounding like a broken record(!), can I ask that new exceptions >> provide better information (where possible) ? >> >> com/sun/crypto/provider/DHKeyPairGenerator.java >> >>> + throw new InvalidParameterException( >>> + "Keysize must be multiple of 64, and can only >>> range " + >>> + "from 512 to 8192 (inclusive)"); >> This is a new checkKeySize method - we should print what keysize was >> attempted in the exception message! Granted - the code was borrowed from >> old code but hopefully you can improve while here. >> >> likewise in com/sun/crypto/provider/DHParameterGenerator.java (print the >> keysize in InvalidParameterException) >> >> Can we improve this exception message while here also ? >>> + if ((exponentSize <= 0) || (exponentSize >= primeSize)) { >>> + throw new InvalidAlgorithmParameterException( >>> + "Exponent size must be positive and less than modulus >>> size"); >>> + } catch (Exception ex) { >>> + throw new ProviderException("Unexpected exception: " + ex); >> Could we use the two arg constructor for ProviderException above and >> pass ex as Throwable ? >> >> === >> >> sun/security/provider/DSAParameterGenerator.java >>> + ("Prime size should be 512 - 1024, or 2048, 3072"); >> again, could we print the strength variable in above exception ? >> >> === >> >> sun/security/ssl/ServerHandshaker.java >> >>> throw new IllegalArgumentException( >>> - "Customized DH key size should be positive >>> integer " + >>> - "between 1024 and 2048 bits, inclusive"); >>> + "Customized DH key size should not be less " + >>> + "than 1024 bits"); >> Can we print customizedDHKeySize value ? >> >> === >> >> sun/security/pkcs11/P11KeyPairGenerator.java >> >> Let's get the keySize printed in all InvalidAlgorithmParameterException >> calls that you're editing. >> >> Thanks, >> Sean. >> >> On 14/04/2016 12:12, Xuelei Fan wrote: >>> Thanks for the comments. Here is the new webrev: >>> http://cr.openjdk.java.net/~xuelei/8072452/webrev.03/ >>> >>> On 4/14/2016 7:25 AM, Valerie Peng wrote: >>>> Here are some comments for the test changes: >>>> >>>> >>>> - Not testing key size 768? >>>> - line 82, would be useful to indicate version here, e.g. NSS (as of >>>> version xxx) has a hard coded ... >>>> - line 27, 4096 should be 8192? >>>> >>> Updated. >>> >>>> >>>> - format changes only? No test for (3072, 256)? >>>> >>> I removed the update of this file. >>> >>>> >>>> - line 50, dhp8192(8191) looks like a typo? >>>> - line 66, do we really need to generate the key pair here? >>>> - line 71, seem redundant and potentially confusing as it's aligned >>>> differently comparing to line70? >>>> >>> Updated. >>> >>>> >>>> - line 63, why test for KeyAgreement here instead of KeyPairGenerator? >>>> >>> Better to use KeyPairGenerator. Updated. >>> >>>> >>>> - line 53, dhp8192(8191) looks like a typo? >>>> - line 64, why test for KeyAgreement here instead of KeyPairGenerator? >>>> - line 75, do we really need to generate the key pair here? >>>> - line 80, seem redundant and potentially confusing as it's aligned >>>> differently comparing to line79? >>>> >>> Updated. >>> >>>> >>>> - Use "Param" instead of "Para" in the test name "SupportedDSAParaGen"? >>> Hm, nice name. >>> >>>> - Just curious, have u tried the specified timeout value across >>>> different platforms? >>> Not really, I only tested on JPRT and the solaris-sparc desktop. This >>> test may be intermittent timeout failure in some circumstances. I added >>> the intermittent key tag. >>> >>>> - The file is new but the copyright year starts from 2012? >>>> >>> Updated. >>> >>>> As for the updated sources, all changes look fine. But while I was >>>> looking at >>>> src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java, I >>>> have some more questions: >>>> - line 145, do we need to check for upper limit here? It used to have >>>> 2048, should it be 8192 now? If yes, then line 1526 need to be enhanced >>>> too. >>> I was wondering to remove the limit in case third party's implementation >>> support more size. Not necessary. Updated and limited to 8192 bits. >>> >>>> - line 1551, now that more DH sizes are supported, shouldn't we make >>>> some changes here? Now it's either 1024 or 2048. The older impl on line >>>> 1550 uses 1024 as the lower limit and 2048 as the upper limit and will >>>> keep the value as is if it's in-between the limits. If there is a reason >>>> to keep 2048 as the upper limit, it'd be useful to add some comment here >>>> for clarification. >>>> >>> This is mainly for compatibility and interoperability impact. Some old >>> deployed application may not support DH key size bigger than 2048. I >>> added back the comments. >>> >>> Thanks, >>> Xuelei >>> >>>> Thanks, >>>> Valerie >>>> >>>> On 4/13/2016 7:23 AM, Xuelei Fan wrote: >>>>> Hi Valerie, >>>>> >>>>> All comments are good to me and accepted in the new webrev: >>>>> >>>>> http://cr.openjdk.java.net/~xuelei/8072452/webrev.02/ >>>>> >>>>> On 4/13/2016 8:26 AM, Valerie Peng wrote: >>>>>> Hi Xuelei, >>>>>> >>>>>> Mostly look good, just some comments in line... >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> line 95-100, so essentially, we will use the built-in parameters as >>>>>> much >>>>>> as possible and if none available, we will try to generate the >>>>>> parameters for key sizes<= 1024, right? The current comment is a >>>>>> little >>>>>> hard to parse. Maybe we can just explain it as below? >>>>>> // Use the built-in parameters (ranging from 512 to 8192) when >>>>>> available >>>>>> this.params = ParameterCache.getCachedDHParameterSpec(keysize); >>>>>> // Due to performance issue, only support DH parameters >>>>>> generation >>>>>> // up to 1024 bits >>>>>> if ((this.params == null)&& (keysize> 1024)) { >>>>>> >>>>> Updated. >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> - line 212, redundant? >>>>> Yes. Updated. >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> - line 277-303, the "params"argument for this particular method is >>>>>> always null for non-RSA algorithms based on the usage. It is commented >>>>>> on line 232 and several other places as indicated by the "// XXX >>>>>> sanity >>>>>> check params" comments. So, more code changes will be needed here. >>>>>> Either you can add another boolean hasParams and rely on that >>>>>> argument, >>>>>> or change the specified argument type from RSAKeyGenParameterSpec to a >>>>>> generic one and then cast it later when it is needed. >>>>>> >>>>> Good catch! Updated per the latter proposal. >>>>> >>>>>> >>>>>> - line 141 - 146 and line 1548 - 1554 are identical. Seems to me that >>>>>> they can be customized a little as they are for different variable >>>>>> assignment. The "customizedDHKeySize" variable on line 147 is from >>>>>> user, >>>>>> right? Maybe what you really mean is something like the following? >>>>>> // DH parameter generation can be extremely slow, best to use >>>>>> one of >>>>>> the >>>>>> // supported pre-computed DH parameters (see DHCrypt class) >>>>>> As for line 1548 - 1554, it can be as simple as: >>>>>> // DH parameter generation can be extremely slow, make sure >>>>>> to use >>>>>> one of the >>>>>> // supported pre-computed DH parameters (see DHCrypt class) >>>>> Updated. >>>>> >>>>>> - line 148, can customizedDHKeySize be 1024? The old code accepts >>>>>> it but >>>>>> the new code will error out. Is there a reason for rejecting 1024? The >>>>>> check only rejects "<1024" but yet the exception message says the >>>>>> value >>>>>> should be larger than 1024. >>>>>> Lastly, "should larger" => "should be larger" (line 150). >>>>>> >>>>> 1024 bits should not be rejected. Updated the exception message. >>>>> >>>>> Thanks for the comments! >>>>> >>>>> Xuelei >>>>> >>>>>> I will look at the tests next and send u comments separately. >>>>>> Thanks, >>>>>> Valerie >>>>>> On 4/1/2016 8:53 AM, Xuelei Fan wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review this improvement update to support DHE sizes up to >>>>>>> 8192-bits and DSA sizes up to 3072-bits: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~xuelei/8072452/webrev.00 >>>>>>> >>>>>>> This updated extends to support 3072-bits DH and DSA parameters >>>>>>> generation, and pre-computed DH parameters up to 8192 bits and >>>>>>> pre-computed DSA parameters up to 3072-bits. >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei From weijun.wang at oracle.com Fri Apr 15 13:35:54 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 15 Apr 2016 21:35:54 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> Message-ID: <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> Hi All Webrev updated again at http://cr.openjdk.java.net/~weijun/8051408/webrev.10/ http://cr.openjdk.java.net/~weijun/8051408/webrev.10/spec http://cr.openjdk.java.net/~weijun/8051408/webrev.10/specdiff Changes since webrev.09: 1. The first line in DrbgParameters: - * This class specifies the parameters used by a DRBG. + * This class specifies the parameters used by a DRBG (Deterministic + * Random Bit Generator). 2. Two new methods for DrbgParameters$Capability: public boolean supportsReseeding(); public boolean supportsPredictionResistance(); So you will be able to write drbg = SecureRandom.getInstance("DRBG"); SecureRandomParameters params = drbg.getParameters(); if (params instanceof DrbgParameters.Instantiate) { DrbgParameters.Instantiate ins = (DrbgParameters.Instantiate) params; if (ins.getCapability().supportsReseeding()) { drbg.reseed(); } } 3. More descriptive text in exception thrown. Thanks Max > On Apr 5, 2016, at 10:34 AM, Wang Weijun wrote: > > Updated webrev again at > > http://cr.openjdk.java.net/~weijun/8051408/webrev.09/ > http://cr.openjdk.java.net/~weijun/8051408/webrev.09/spec > http://cr.openjdk.java.net/~weijun/8051408/webrev.09/specdiff > > The only change is that SecureRandomInstantiateParameters, SecureRandomNextBytesParameters and SecureRandomReseedParameters are removed and only a single SecureRandomParameters is added. There seems no reason to introduce 3 marker interfaces. > > Thanks > Max From jamil.j.nimeh at oracle.com Fri Apr 15 18:06:53 2016 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 15 Apr 2016 11:06:53 -0700 Subject: RFR: Proposed HKDF API (JDK-8145255) Message-ID: <57112DBD.2090508@oracle.com> Hello all, We are looking to add HKDF support as a KeyGenerator into OpenJDK 9. This will be available for general-purpose use. I've documented the proposed API below. RFE: https://bugs.openjdk.java.net/browse/JDK-8145255 Proof-of-concept implementation: http://cr.openjdk.java.net/~jnimeh/reviews/8145255/webrev.1/ A set of new standard algorithm names would be created that define the HMAC algorithm used with HKDF: HkdfSHA224, HkdfSHA256, HkdfSHA384 and HkdfSHA512. We can at a later date include HKDF variants that use other supported HMAC algorithms. Instantiation: -------------- In order to do HKDF derivations, a KeyGenerator of the appropriate type must be obtained. This is done using one of the KeyGenerator.getInstance methods, specifying the underlying HMAC type using one of the names listed above. Initialization: --------------- The resulting HKDF KeyGenerator, in order to be compliant with the KeyGenerator API, may be used to generate a key without any further initialization. In this case, the Extract-then-Expand operation will be performed using null salt and application-specific information, and a random input key. The resulting output key will be sized to the output length of the underlying HMAC. This can be used as a way to obtain a random key. The HKDF KeyGenerator supports all five flavors of the init method. The resulting behavior differs between each flavor however. KeyGenerator.init(SecureRandom): -------------------------------- If this version of the init method is used, the KeyGenerator will behave similarly to the default initialization, with the exception that the caller may provide their own SecureRandom source for the input key. A null value is allowed, in which case the implementation will obtain the default SecureRandom implementation for generating the input key. KeyGenerator.init(int); KeyGenerator.init(int, SecureRandom); ------------------------------------- These two versions of the KeyGenerator allow the caller to provide the resulting key length and, in the second case provide a SecureRandom source. The caller must provide a non-negative length value in bytes. A value of zero is allowed and returns a key of the same length as the underlying HMAC. In both forms the Extract-then-Expand operation will be performed with null salt and application-specific information, and a random input key. If a SecureRandom value is provided, its behavior is similar to KeyGenerator.init(SecureRandom). KeyGenerator.init(AlgorithmParameterSpec); KeyGenerator.init(AlgorithmParameterSpec, SecureRandom); -------------------------------------------------------- These versions of the init method allow the caller to customize the input parameters to the HKDF generator as well as select the HKDF function to perform. Users desiring a specific HKDF function would initialize it using one of three new AlgorithmParameterSpec classes: HkdfExtractParameterSpec, HkdfExpandParameterSpec, or HkdfParameterSpec. These three parameter spec classes are used to initialize the HKDF key generator to perform the HKDF-Expand, HKDF-Extract or a combination HKDF-Extract-then-Expand operation, respectively. The init(AlgorithmParameterSpec, SecureRandom) ignores the SecureRandom parameter, and requires that input key material (IKM) or a pseudorandom key (PRK) is provided. Key Generation: --------------- Once initialized (default or via one of the init methods) a key is generated by calling KeyGenerator.generateKey(). The Specification: ------------------ Three new AlgorithmParameterSpec classes will be created to initialize HKDF KeyGenerator objects: HkdfParameterSpec: For performing the Extract-then-Expand operation HkdfExtractParameterSpec: For performingthe HKDF-Extract operation HkdfExpandParameterSpec: For performing the HKDF-Expand operation /** * Parameters for the Extract operation of the HMAC-based Extract-and-Expand * Key Derivation Function (HKDF). The HKDF function is defined in * RFC 5869. * This class is used to initialize KeyGenerators in the HKDF family of * generators, specifically for the HKDF Extract function. *

* Here is an example of how an HkdfExtractParameterSpec would be used to * initialize an HKDF KeyGenerator: *

  *     byte[] salt;
  *     SecretKey inputKey;
  *     SecretKey resultingPRK;
  *
  *     // salt and inputKey values populated with data
  *     ...
  *
  *     // Get an instance of the HKDF KeyGenerator
  *     hkdfGen = KeyGenerator.getInstance("HkdfSHA256");
  *
  *     // Create the spec object and use it to initialize the generator.
  *     hkdfGen.init(new HkdfExtractParameterSpec(salt, inputKey));
  *
  *     // Generate the PRK
  *     resultingPRK = hkdfGen.generateKey();
  * 
* * @since 9 */ public final class HkdfExtractParameterSpec implements AlgorithmParameterSpec { /** * Constructs a new HkdfExtractParameterSpec with the given salt value * and key material * * @param salt the salt value, or {@code null} if not specified. The * contents of the array are copied to protect against subsequent * modification. * @param inputKey the Input Keying Material (IKM). * * @throws NullPointerException if {@code inputKey} is {@code null}. */ public HkdfExtractParameterSpec(byte[] salt, SecretKey inputKey); /** * Returns the Input Keying Material (IKM). * * @return the Input Keying Material. */ public SecretKey getIKM(); /** * Returns the salt value. * * @return a copy of the salt value or {@code null} if no salt was provided. */ public byte[] getSalt(); } HkdfExpandParameterSpec: ------------------------ /** * Parameters for the Expand operation of the HMAC-based Extract-and-Expand * Key Derivation Function (HKDF). The HKDF function is defined in * RFC 5869. *

* Here is an example of how an HkdfExpandParameterSpec would be used to * initialize an HKDF KeyGenerator: *

  *     byte[] info;
  *     SecretKey pseudoRandomKey;
  *     SecretKey resultingKey;
  *
  *     // pseudoRandomKey and context info values populated with data
  *     ...
  *
  *     // Get an instance of the HKDF KeyGenerator
  *     hkdfGen = KeyGenerator.getInstance("HkdfSHA256");
  *
  *     // Create the spec object and use it to initialize the generator.
  *     // Ask for a 64-byte key to be output.
  *     hkdfGen.init(new HkdfExpandParameterSpec(pseudoRandomKey, info, 
64));
  *
  *     // Generate the key
  *     resultingKey = hkdfGen.generateKey();
  * 
* * @since 9 */ public final class HkdfExpandParameterSpec implements AlgorithmParameterSpec { /** * Constructs a new HkdfExpandParameterSpec. * * @param prk the pseudorandom key used for HKDF-Expand. * @param info optional context and application specific information or * {@code null} if no info data is provided. The contents of the * array are copied to protect against subsequent modification. * @param outLen the length in bytes of the output data * * @throws NullPointerException if {@code prk} is {@code null}. * @throws IllegalArgumentException if {@code outLen} is a * non-positive value. */ public HkdfExpandParameterSpec(SecretKey prk, byte[] info, int outLen); /** * Returns a {@link SecretKey} object containing the pseudorandom key (PRK). * * @return a {@link SecretKey} object containing the pseudorandom key. */ public SecretKey getPRK(); /** * Returns a copy of the context and application specific information. * * @return a copy of the context and application specific information. * This may be {@code null} or empty if no specific information was * provided. */ public byte[] getInfo(); /** * Returns the length in bytes of the output key to be produced. * * @return the length in bytes of the output key to be produced. */ public int getOutputLength(); } HkdfParameterSpec: ------------------ /** * Parameters for the combined Extract-then-Expand operation of the HMAC-based * Extract-and-Expand Key Derivation Function (HKDF). The HKDF function * is defined in RFC 5869. *

* Here is an example of how an HkdfParameterSpec would be used to initialize * an HKDF KeyGenerator: *

  *     byte[] salt;
  *     byte[] info;
  *     SecretKey inputKey;
  *     SecretKey resultingKey;
  *
  *     // salt, info and inputKey values populated with data
  *     ...
  *
  *     // Get an instance of the HKDF KeyGenerator
  *     hkdfGen = KeyGenerator.getInstance("HkdfSHA256");
  *
  *     // Create the spec object and use it to initialize the generator.
  *     // Ask for a 64-byte key to be output.
  *     hkdfGen.init(new HkdfParameterSpec(inputKey, salt, info, 64));
  *
  *     // Generate the key
  *     resultingKey = hkdfGen.generateKey();
  * 
* * @since 9 */ public final class HkdfParameterSpec implements AlgorithmParameterSpec { /** * Constructs a new HkdfParameterSpec. * * @param inputKey the input keying material used for the * HKDF-Extract-then-Expand operation. * @param salt the salt value, or {@code null} if not specified. The * contents of the array are copied to protect against subsequent * modification. * @param info optional context and application specific information or * {@code null} if no info data is provided. The contents of the * array are copied to protect against subsequent modification. * @param outLen the length in bytes of the output data * * @throws NullPointerException if {@code inputKey} is {@code null}. * @throws IllegalArgumentException if {@code outLen} is a * non-positive value. */ public HkdfParameterSpec(SecretKey inputKey, byte[] salt, byte[] info, int outLen); /** * Returns the Input Keying Material (IKM). * * @return the Input Keying Material. */ public SecretKey getIKM(); /** * Returns the salt value. * * @return a copy of the salt value or {@code null} if no salt was provided. */ public byte[] getSalt(); /** * Returns a copy of the context and application specific information. * * @return a copy of the context and application specific information. * This may be {@code null} or empty if no specific information was * provided. */ public byte[] getInfo(); /** * Returns the length in bytes of the output key to be produced. * * @return the length in bytes of the output key to be produced. */ public int getOutputLength(); } From mstjohns at comcast.net Fri Apr 15 19:54:36 2016 From: mstjohns at comcast.net (Michael StJohns) Date: Fri, 15 Apr 2016 15:54:36 -0400 Subject: RFR: Proposed HKDF API (JDK-8145255) In-Reply-To: <57112DBD.2090508@oracle.com> References: <57112DBD.2090508@oracle.com> Message-ID: <571146FC.9020507@comcast.net> Hi Jamil - I need to look at this a bit more, but I think its probably incorrect. Basically, KDFs should be able to provide multiple keys from a single call, not a single key as you've described here. They may also may need to provide non-key cryptographic material such as IV's. The TLS1.2 KDF (PRF) is an example of this. There's this other problem that you're outputting unwrapped data - which means you can never define this to run as a hardware module as the outputs are byte arrays. So I'd generalize this more as: (This is a single pass design - I haven't gone back and tweaked the obvious mistakes - not enough time right now). Kdf.getInstance(String algName); Kdf.init (AlgorithmParameterSpec kdfSpec); // only one key produced, well defined by the algName, no parameters required. Kdf.init (AlgorithmParameterSpec kdfSpec, KDFAlgorithmParameterSpec keyspec); Kdf.init (AlgorithmParameterSpec kdfSpec, KDFAlgorithmParameterSpec[] keyspecs); Key xxx = Kdf.generateKey(); Key[] xxx = Kdf.generateKeys(); public interface KDFAlgorithmParameterSpec extends AlgorithmParameterSpec { public KDFParameters[] getParams(); } public class SecretKeyAlgorithmSpec implements KDFAlgorithmParameterSpec { public SecretKeyAlgorithmSpec (String algorithm, int size, KDFParameters ... params ); public int getSize(); public String getAlgorithm(); public KDFParameters[] getParams(); } public interface KDFParameters{}; KDFParameters is a marker interface to deal with mixin parameters that are specific to the key material. I'd define HKDF as the instance type for the Kdf.getInstance(). I'd define HKDFAlgorithmParameterSpec and place the info on which PRF function to use in that spec along with any other instance specific stuff. This is also where you put the context and label mixin data. I'd then define the "HKDFExtract" and "HKDFExpand" as two separate KDFs. The first produces a single Key of instance type MasterKey (which is a sub type of SecretKey) which is a well known length based on the provided PRF. The second produces whatever you ask for based on the key spec's you provide. This generalizes well to other KDFs including SP800-108. Mike On 4/15/2016 2:06 PM, Jamil Nimeh wrote: > Hello all, > > We are looking to add HKDF support as a KeyGenerator into OpenJDK 9. > This will be available for general-purpose use. I've documented the > proposed API below. > > RFE: https://bugs.openjdk.java.net/browse/JDK-8145255 > Proof-of-concept implementation: > http://cr.openjdk.java.net/~jnimeh/reviews/8145255/webrev.1/ > > A set of new standard algorithm names would be created that define the > HMAC algorithm used with HKDF: HkdfSHA224, HkdfSHA256, HkdfSHA384 and > HkdfSHA512. We can at a later date include HKDF variants that use > other supported HMAC algorithms. > > Instantiation: > -------------- > In order to do HKDF derivations, a KeyGenerator of the appropriate > type must be obtained. This is done using one of the > KeyGenerator.getInstance methods, specifying the underlying HMAC type > using one of the names listed above. > > Initialization: > --------------- > The resulting HKDF KeyGenerator, in order to be compliant with the > KeyGenerator API, may be used to generate a key without any further > initialization. In this case, the Extract-then-Expand operation will > be performed using null salt and application-specific information, and > a random input key. The resulting output key will be sized to the > output length of the underlying HMAC. This can be used as a way to > obtain a random key. > > The HKDF KeyGenerator supports all five flavors of the init method. > The resulting behavior differs between each flavor however. > > KeyGenerator.init(SecureRandom): > -------------------------------- > If this version of the init method is used, the KeyGenerator will > behave similarly to the default initialization, with the exception > that the caller may provide their own SecureRandom source for the > input key. A null value is allowed, in which case the implementation > will obtain the default SecureRandom implementation for generating the > input key. > > KeyGenerator.init(int); > KeyGenerator.init(int, SecureRandom); > ------------------------------------- > These two versions of the KeyGenerator allow the caller to provide the > resulting key length and, in the second case provide a SecureRandom > source. The caller must provide a non-negative length value in bytes. > A value of zero is allowed and returns a key of the same length as > the underlying HMAC. In both forms the Extract-then-Expand operation > will be performed with null salt and application-specific information, > and a random input key. If a SecureRandom value is provided, its > behavior is similar to KeyGenerator.init(SecureRandom). > > KeyGenerator.init(AlgorithmParameterSpec); > KeyGenerator.init(AlgorithmParameterSpec, SecureRandom); > -------------------------------------------------------- > These versions of the init method allow the caller to customize the > input parameters to the HKDF generator as well as select the HKDF > function to perform. > > Users desiring a specific HKDF function would initialize it using one > of three new AlgorithmParameterSpec classes: HkdfExtractParameterSpec, > HkdfExpandParameterSpec, or HkdfParameterSpec. These three parameter > spec classes are used to initialize the HKDF key generator to perform > the HKDF-Expand, HKDF-Extract or a combination > HKDF-Extract-then-Expand operation, respectively. > > The init(AlgorithmParameterSpec, SecureRandom) ignores the > SecureRandom parameter, and requires that input key material (IKM) or > a pseudorandom key (PRK) is provided. > > Key Generation: > --------------- > Once initialized (default or via one of the init methods) a key is > generated by calling KeyGenerator.generateKey(). > > > The Specification: > ------------------ > Three new AlgorithmParameterSpec classes will be created to initialize > HKDF KeyGenerator objects: > HkdfParameterSpec: For performing the Extract-then-Expand operation > HkdfExtractParameterSpec: For performingthe HKDF-Extract operation > HkdfExpandParameterSpec: For performing the HKDF-Expand operation > > > /** > * Parameters for the Extract operation of the HMAC-based > Extract-and-Expand > * Key Derivation Function (HKDF). The HKDF function is defined in > * RFC 5869. > * This class is used to initialize KeyGenerators in the HKDF family of > * generators, specifically for the HKDF Extract function. > *

> * Here is an example of how an HkdfExtractParameterSpec would be used to > * initialize an HKDF KeyGenerator: > *

>  *     byte[] salt;
>  *     SecretKey inputKey;
>  *     SecretKey resultingPRK;
>  *
>  *     // salt and inputKey values populated with data
>  *     ...
>  *
>  *     // Get an instance of the HKDF KeyGenerator
>  *     hkdfGen = KeyGenerator.getInstance("HkdfSHA256");
>  *
>  *     // Create the spec object and use it to initialize the generator.
>  *     hkdfGen.init(new HkdfExtractParameterSpec(salt, inputKey));
>  *
>  *     // Generate the PRK
>  *     resultingPRK = hkdfGen.generateKey();
>  * 
> * > * @since 9 > */ > public final class HkdfExtractParameterSpec implements > AlgorithmParameterSpec { > > /** > * Constructs a new HkdfExtractParameterSpec with the given salt > value > * and key material > * > * @param salt the salt value, or {@code null} if not specified. The > * contents of the array are copied to protect against > subsequent > * modification. > * @param inputKey the Input Keying Material (IKM). > * > * @throws NullPointerException if {@code inputKey} is {@code null}. > */ > public HkdfExtractParameterSpec(byte[] salt, SecretKey inputKey); > > /** > * Returns the Input Keying Material (IKM). > * > * @return the Input Keying Material. > */ > public SecretKey getIKM(); > > /** > * Returns the salt value. > * > * @return a copy of the salt value or {@code null} if no salt was > provided. > */ > public byte[] getSalt(); > } > > HkdfExpandParameterSpec: > ------------------------ > /** > * Parameters for the Expand operation of the HMAC-based > Extract-and-Expand > * Key Derivation Function (HKDF). The HKDF function is defined in > * RFC 5869. > *

> * Here is an example of how an HkdfExpandParameterSpec would be used to > * initialize an HKDF KeyGenerator: > *

>  *     byte[] info;
>  *     SecretKey pseudoRandomKey;
>  *     SecretKey resultingKey;
>  *
>  *     // pseudoRandomKey and context info values populated with data
>  *     ...
>  *
>  *     // Get an instance of the HKDF KeyGenerator
>  *     hkdfGen = KeyGenerator.getInstance("HkdfSHA256");
>  *
>  *     // Create the spec object and use it to initialize the generator.
>  *     // Ask for a 64-byte key to be output.
>  *     hkdfGen.init(new HkdfExpandParameterSpec(pseudoRandomKey, info, 
> 64));
>  *
>  *     // Generate the key
>  *     resultingKey = hkdfGen.generateKey();
>  * 
> * > * @since 9 > */ > public final class HkdfExpandParameterSpec implements > AlgorithmParameterSpec { > > /** > * Constructs a new HkdfExpandParameterSpec. > * > * @param prk the pseudorandom key used for HKDF-Expand. > * @param info optional context and application specific > information or > * {@code null} if no info data is provided. The contents of > the > * array are copied to protect against subsequent modification. > * @param outLen the length in bytes of the output data > * > * @throws NullPointerException if {@code prk} is {@code null}. > * @throws IllegalArgumentException if {@code outLen} is a > * non-positive value. > */ > public HkdfExpandParameterSpec(SecretKey prk, byte[] info, int > outLen); > > /** > * Returns a {@link SecretKey} object containing the pseudorandom > key (PRK). > * > * @return a {@link SecretKey} object containing the pseudorandom > key. > */ > public SecretKey getPRK(); > > /** > * Returns a copy of the context and application specific > information. > * > * @return a copy of the context and application specific > information. > * This may be {@code null} or empty if no specific > information was > * provided. > */ > public byte[] getInfo(); > > /** > * Returns the length in bytes of the output key to be produced. > * > * @return the length in bytes of the output key to be produced. > */ > public int getOutputLength(); > } > > > HkdfParameterSpec: > ------------------ > > /** > * Parameters for the combined Extract-then-Expand operation of the > HMAC-based > * Extract-and-Expand Key Derivation Function (HKDF). The HKDF function > * is defined in RFC > 5869. > *

> * Here is an example of how an HkdfParameterSpec would be used to > initialize > * an HKDF KeyGenerator: > *

>  *     byte[] salt;
>  *     byte[] info;
>  *     SecretKey inputKey;
>  *     SecretKey resultingKey;
>  *
>  *     // salt, info and inputKey values populated with data
>  *     ...
>  *
>  *     // Get an instance of the HKDF KeyGenerator
>  *     hkdfGen = KeyGenerator.getInstance("HkdfSHA256");
>  *
>  *     // Create the spec object and use it to initialize the generator.
>  *     // Ask for a 64-byte key to be output.
>  *     hkdfGen.init(new HkdfParameterSpec(inputKey, salt, info, 64));
>  *
>  *     // Generate the key
>  *     resultingKey = hkdfGen.generateKey();
>  * 
> * > * @since 9 > */ > public final class HkdfParameterSpec implements AlgorithmParameterSpec { > > /** > * Constructs a new HkdfParameterSpec. > * > * @param inputKey the input keying material used for the > * HKDF-Extract-then-Expand operation. > * @param salt the salt value, or {@code null} if not specified. The > * contents of the array are copied to protect against > subsequent > * modification. > * @param info optional context and application specific > information or > * {@code null} if no info data is provided. The contents of > the > * array are copied to protect against subsequent modification. > * @param outLen the length in bytes of the output data > * > * @throws NullPointerException if {@code inputKey} is {@code null}. > * @throws IllegalArgumentException if {@code outLen} is a > * non-positive value. > */ > public HkdfParameterSpec(SecretKey inputKey, byte[] salt, byte[] > info, > int outLen); > > /** > * Returns the Input Keying Material (IKM). > * > * @return the Input Keying Material. > */ > public SecretKey getIKM(); > > /** > * Returns the salt value. > * > * @return a copy of the salt value or {@code null} if no salt was > provided. > */ > public byte[] getSalt(); > > /** > * Returns a copy of the context and application specific > information. > * > * @return a copy of the context and application specific > information. > * This may be {@code null} or empty if no specific > information was > * provided. > */ > public byte[] getInfo(); > > /** > * Returns the length in bytes of the output key to be produced. > * > * @return the length in bytes of the output key to be produced. > */ > public int getOutputLength(); > } From jamil.j.nimeh at oracle.com Fri Apr 15 21:33:03 2016 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 15 Apr 2016 14:33:03 -0700 Subject: RFR: Proposed HKDF API (JDK-8145255) In-Reply-To: <571146FC.9020507@comcast.net> References: <57112DBD.2090508@oracle.com> <571146FC.9020507@comcast.net> Message-ID: <57115E0F.4090705@oracle.com> Hi Mike, thanks for your comments and suggestions, I need to digest some of this but I have some follow-up questions to start: On 04/15/2016 12:54 PM, Michael StJohns wrote: > Hi Jamil - > > I need to look at this a bit more, but I think its probably > incorrect. Basically, KDFs should be able to provide multiple keys > from a single call, not a single key as you've described here. Would that mean that a second call to Kdf.generateKey() with no prior reinitialization would create a new key of whatever output length it was initialized with, assuming the end state from the previous call? In other words, the output from generateKey1 and generateKey2 would yield the same bytes as it would if a single call was made for the combined length and then segmented after the fact? > They may also may need to provide non-key cryptographic material such > as IV's. The TLS1.2 KDF (PRF) is an example of this. > > There's this other problem that you're outputting unwrapped data - > which means you can never define this to run as a hardware module as > the outputs are byte arrays. The output from SunJCE's implementation (the only one we're doing right off the bat) would start as a byte array internally from HKDFKeyGenerator, true. But SunJCE's implementation is supposed to be native and not assuming outside hardware, AFAIK. If we had to interact with an HSM, I would think we'd need to define an HKDFKeyGenerator class within the SunPKCS11 provider, or some other provider capable of speaking to said HSM. My PKCS#11 is a bit rusty, but if the underlying provider had its own HDKF mechanism then I would guess we could call into C_DeriveKey using that mech and the template could mark the resulting key as sensitive or sensitive/non-extractable. If it didn't have an HKDF mechanism (OASIS hasn't defined an HKDF mechanism yet, have they?) then we could implement HKDF in terms of HMAC calls, but that doesn't solve the concern you have, since IIRC C_Sign calls would be used and those return byte arrays which would expose the key as bytes until a C_CreateObject could be called. Assuming though that SunPKCS11 could talk to an HSM that had an HKDF mech in their PKCS#11 library, and we added HKDF support to that provider, the output from KeyGenerator.generateKey() is a SecretKey, one that would I believe be a wrapper around an object handle rather than holding the actual key bytes (I'd have to go look to be sure). I think that's why calls like Key.getEncoded() are not guaranteed to return encoded data...in some cases like a PKCS#11 sensitive key we wouldn't be allowed access to it. > > So I'd generalize this more as: (This is a single pass design - I > haven't gone back and tweaked the obvious mistakes - not enough time > right now). Are you suggesting that your KDF solution below is accessed through the KeyGenerator API and the implementation would derive from KeyGeneratorSpi? I ask because two of the forms of init you provide below are not part of the API. Or are you thinking of it as standalone or derived from another API? Some of the calls make it look like it's intended to be a KeyGenerator and that's why I ask. > > Kdf.getInstance(String algName); > > Kdf.init (AlgorithmParameterSpec kdfSpec); // only one key produced, > well defined by the algName, no parameters required. > Kdf.init (AlgorithmParameterSpec kdfSpec, KDFAlgorithmParameterSpec > keyspec); > Kdf.init (AlgorithmParameterSpec kdfSpec, KDFAlgorithmParameterSpec[] > keyspecs); > > Key xxx = Kdf.generateKey(); > Key[] xxx = Kdf.generateKeys(); Why do we need an array form for generateKeys? Is that just a convenience? Is it inspired by the TLS-style key/mac/IV derivation? > > public interface KDFAlgorithmParameterSpec extends > AlgorithmParameterSpec { > public KDFParameters[] getParams(); > } > > public class SecretKeyAlgorithmSpec implements > KDFAlgorithmParameterSpec { > public SecretKeyAlgorithmSpec (String algorithm, int size, > KDFParameters ... params ); > public int getSize(); > public String getAlgorithm(); > public KDFParameters[] getParams(); > } > > public interface KDFParameters{}; > > KDFParameters is a marker interface to deal with mixin parameters that > are specific to the key material. > > I'd define HKDF as the instance type for the Kdf.getInstance(). > > I'd define HKDFAlgorithmParameterSpec and place the info on which PRF > function to use in that spec along with any other instance specific > stuff. This is also where you put the context and label mixin data. > > > I'd then define the "HKDFExtract" and "HKDFExpand" as two separate > KDFs. The first produces a single Key of instance type MasterKey > (which is a sub type of SecretKey) which is a well known length based > on the provided PRF. The second produces whatever you ask for based > on the key spec's you provide. > > This generalizes well to other KDFs including SP800-108. I'll have to spend a little time digesting what you put down here. Interesting stuff. --Jamil > > Mike > > > > > > > > > On 4/15/2016 2:06 PM, Jamil Nimeh wrote: >> Hello all, >> >> We are looking to add HKDF support as a KeyGenerator into OpenJDK 9. >> This will be available for general-purpose use. I've documented the >> proposed API below. >> >> RFE: https://bugs.openjdk.java.net/browse/JDK-8145255 >> Proof-of-concept implementation: >> http://cr.openjdk.java.net/~jnimeh/reviews/8145255/webrev.1/ >> >> A set of new standard algorithm names would be created that define >> the HMAC algorithm used with HKDF: HkdfSHA224, HkdfSHA256, HkdfSHA384 >> and HkdfSHA512. We can at a later date include HKDF variants that >> use other supported HMAC algorithms. >> >> Instantiation: >> -------------- >> In order to do HKDF derivations, a KeyGenerator of the appropriate >> type must be obtained. This is done using one of the >> KeyGenerator.getInstance methods, specifying the underlying HMAC type >> using one of the names listed above. >> >> Initialization: >> --------------- >> The resulting HKDF KeyGenerator, in order to be compliant with the >> KeyGenerator API, may be used to generate a key without any further >> initialization. In this case, the Extract-then-Expand operation will >> be performed using null salt and application-specific information, >> and a random input key. The resulting output key will be sized to >> the output length of the underlying HMAC. This can be used as a way >> to obtain a random key. >> >> The HKDF KeyGenerator supports all five flavors of the init method. >> The resulting behavior differs between each flavor however. >> >> KeyGenerator.init(SecureRandom): >> -------------------------------- >> If this version of the init method is used, the KeyGenerator will >> behave similarly to the default initialization, with the exception >> that the caller may provide their own SecureRandom source for the >> input key. A null value is allowed, in which case the implementation >> will obtain the default SecureRandom implementation for generating >> the input key. >> >> KeyGenerator.init(int); >> KeyGenerator.init(int, SecureRandom); >> ------------------------------------- >> These two versions of the KeyGenerator allow the caller to provide >> the resulting key length and, in the second case provide a >> SecureRandom source. The caller must provide a non-negative length >> value in bytes. A value of zero is allowed and returns a key of the >> same length as the underlying HMAC. In both forms the >> Extract-then-Expand operation will be performed with null salt and >> application-specific information, and a random input key. If a >> SecureRandom value is provided, its behavior is similar to >> KeyGenerator.init(SecureRandom). >> >> KeyGenerator.init(AlgorithmParameterSpec); >> KeyGenerator.init(AlgorithmParameterSpec, SecureRandom); >> -------------------------------------------------------- >> These versions of the init method allow the caller to customize the >> input parameters to the HKDF generator as well as select the HKDF >> function to perform. >> >> Users desiring a specific HKDF function would initialize it using one >> of three new AlgorithmParameterSpec classes: >> HkdfExtractParameterSpec, HkdfExpandParameterSpec, or >> HkdfParameterSpec. These three parameter spec classes are used to >> initialize the HKDF key generator to perform the HKDF-Expand, >> HKDF-Extract or a combination HKDF-Extract-then-Expand operation, >> respectively. >> >> The init(AlgorithmParameterSpec, SecureRandom) ignores the >> SecureRandom parameter, and requires that input key material (IKM) or >> a pseudorandom key (PRK) is provided. >> >> Key Generation: >> --------------- >> Once initialized (default or via one of the init methods) a key is >> generated by calling KeyGenerator.generateKey(). >> >> >> The Specification: >> ------------------ >> Three new AlgorithmParameterSpec classes will be created to >> initialize HKDF KeyGenerator objects: >> HkdfParameterSpec: For performing the Extract-then-Expand operation >> HkdfExtractParameterSpec: For performingthe HKDF-Extract operation >> HkdfExpandParameterSpec: For performing the HKDF-Expand operation >> >> >> /** >> * Parameters for the Extract operation of the HMAC-based >> Extract-and-Expand >> * Key Derivation Function (HKDF). The HKDF function is defined in >> * RFC 5869. >> * This class is used to initialize KeyGenerators in the HKDF family of >> * generators, specifically for the HKDF Extract function. >> *

>> * Here is an example of how an HkdfExtractParameterSpec would be >> used to >> * initialize an HKDF KeyGenerator: >> *

>>  *     byte[] salt;
>>  *     SecretKey inputKey;
>>  *     SecretKey resultingPRK;
>>  *
>>  *     // salt and inputKey values populated with data
>>  *     ...
>>  *
>>  *     // Get an instance of the HKDF KeyGenerator
>>  *     hkdfGen = KeyGenerator.getInstance("HkdfSHA256");
>>  *
>>  *     // Create the spec object and use it to initialize the generator.
>>  *     hkdfGen.init(new HkdfExtractParameterSpec(salt, inputKey));
>>  *
>>  *     // Generate the PRK
>>  *     resultingPRK = hkdfGen.generateKey();
>>  * 
>> * >> * @since 9 >> */ >> public final class HkdfExtractParameterSpec implements >> AlgorithmParameterSpec { >> >> /** >> * Constructs a new HkdfExtractParameterSpec with the given salt >> value >> * and key material >> * >> * @param salt the salt value, or {@code null} if not specified. >> The >> * contents of the array are copied to protect against >> subsequent >> * modification. >> * @param inputKey the Input Keying Material (IKM). >> * >> * @throws NullPointerException if {@code inputKey} is {@code null}. >> */ >> public HkdfExtractParameterSpec(byte[] salt, SecretKey inputKey); >> >> /** >> * Returns the Input Keying Material (IKM). >> * >> * @return the Input Keying Material. >> */ >> public SecretKey getIKM(); >> >> /** >> * Returns the salt value. >> * >> * @return a copy of the salt value or {@code null} if no salt >> was provided. >> */ >> public byte[] getSalt(); >> } >> >> HkdfExpandParameterSpec: >> ------------------------ >> /** >> * Parameters for the Expand operation of the HMAC-based >> Extract-and-Expand >> * Key Derivation Function (HKDF). The HKDF function is defined in >> * RFC 5869. >> *

>> * Here is an example of how an HkdfExpandParameterSpec would be used to >> * initialize an HKDF KeyGenerator: >> *

>>  *     byte[] info;
>>  *     SecretKey pseudoRandomKey;
>>  *     SecretKey resultingKey;
>>  *
>>  *     // pseudoRandomKey and context info values populated with data
>>  *     ...
>>  *
>>  *     // Get an instance of the HKDF KeyGenerator
>>  *     hkdfGen = KeyGenerator.getInstance("HkdfSHA256");
>>  *
>>  *     // Create the spec object and use it to initialize the generator.
>>  *     // Ask for a 64-byte key to be output.
>>  *     hkdfGen.init(new HkdfExpandParameterSpec(pseudoRandomKey, 
>> info, 64));
>>  *
>>  *     // Generate the key
>>  *     resultingKey = hkdfGen.generateKey();
>>  * 
>> * >> * @since 9 >> */ >> public final class HkdfExpandParameterSpec implements >> AlgorithmParameterSpec { >> >> /** >> * Constructs a new HkdfExpandParameterSpec. >> * >> * @param prk the pseudorandom key used for HKDF-Expand. >> * @param info optional context and application specific >> information or >> * {@code null} if no info data is provided. The contents >> of the >> * array are copied to protect against subsequent modification. >> * @param outLen the length in bytes of the output data >> * >> * @throws NullPointerException if {@code prk} is {@code null}. >> * @throws IllegalArgumentException if {@code outLen} is a >> * non-positive value. >> */ >> public HkdfExpandParameterSpec(SecretKey prk, byte[] info, int >> outLen); >> >> /** >> * Returns a {@link SecretKey} object containing the pseudorandom >> key (PRK). >> * >> * @return a {@link SecretKey} object containing the pseudorandom >> key. >> */ >> public SecretKey getPRK(); >> >> /** >> * Returns a copy of the context and application specific >> information. >> * >> * @return a copy of the context and application specific >> information. >> * This may be {@code null} or empty if no specific >> information was >> * provided. >> */ >> public byte[] getInfo(); >> >> /** >> * Returns the length in bytes of the output key to be produced. >> * >> * @return the length in bytes of the output key to be produced. >> */ >> public int getOutputLength(); >> } >> >> >> HkdfParameterSpec: >> ------------------ >> >> /** >> * Parameters for the combined Extract-then-Expand operation of the >> HMAC-based >> * Extract-and-Expand Key Derivation Function (HKDF). The HKDF function >> * is defined in RFC >> 5869. >> *

>> * Here is an example of how an HkdfParameterSpec would be used to >> initialize >> * an HKDF KeyGenerator: >> *

>>  *     byte[] salt;
>>  *     byte[] info;
>>  *     SecretKey inputKey;
>>  *     SecretKey resultingKey;
>>  *
>>  *     // salt, info and inputKey values populated with data
>>  *     ...
>>  *
>>  *     // Get an instance of the HKDF KeyGenerator
>>  *     hkdfGen = KeyGenerator.getInstance("HkdfSHA256");
>>  *
>>  *     // Create the spec object and use it to initialize the generator.
>>  *     // Ask for a 64-byte key to be output.
>>  *     hkdfGen.init(new HkdfParameterSpec(inputKey, salt, info, 64));
>>  *
>>  *     // Generate the key
>>  *     resultingKey = hkdfGen.generateKey();
>>  * 
>> * >> * @since 9 >> */ >> public final class HkdfParameterSpec implements AlgorithmParameterSpec { >> >> /** >> * Constructs a new HkdfParameterSpec. >> * >> * @param inputKey the input keying material used for the >> * HKDF-Extract-then-Expand operation. >> * @param salt the salt value, or {@code null} if not specified. >> The >> * contents of the array are copied to protect against >> subsequent >> * modification. >> * @param info optional context and application specific >> information or >> * {@code null} if no info data is provided. The contents >> of the >> * array are copied to protect against subsequent modification. >> * @param outLen the length in bytes of the output data >> * >> * @throws NullPointerException if {@code inputKey} is {@code null}. >> * @throws IllegalArgumentException if {@code outLen} is a >> * non-positive value. >> */ >> public HkdfParameterSpec(SecretKey inputKey, byte[] salt, byte[] >> info, >> int outLen); >> >> /** >> * Returns the Input Keying Material (IKM). >> * >> * @return the Input Keying Material. >> */ >> public SecretKey getIKM(); >> >> /** >> * Returns the salt value. >> * >> * @return a copy of the salt value or {@code null} if no salt >> was provided. >> */ >> public byte[] getSalt(); >> >> /** >> * Returns a copy of the context and application specific >> information. >> * >> * @return a copy of the context and application specific >> information. >> * This may be {@code null} or empty if no specific >> information was >> * provided. >> */ >> public byte[] getInfo(); >> >> /** >> * Returns the length in bytes of the output key to be produced. >> * >> * @return the length in bytes of the output key to be produced. >> */ >> public int getOutputLength(); >> } > From valerie.peng at oracle.com Fri Apr 15 23:54:10 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 15 Apr 2016 16:54:10 -0700 Subject: RFR 8053371: Remove sun.misc.ManagedLocalsThread from jdk.crypto.pkcs11 Message-ID: <57117F22.7090804@oracle.com> Anyone can help reviewing this? Just a one-line replacement for switching to the new public Thread constructor. No new regression test as it should be covered by the existing one. Webrev: http://cr.openjdk.java.net/~valeriep/8053371/webrev.00/ Thanks, Valerie From rajan.halade at oracle.com Sat Apr 16 00:00:54 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Fri, 15 Apr 2016 17:00:54 -0700 Subject: RFR: [9]: 8154382: Remove intermittent keyword from SupportedDSAParamGen.java Message-ID: <571180B6.6090103@oracle.com> Please review following patch to remove intermittent keyword from this test. Test has never seen to fail intermittently. diff -r 8606d027b2c2 test/sun/security/provider/DSA/SupportedDSAParamGen.java --- a/test/sun/security/provider/DSA/SupportedDSAParamGen.java Fri Apr 15 16:19:15 2016 +0100 +++ b/test/sun/security/provider/DSA/SupportedDSAParamGen.java Fri Apr 15 16:58:04 2016 -0700 @@ -24,7 +24,6 @@ /* * @test * @bug 8072452 - * @key intermittent * @summary Support DHE sizes up to 8192-bits and DSA sizes up to 3072-bits * @run main/timeout=300 SupportedDSAParamGen 1024 160 * @run main/timeout=300 SupportedDSAParamGen 2048 224 Thanks, Rajan From mstjohns at comcast.net Sat Apr 16 00:02:02 2016 From: mstjohns at comcast.net (Michael StJohns) Date: Fri, 15 Apr 2016 20:02:02 -0400 Subject: RFR: Proposed HKDF API (JDK-8145255) In-Reply-To: <57115E0F.4090705@oracle.com> References: <57112DBD.2090508@oracle.com> <571146FC.9020507@comcast.net> <57115E0F.4090705@oracle.com> Message-ID: <571180FA.1020509@comcast.net> On 4/15/2016 5:33 PM, Jamil Nimeh wrote: > Hi Mike, thanks for your comments and suggestions, I need to digest > some of this but I have some follow-up questions to start: > > On 04/15/2016 12:54 PM, Michael StJohns wrote: >> Hi Jamil - >> >> I need to look at this a bit more, but I think its probably >> incorrect. Basically, KDFs should be able to provide multiple keys >> from a single call, not a single key as you've described here. > Would that mean that a second call to Kdf.generateKey() with no prior > reinitialization would create a new key of whatever output length it > was initialized with, assuming the end state from the previous call? > In other words, the output from generateKey1 and generateKey2 would > yield the same bytes as it would if a single call was made for the > combined length and then segmented after the fact? No. Calling generateKey again would get you the exact same key as before. Same initial key, same input data, same output data. I'd probably wipe the state and require a reinitialization rather than do that. You *don't* want to treat this like a DRBG. >> They may also may need to provide non-key cryptographic material such >> as IV's. The TLS1.2 KDF (PRF) is an example of this. >> >> There's this other problem that you're outputting unwrapped data - >> which means you can never define this to run as a hardware module as >> the outputs are byte arrays. > The output from SunJCE's implementation (the only one we're doing > right off the bat) would start as a byte array internally from > HKDFKeyGenerator, true. But SunJCE's implementation is supposed to be > native and not assuming outside hardware, AFAIK. If we had to > interact with an HSM, I would think we'd need to define an > HKDFKeyGenerator class within the SunPKCS11 provider, or some other > provider capable of speaking to said HSM. Probably, but for software keys you can usually use the "getBytes()" or equivalent (getEncoded() for SecretKeySpec...) to get out the bytes if you really need them. Its harder to do this the other way - if you always have to output bytes, then it won't work in most HSMs. > > My PKCS#11 is a bit rusty, but if the underlying provider had its own > HDKF mechanism then I would guess we could call into C_DeriveKey using > that mech and the template could mark the resulting key as sensitive > or sensitive/non-extractable. If it didn't have an HKDF mechanism > (OASIS hasn't defined an HKDF mechanism yet, have they?) then we could > implement HKDF in terms of HMAC calls, but that doesn't solve the > concern you have, since IIRC C_Sign calls would be used and those > return byte arrays which would expose the key as bytes until a > C_CreateObject could be called. If the Master Key or Key Derivation Key is inside the HSM, then you have to use whatever mechanism that gets described to do the KDF function. AFAICT, Oasis hasn't yet done a KDF for HKDF. You might ask Valerie Fenwick @oracle to put it on the list of things to do (or you could even write a contribution :-) ). > > Assuming though that SunPKCS11 could talk to an HSM that had an HKDF > mech in their PKCS#11 library, and we added HKDF support to that > provider, the output from KeyGenerator.generateKey() is a SecretKey, > one that would I believe be a wrapper around an object handle rather > than holding the actual key bytes (I'd have to go look to be sure). I > think that's why calls like Key.getEncoded() are not guaranteed to > return encoded data...in some cases like a PKCS#11 sensitive key we > wouldn't be allowed access to it. Exactly. >> >> So I'd generalize this more as: (This is a single pass design - I >> haven't gone back and tweaked the obvious mistakes - not enough time >> right now). > Are you suggesting that your KDF solution below is accessed through > the KeyGenerator API and the implementation would derive from > KeyGeneratorSpi? I ask because two of the forms of init you provide > below are not part of the API. I think a KDF is a different beast than a KeyGenerator. Trying to overload KeyGenerator to work with KDF's is problematic. KeyGenerators generate exactly one type of key. KeyDerivationFunctions can generate ANY type of key. > > Or are you thinking of it as standalone or derived from another API? > Some of the calls make it look like it's intended to be a KeyGenerator > and that's why I ask. >> >> Kdf.getInstance(String algName); >> >> Kdf.init (AlgorithmParameterSpec kdfSpec); // only one key produced, >> well defined by the algName, no parameters required. >> Kdf.init (AlgorithmParameterSpec kdfSpec, KDFAlgorithmParameterSpec >> keyspec); >> Kdf.init (AlgorithmParameterSpec kdfSpec, KDFAlgorithmParameterSpec[] >> keyspecs); >> >> Key xxx = Kdf.generateKey(); >> Key[] xxx = Kdf.generateKeys(); > Why do we need an array form for generateKeys? Is that just a > convenience? Is it inspired by the TLS-style key/mac/IV derivation? This goes back to the fact that you call generate only once per init. You want to make sure that if the order of the keys to which key material is assigned changes, then so to does the underlying derived key stream. (I've got a long rant related to this - but basically, you want to make it possible (or least have the API make it possible) to mixin all of the assignment of key material to cryptographic objecs - e.g. key type, key length, key protection bits etc. HDKF might not do this, but other KDFs will and do. The makes it possible for an HSM to use the mixin data to figure out what protection to assign to the generated keys in a way that depends on the derivation constants - any change to the constants changes the entire key stream). It turns out that its trivial to extract TLS keys from an HSM because the TLS KDF doesn't mixin the key type and lengths for the keys and IV it generates, so the derived key stream doesn't change if you change the keys to be produced. See https://www.ietf.org/mail-archive/web/i-d-announce/current/msg67039.html - I need to go back and get this accepted. >> >> public interface KDFAlgorithmParameterSpec extends >> AlgorithmParameterSpec { >> public KDFParameters[] getParams(); >> } >> >> public class SecretKeyAlgorithmSpec implements >> KDFAlgorithmParameterSpec { >> public SecretKeyAlgorithmSpec (String algorithm, int size, >> KDFParameters ... params ); >> public int getSize(); >> public String getAlgorithm(); >> public KDFParameters[] getParams(); >> } >> >> public interface KDFParameters{}; >> >> KDFParameters is a marker interface to deal with mixin parameters >> that are specific to the key material. >> >> I'd define HKDF as the instance type for the Kdf.getInstance(). >> >> I'd define HKDFAlgorithmParameterSpec and place the info on which >> PRF function to use in that spec along with any other instance >> specific stuff. This is also where you put the context and label >> mixin data. >> >> >> I'd then define the "HKDFExtract" and "HKDFExpand" as two separate >> KDFs. The first produces a single Key of instance type MasterKey >> (which is a sub type of SecretKey) which is a well known length based >> on the provided PRF. The second produces whatever you ask for based >> on the key spec's you provide. >> >> This generalizes well to other KDFs including SP800-108. > I'll have to spend a little time digesting what you put down here. > Interesting stuff. Yeah - I think this is probably more than you want to do, and is going to require an API change, but I also think that is the right way to do it. Mike > > --Jamil >> >> Mike >> >> >> >> >> >> >> >> >> On 4/15/2016 2:06 PM, Jamil Nimeh wrote: >>> Hello all, >>> >>> We are looking to add HKDF support as a KeyGenerator into OpenJDK >>> 9. This will be available for general-purpose use. I've documented >>> the proposed API below. >>> >>> RFE: https://bugs.openjdk.java.net/browse/JDK-8145255 >>> Proof-of-concept implementation: >>> http://cr.openjdk.java.net/~jnimeh/reviews/8145255/webrev.1/ >>> >>> A set of new standard algorithm names would be created that define >>> the HMAC algorithm used with HKDF: HkdfSHA224, HkdfSHA256, >>> HkdfSHA384 and HkdfSHA512. We can at a later date include HKDF >>> variants that use other supported HMAC algorithms. >>> >>> Instantiation: >>> -------------- >>> In order to do HKDF derivations, a KeyGenerator of the appropriate >>> type must be obtained. This is done using one of the >>> KeyGenerator.getInstance methods, specifying the underlying HMAC >>> type using one of the names listed above. >>> >>> Initialization: >>> --------------- >>> The resulting HKDF KeyGenerator, in order to be compliant with the >>> KeyGenerator API, may be used to generate a key without any further >>> initialization. In this case, the Extract-then-Expand operation >>> will be performed using null salt and application-specific >>> information, and a random input key. The resulting output key will >>> be sized to the output length of the underlying HMAC. This can be >>> used as a way to obtain a random key. >>> >>> The HKDF KeyGenerator supports all five flavors of the init method. >>> The resulting behavior differs between each flavor however. >>> >>> KeyGenerator.init(SecureRandom): >>> -------------------------------- >>> If this version of the init method is used, the KeyGenerator will >>> behave similarly to the default initialization, with the exception >>> that the caller may provide their own SecureRandom source for the >>> input key. A null value is allowed, in which case the >>> implementation will obtain the default SecureRandom implementation >>> for generating the input key. >>> >>> KeyGenerator.init(int); >>> KeyGenerator.init(int, SecureRandom); >>> ------------------------------------- >>> These two versions of the KeyGenerator allow the caller to provide >>> the resulting key length and, in the second case provide a >>> SecureRandom source. The caller must provide a non-negative length >>> value in bytes. A value of zero is allowed and returns a key of the >>> same length as the underlying HMAC. In both forms the >>> Extract-then-Expand operation will be performed with null salt and >>> application-specific information, and a random input key. If a >>> SecureRandom value is provided, its behavior is similar to >>> KeyGenerator.init(SecureRandom). >>> >>> KeyGenerator.init(AlgorithmParameterSpec); >>> KeyGenerator.init(AlgorithmParameterSpec, SecureRandom); >>> -------------------------------------------------------- >>> These versions of the init method allow the caller to customize the >>> input parameters to the HKDF generator as well as select the HKDF >>> function to perform. >>> >>> Users desiring a specific HKDF function would initialize it using >>> one of three new AlgorithmParameterSpec classes: >>> HkdfExtractParameterSpec, HkdfExpandParameterSpec, or >>> HkdfParameterSpec. These three parameter spec classes are used to >>> initialize the HKDF key generator to perform the HKDF-Expand, >>> HKDF-Extract or a combination HKDF-Extract-then-Expand operation, >>> respectively. >>> >>> The init(AlgorithmParameterSpec, SecureRandom) ignores the >>> SecureRandom parameter, and requires that input key material (IKM) >>> or a pseudorandom key (PRK) is provided. >>> >>> Key Generation: >>> --------------- >>> Once initialized (default or via one of the init methods) a key is >>> generated by calling KeyGenerator.generateKey(). >>> >>> >>> The Specification: >>> ------------------ >>> Three new AlgorithmParameterSpec classes will be created to >>> initialize HKDF KeyGenerator objects: >>> HkdfParameterSpec: For performing the Extract-then-Expand operation >>> HkdfExtractParameterSpec: For performingthe HKDF-Extract operation >>> HkdfExpandParameterSpec: For performing the HKDF-Expand operation >>> >>> >>> /** >>> * Parameters for the Extract operation of the HMAC-based >>> Extract-and-Expand >>> * Key Derivation Function (HKDF). The HKDF function is defined in >>> * RFC 5869. >>> * This class is used to initialize KeyGenerators in the HKDF family of >>> * generators, specifically for the HKDF Extract function. >>> *

>>> * Here is an example of how an HkdfExtractParameterSpec would be >>> used to >>> * initialize an HKDF KeyGenerator: >>> *

>>>  *     byte[] salt;
>>>  *     SecretKey inputKey;
>>>  *     SecretKey resultingPRK;
>>>  *
>>>  *     // salt and inputKey values populated with data
>>>  *     ...
>>>  *
>>>  *     // Get an instance of the HKDF KeyGenerator
>>>  *     hkdfGen = KeyGenerator.getInstance("HkdfSHA256");
>>>  *
>>>  *     // Create the spec object and use it to initialize the 
>>> generator.
>>>  *     hkdfGen.init(new HkdfExtractParameterSpec(salt, inputKey));
>>>  *
>>>  *     // Generate the PRK
>>>  *     resultingPRK = hkdfGen.generateKey();
>>>  * 
>>> * >>> * @since 9 >>> */ >>> public final class HkdfExtractParameterSpec implements >>> AlgorithmParameterSpec { >>> >>> /** >>> * Constructs a new HkdfExtractParameterSpec with the given salt >>> value >>> * and key material >>> * >>> * @param salt the salt value, or {@code null} if not >>> specified. The >>> * contents of the array are copied to protect against >>> subsequent >>> * modification. >>> * @param inputKey the Input Keying Material (IKM). >>> * >>> * @throws NullPointerException if {@code inputKey} is {@code >>> null}. >>> */ >>> public HkdfExtractParameterSpec(byte[] salt, SecretKey inputKey); >>> >>> /** >>> * Returns the Input Keying Material (IKM). >>> * >>> * @return the Input Keying Material. >>> */ >>> public SecretKey getIKM(); >>> >>> /** >>> * Returns the salt value. >>> * >>> * @return a copy of the salt value or {@code null} if no salt >>> was provided. >>> */ >>> public byte[] getSalt(); >>> } >>> >>> HkdfExpandParameterSpec: >>> ------------------------ >>> /** >>> * Parameters for the Expand operation of the HMAC-based >>> Extract-and-Expand >>> * Key Derivation Function (HKDF). The HKDF function is defined in >>> * RFC 5869. >>> *

>>> * Here is an example of how an HkdfExpandParameterSpec would be >>> used to >>> * initialize an HKDF KeyGenerator: >>> *

>>>  *     byte[] info;
>>>  *     SecretKey pseudoRandomKey;
>>>  *     SecretKey resultingKey;
>>>  *
>>>  *     // pseudoRandomKey and context info values populated with data
>>>  *     ...
>>>  *
>>>  *     // Get an instance of the HKDF KeyGenerator
>>>  *     hkdfGen = KeyGenerator.getInstance("HkdfSHA256");
>>>  *
>>>  *     // Create the spec object and use it to initialize the 
>>> generator.
>>>  *     // Ask for a 64-byte key to be output.
>>>  *     hkdfGen.init(new HkdfExpandParameterSpec(pseudoRandomKey, 
>>> info, 64));
>>>  *
>>>  *     // Generate the key
>>>  *     resultingKey = hkdfGen.generateKey();
>>>  * 
>>> * >>> * @since 9 >>> */ >>> public final class HkdfExpandParameterSpec implements >>> AlgorithmParameterSpec { >>> >>> /** >>> * Constructs a new HkdfExpandParameterSpec. >>> * >>> * @param prk the pseudorandom key used for HKDF-Expand. >>> * @param info optional context and application specific >>> information or >>> * {@code null} if no info data is provided. The contents >>> of the >>> * array are copied to protect against subsequent >>> modification. >>> * @param outLen the length in bytes of the output data >>> * >>> * @throws NullPointerException if {@code prk} is {@code null}. >>> * @throws IllegalArgumentException if {@code outLen} is a >>> * non-positive value. >>> */ >>> public HkdfExpandParameterSpec(SecretKey prk, byte[] info, int >>> outLen); >>> >>> /** >>> * Returns a {@link SecretKey} object containing the >>> pseudorandom key (PRK). >>> * >>> * @return a {@link SecretKey} object containing the >>> pseudorandom key. >>> */ >>> public SecretKey getPRK(); >>> >>> /** >>> * Returns a copy of the context and application specific >>> information. >>> * >>> * @return a copy of the context and application specific >>> information. >>> * This may be {@code null} or empty if no specific >>> information was >>> * provided. >>> */ >>> public byte[] getInfo(); >>> >>> /** >>> * Returns the length in bytes of the output key to be produced. >>> * >>> * @return the length in bytes of the output key to be produced. >>> */ >>> public int getOutputLength(); >>> } >>> >>> >>> HkdfParameterSpec: >>> ------------------ >>> >>> /** >>> * Parameters for the combined Extract-then-Expand operation of the >>> HMAC-based >>> * Extract-and-Expand Key Derivation Function (HKDF). The HKDF function >>> * is defined in RFC >>> 5869. >>> *

>>> * Here is an example of how an HkdfParameterSpec would be used to >>> initialize >>> * an HKDF KeyGenerator: >>> *

>>>  *     byte[] salt;
>>>  *     byte[] info;
>>>  *     SecretKey inputKey;
>>>  *     SecretKey resultingKey;
>>>  *
>>>  *     // salt, info and inputKey values populated with data
>>>  *     ...
>>>  *
>>>  *     // Get an instance of the HKDF KeyGenerator
>>>  *     hkdfGen = KeyGenerator.getInstance("HkdfSHA256");
>>>  *
>>>  *     // Create the spec object and use it to initialize the 
>>> generator.
>>>  *     // Ask for a 64-byte key to be output.
>>>  *     hkdfGen.init(new HkdfParameterSpec(inputKey, salt, info, 64));
>>>  *
>>>  *     // Generate the key
>>>  *     resultingKey = hkdfGen.generateKey();
>>>  * 
>>> * >>> * @since 9 >>> */ >>> public final class HkdfParameterSpec implements >>> AlgorithmParameterSpec { >>> >>> /** >>> * Constructs a new HkdfParameterSpec. >>> * >>> * @param inputKey the input keying material used for the >>> * HKDF-Extract-then-Expand operation. >>> * @param salt the salt value, or {@code null} if not >>> specified. The >>> * contents of the array are copied to protect against >>> subsequent >>> * modification. >>> * @param info optional context and application specific >>> information or >>> * {@code null} if no info data is provided. The contents >>> of the >>> * array are copied to protect against subsequent >>> modification. >>> * @param outLen the length in bytes of the output data >>> * >>> * @throws NullPointerException if {@code inputKey} is {@code >>> null}. >>> * @throws IllegalArgumentException if {@code outLen} is a >>> * non-positive value. >>> */ >>> public HkdfParameterSpec(SecretKey inputKey, byte[] salt, byte[] >>> info, >>> int outLen); >>> >>> /** >>> * Returns the Input Keying Material (IKM). >>> * >>> * @return the Input Keying Material. >>> */ >>> public SecretKey getIKM(); >>> >>> /** >>> * Returns the salt value. >>> * >>> * @return a copy of the salt value or {@code null} if no salt >>> was provided. >>> */ >>> public byte[] getSalt(); >>> >>> /** >>> * Returns a copy of the context and application specific >>> information. >>> * >>> * @return a copy of the context and application specific >>> information. >>> * This may be {@code null} or empty if no specific >>> information was >>> * provided. >>> */ >>> public byte[] getInfo(); >>> >>> /** >>> * Returns the length in bytes of the output key to be produced. >>> * >>> * @return the length in bytes of the output key to be produced. >>> */ >>> public int getOutputLength(); >>> } >> > From xuelei.fan at oracle.com Sat Apr 16 00:07:50 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 16 Apr 2016 08:07:50 +0800 Subject: RFR 8053371: Remove sun.misc.ManagedLocalsThread from jdk.crypto.pkcs11 In-Reply-To: <57117F22.7090804@oracle.com> References: <57117F22.7090804@oracle.com> Message-ID: <57118256.1080405@oracle.com> Looks like there jdk.crypto.pkcs11 has no dependence on jdk.unsupported any more. Do you want to update the module-info.java in this update? module jdk.crypto.pkcs11 { // Depends on SunEC provider for EC related functionality requires jdk.crypto.ec; - // 8153371 - requires jdk.unsupported; provides java.security.Provider with sun.security.pkcs11.SunPKCS11; } Xuelei On 4/16/2016 7:54 AM, Valerie Peng wrote: > > Anyone can help reviewing this? > Just a one-line replacement for switching to the new public Thread > constructor. > No new regression test as it should be covered by the existing one. > > Webrev: http://cr.openjdk.java.net/~valeriep/8053371/webrev.00/ > > Thanks, > Valerie From valerie.peng at oracle.com Sat Apr 16 00:09:00 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 15 Apr 2016 17:09:00 -0700 Subject: RFR 8077360: Lower the number of providers created when using ServiceLoader Message-ID: <5711829C.4040003@oracle.com> Hi Sean, Not sure if you have reviewed this or not as you were on vacation while Mandy and Alan reviewed this prototype fix for Jigsaw workspace earlier. Now that the relevant Jigsaw code have been merged into JDK, I plan to integrate this fix into JDK workspace instead. I verified the fixes by manually checking the number of Provider created by going through the security debugging output. Bug: https://bugs.openjdk.java.net/browse/JDK-8077360 Webrev: http://cr.openjdk.java.net/~valeriep/8077360/webrev.00/ Thanks, Valerie From valerie.peng at oracle.com Sat Apr 16 00:13:23 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 15 Apr 2016 17:13:23 -0700 Subject: RFR 8153371: Remove sun.misc.ManagedLocalsThread from jdk.crypto.pkcs11 In-Reply-To: <57117F22.7090804@oracle.com> References: <57117F22.7090804@oracle.com> Message-ID: <571183A3.5020300@oracle.com> NOTE: resend with the correct bug id. Anyone can help reviewing this? Just a one-line replacement for switching to the new public Thread constructor. No new regression test as it should be covered by the existing one. Webrev: http://cr.openjdk.java.net/~valeriep/8153371/webrev.00/ Thanks, Valerie From xuelei.fan at oracle.com Sat Apr 16 00:22:15 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 16 Apr 2016 08:22:15 +0800 Subject: RFR 8153371: Remove sun.misc.ManagedLocalsThread from jdk.crypto.pkcs11 In-Reply-To: <571183A3.5020300@oracle.com> References: <57117F22.7090804@oracle.com> <571183A3.5020300@oracle.com> Message-ID: <571185B7.5090002@oracle.com> Resend. Looks like there jdk.crypto.pkcs11 has no dependence on jdk.unsupported any more. Do you want to update the module-info.java in this update? module jdk.crypto.pkcs11 { // Depends on SunEC provider for EC related functionality requires jdk.crypto.ec; - // 8153371 - requires jdk.unsupported; provides java.security.Provider with sun.security.pkcs11.SunPKCS11; } Otherwise, looks fine to me. Xuelei On 4/16/2016 8:13 AM, Valerie Peng wrote: > NOTE: resend with the correct bug id. > > Anyone can help reviewing this? Just a one-line replacement for > switching to the new public Thread constructor. > No new regression test as it should be covered by the existing one. > > Webrev: http://cr.openjdk.java.net/~valeriep/8153371/webrev.00/ > > Thanks, > Valerie From valerie.peng at oracle.com Sat Apr 16 00:29:52 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 15 Apr 2016 17:29:52 -0700 Subject: RFR 8153371: Remove sun.misc.ManagedLocalsThread from jdk.crypto.pkcs11 In-Reply-To: <571185B7.5090002@oracle.com> References: <57117F22.7090804@oracle.com> <571183A3.5020300@oracle.com> <571185B7.5090002@oracle.com> Message-ID: <57118780.6030103@oracle.com> Good point. I will update the module-info.java as well. Thanks, Valerie On 4/15/2016 5:22 PM, Xuelei Fan wrote: > Resend. > > Looks like there jdk.crypto.pkcs11 has no dependence on jdk.unsupported > any more. Do you want to update the module-info.java in this update? > > module jdk.crypto.pkcs11 { > // Depends on SunEC provider for EC related functionality > requires jdk.crypto.ec; > - // 8153371 > - requires jdk.unsupported; > provides java.security.Provider with sun.security.pkcs11.SunPKCS11; > } > > Otherwise, looks fine to me. > > Xuelei > > On 4/16/2016 8:13 AM, Valerie Peng wrote: >> NOTE: resend with the correct bug id. >> >> Anyone can help reviewing this? Just a one-line replacement for >> switching to the new public Thread constructor. >> No new regression test as it should be covered by the existing one. >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8153371/webrev.00/ >> >> Thanks, >> Valerie From xuelei.fan at oracle.com Sat Apr 16 00:51:23 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 16 Apr 2016 08:51:23 +0800 Subject: RFR: [9]: 8154382: Remove intermittent keyword from SupportedDSAParamGen.java In-Reply-To: <571180B6.6090103@oracle.com> References: <571180B6.6090103@oracle.com> Message-ID: <57118C8B.1000109@oracle.com> It's OK to me to remove this keyword at present. Note that this test case may be slow on some testing circumstances, and run into timeout intermittently. Xuelei On 4/16/2016 8:00 AM, Rajan Halade wrote: > Please review following patch to remove intermittent keyword from this > test. Test has never seen to fail intermittently. > > diff -r 8606d027b2c2 > test/sun/security/provider/DSA/SupportedDSAParamGen.java > --- a/test/sun/security/provider/DSA/SupportedDSAParamGen.java Fri Apr > 15 16:19:15 2016 +0100 > +++ b/test/sun/security/provider/DSA/SupportedDSAParamGen.java Fri Apr > 15 16:58:04 2016 -0700 > @@ -24,7 +24,6 @@ > /* > * @test > * @bug 8072452 > - * @key intermittent > * @summary Support DHE sizes up to 8192-bits and DSA sizes up to > 3072-bits > * @run main/timeout=300 SupportedDSAParamGen 1024 160 > * @run main/timeout=300 SupportedDSAParamGen 2048 224 > > Thanks, > Rajan From chris.hegarty at oracle.com Sat Apr 16 08:06:26 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 16 Apr 2016 09:06:26 +0100 Subject: RFR 8153371: Remove sun.misc.ManagedLocalsThread from jdk.crypto.pkcs11 In-Reply-To: <571185B7.5090002@oracle.com> References: <57117F22.7090804@oracle.com> <571183A3.5020300@oracle.com> <571185B7.5090002@oracle.com> Message-ID: <55762C93-D514-42AD-BB6B-2B6A51B20B95@oracle.com> The changes in the webrev, along with the change to the module info, look good to me. -Chris. > On 16 Apr 2016, at 01:22, Xuelei Fan wrote: > > Resend. > > Looks like there jdk.crypto.pkcs11 has no dependence on jdk.unsupported > any more. Do you want to update the module-info.java in this update? > > module jdk.crypto.pkcs11 { > // Depends on SunEC provider for EC related functionality > requires jdk.crypto.ec; > - // 8153371 > - requires jdk.unsupported; > provides java.security.Provider with sun.security.pkcs11.SunPKCS11; > } > > Otherwise, looks fine to me. > > Xuelei > >> On 4/16/2016 8:13 AM, Valerie Peng wrote: >> NOTE: resend with the correct bug id. >> >> Anyone can help reviewing this? Just a one-line replacement for >> switching to the new public Thread constructor. >> No new regression test as it should be covered by the existing one. >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8153371/webrev.00/ >> >> Thanks, >> Valerie > From sean.mullan at oracle.com Mon Apr 18 13:44:52 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 18 Apr 2016 09:44:52 -0400 Subject: RFR 8077360: Lower the number of providers created when using ServiceLoader In-Reply-To: <5711829C.4040003@oracle.com> References: <5711829C.4040003@oracle.com> Message-ID: <5714E4D4.9060300@oracle.com> Looks good to me. --Sean On 04/15/2016 08:09 PM, Valerie Peng wrote: > Hi Sean, > > Not sure if you have reviewed this or not as you were on vacation while > Mandy and Alan reviewed this prototype fix for Jigsaw workspace earlier. > Now that the relevant Jigsaw code have been merged into JDK, I plan to > integrate this fix into JDK workspace instead. > > I verified the fixes by manually checking the number of Provider created > by going through the security debugging output. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8077360 > Webrev: http://cr.openjdk.java.net/~valeriep/8077360/webrev.00/ > > Thanks, > Valerie From anthony.scarpino at oracle.com Mon Apr 18 19:15:00 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 18 Apr 2016 12:15:00 -0700 Subject: RFR 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions In-Reply-To: <570D4F0B.50307@oracle.com> References: <56D477F3.9030802@oracle.com> <570BC9E7.4020806@oracle.com> <570D4F0B.50307@oracle.com> Message-ID: <57153234.6080005@oracle.com> Comments addressed in: http://cr.openjdk.java.net/~ascarpino/webrev.04/ Tony On 04/12/2016 12:39 PM, Sean Mullan wrote: > On 04/11/2016 11:59 AM, Anthony Scarpino wrote: >> I believe I have addressed all previous comments and some changes were >> made to rename cacerts to jdkCA and how it works AnchorCertificates.java >> >> http://cr.openjdk.java.net/~ascarpino/8140422/webrev.03/ > > * CertConstraintParameters > > 31 * This class is a wrapper for keeping state and passing objects > betweenPKIX, > > s/betweenPKIX/between PKIX/ > > * AnchorCertificates > > The comments on lines 40-44 need to be updated now that you have changed > the implementation. Also you don't really need the surrounding double > quotes. > > --Sean > > >> >> Tony >> >> On 02/29/2016 08:55 AM, Anthony Scarpino wrote: >>> I need a code review of this change: >>> >>> http://cr.openjdk.java.net/~ascarpino/8140422/webrev/ >>> >>> Currently CertPath algorithm restrictions allow or deny all >>> certificates. This change adds the ability to reject certificate chains >>> that contain a restricted algorithm and the chain terminates at a root >>> CA; therefore, allowing a self-signed or chain that does not terminate >>> at a root CA. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8140422 >>> >>> Thanks >>> >>> Tony >>> >> From xuelei.fan at oracle.com Tue Apr 19 04:34:49 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 19 Apr 2016 12:34:49 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> Message-ID: <5715B569.4080404@oracle.com> Two minor comments about the spec. 1. DrbgParameters.Capability The spec for each enum item is not very clear. Please add more comments about the meaning and behavior of each item. 2. DrbgParameters.Instantiate Looks like this class would be better to an extendable individual class. Declare this class as "static final" may limit it extension. Further more, if you add a public construct (the same as DrbgParameters.instantiate()), this class may be not necessary to be wrapped in DrbgParameters. DrbgParameters { public static final class Instantiate implements SecureRandomParameters; public static Instantiate instantiate(int strength, Capability capability, byte[] personalizationString); } -> Public class DrbgInstantiateParameters { public DrbgInstantiateParameters(int, Capability, byte[]); ... } Similar comments to NextBytes and Reseed. If classes Instantiate, NextBytes and Reseed are not wrapped in DrbgParameters, you may not need DrbgParameters any more. Otherwise, the spec looks fine to me. Xuelei On 4/15/2016 9:35 PM, Wang Weijun wrote: > Hi All > > Webrev updated again at > > http://cr.openjdk.java.net/~weijun/8051408/webrev.10/ > http://cr.openjdk.java.net/~weijun/8051408/webrev.10/spec > http://cr.openjdk.java.net/~weijun/8051408/webrev.10/specdiff > > Changes since webrev.09: > > 1. The first line in DrbgParameters: > > - * This class specifies the parameters used by a DRBG. > + * This class specifies the parameters used by a DRBG (Deterministic > + * Random Bit Generator). > > 2. Two new methods for DrbgParameters$Capability: > > public boolean supportsReseeding(); > public boolean supportsPredictionResistance(); > > So you will be able to write > > drbg = SecureRandom.getInstance("DRBG"); > > SecureRandomParameters params = drbg.getParameters(); > if (params instanceof DrbgParameters.Instantiate) { > DrbgParameters.Instantiate ins = (DrbgParameters.Instantiate) params; > if (ins.getCapability().supportsReseeding()) { > drbg.reseed(); > } > } > > 3. More descriptive text in exception thrown. > > Thanks > Max > > > >> On Apr 5, 2016, at 10:34 AM, Wang Weijun wrote: >> >> Updated webrev again at >> >> http://cr.openjdk.java.net/~weijun/8051408/webrev.09/ >> http://cr.openjdk.java.net/~weijun/8051408/webrev.09/spec >> http://cr.openjdk.java.net/~weijun/8051408/webrev.09/specdiff >> >> The only change is that SecureRandomInstantiateParameters, SecureRandomNextBytesParameters and SecureRandomReseedParameters are removed and only a single SecureRandomParameters is added. There seems no reason to introduce 3 marker interfaces. >> >> Thanks >> Max > From weijun.wang at oracle.com Tue Apr 19 08:05:39 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 19 Apr 2016 16:05:39 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <5715B569.4080404@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <5715B569.4080404@oracle.com> Message-ID: > On Apr 19, 2016, at 12:34 PM, Xuelei Fan wrote: > > Two minor comments about the spec. > > 1. DrbgParameters.Capability > The spec for each enum item is not very clear. Please add more comments > about the meaning and behavior of each item. OK. I probably should move the text in DrbgParameters$Instantiate#getCapability here. > > 2. DrbgParameters.Instantiate > Looks like this class would be better to an extendable individual class. > Declare this class as "static final" may limit it extension. NIST SP 800-90A&C are quite clear on what parameters are required for a DRBG. If some implementation really wants to add more parameters, it can implement SecureRandomParameters directly as a new type. In fact, SUN's DRBG uses this technique to pass in the configuration details encoded in the "drbg" security property. In fact, if you extend DrbgParameters.Instantiate and call getInstance("drbg", params), another implementation may hijack your params even if it does not understand the extra parameters. So I suppose you will only call getInstance("drbg", params, yourProvider), then why care about using a common base class? Also, it would make documenting SecureRandom#getParameters a little more complex. Should it return the new type or only return the base type? > > Further more, if you add a public construct (the same as > DrbgParameters.instantiate()), this class may be not necessary to be > wrapped in DrbgParameters. > > DrbgParameters { > public static final class Instantiate > implements SecureRandomParameters; > public static Instantiate instantiate(int strength, > Capability capability, byte[] personalizationString); > } > > -> > Public class DrbgInstantiateParameters { > public DrbgInstantiateParameters(int, Capability, byte[]); > ... > } > > Similar comments to NextBytes and Reseed. > > If classes Instantiate, NextBytes and Reseed are not wrapped in > DrbgParameters, you may not need DrbgParameters any more. A constructor is not very useful for a final class. The reason I put them into one compilation unit (is that the correct word?) is that I don't want to pollute the java.security package too much. DRBG is only one kind of SecureRandom. I know after compiled they will be different classes but putting the source code in one place makes me more comfortable. Thanks Max > > Otherwise, the spec looks fine to me. > > Xuelei > > On 4/15/2016 9:35 PM, Wang Weijun wrote: >> Hi All >> >> Webrev updated again at >> >> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/ >> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/spec >> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/specdiff >> >> Changes since webrev.09: >> >> 1. The first line in DrbgParameters: >> >> - * This class specifies the parameters used by a DRBG. >> + * This class specifies the parameters used by a DRBG (Deterministic >> + * Random Bit Generator). >> >> 2. Two new methods for DrbgParameters$Capability: >> >> public boolean supportsReseeding(); >> public boolean supportsPredictionResistance(); >> >> So you will be able to write >> >> drbg = SecureRandom.getInstance("DRBG"); >> >> SecureRandomParameters params = drbg.getParameters(); >> if (params instanceof DrbgParameters.Instantiate) { >> DrbgParameters.Instantiate ins = (DrbgParameters.Instantiate) params; >> if (ins.getCapability().supportsReseeding()) { >> drbg.reseed(); >> } >> } >> >> 3. More descriptive text in exception thrown. >> >> Thanks >> Max >> >> >> >>> On Apr 5, 2016, at 10:34 AM, Wang Weijun wrote: >>> >>> Updated webrev again at >>> >>> http://cr.openjdk.java.net/~weijun/8051408/webrev.09/ >>> http://cr.openjdk.java.net/~weijun/8051408/webrev.09/spec >>> http://cr.openjdk.java.net/~weijun/8051408/webrev.09/specdiff >>> >>> The only change is that SecureRandomInstantiateParameters, SecureRandomNextBytesParameters and SecureRandomReseedParameters are removed and only a single SecureRandomParameters is added. There seems no reason to introduce 3 marker interfaces. >>> >>> Thanks >>> Max >> > From weijun.wang at oracle.com Tue Apr 19 08:08:00 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 19 Apr 2016 16:08:00 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <5715B569.4080404@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <5715B569.4080404@oracle.com> Message-ID: > On Apr 19, 2016, at 12:34 PM, Xuelei Fan wrote: > > Two minor comments about the spec. > > 1. DrbgParameters.Capability > The spec for each enum item is not very clear. Please add more comments > about the meaning and behavior of each item. OK. I probably should move the text in DrbgParameters$Instantiate#getCapability here. > > 2. DrbgParameters.Instantiate > Looks like this class would be better to an extendable individual class. > Declare this class as "static final" may limit it extension. NIST SP 800-90A&C are quite clear on what parameters are required for a DRBG. If some implementation really wants to add more parameters, it can implement SecureRandomParameters directly as a new type. In fact, SUN's DRBG uses this technique to pass in the configuration details encoded in the "drbg" security property. In fact, if you extend DrbgParameters.Instantiate and call getInstance("drbg", params), another implementation may hijack your params even if it does not understand the extra parameters. So I suppose you will only call getInstance("drbg", params, yourProvider), then why care about using a common base class? Also, it would make documenting SecureRandom#getParameters a little more complex. Should it return the new type or only return the base type? > > Further more, if you add a public construct (the same as > DrbgParameters.instantiate()), this class may be not necessary to be > wrapped in DrbgParameters. > > DrbgParameters { > public static final class Instantiate > implements SecureRandomParameters; > public static Instantiate instantiate(int strength, > Capability capability, byte[] personalizationString); > } > > -> > Public class DrbgInstantiateParameters { > public DrbgInstantiateParameters(int, Capability, byte[]); > ... > } > > Similar comments to NextBytes and Reseed. > > If classes Instantiate, NextBytes and Reseed are not wrapped in > DrbgParameters, you may not need DrbgParameters any more. A constructor is not very useful for a final class. The reason I put them into one compilation unit (is that the correct word?) is that I don't want to pollute the java.security package too much. DRBG is only one kind of SecureRandom. I know after compiled they will be different classes but putting the source code in one place makes me more comfortable. Thanks Max > > Otherwise, the spec looks fine to me. > > Xuelei > > On 4/15/2016 9:35 PM, Wang Weijun wrote: >> Hi All >> >> Webrev updated again at >> >> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/ >> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/spec >> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/specdiff >> >> Changes since webrev.09: >> >> 1. The first line in DrbgParameters: >> >> - * This class specifies the parameters used by a DRBG. >> + * This class specifies the parameters used by a DRBG (Deterministic >> + * Random Bit Generator). >> >> 2. Two new methods for DrbgParameters$Capability: >> >> public boolean supportsReseeding(); >> public boolean supportsPredictionResistance(); >> >> So you will be able to write >> >> drbg = SecureRandom.getInstance("DRBG"); >> >> SecureRandomParameters params = drbg.getParameters(); >> if (params instanceof DrbgParameters.Instantiate) { >> DrbgParameters.Instantiate ins = (DrbgParameters.Instantiate) params; >> if (ins.getCapability().supportsReseeding()) { >> drbg.reseed(); >> } >> } >> >> 3. More descriptive text in exception thrown. >> >> Thanks >> Max >> >> >> >>> On Apr 5, 2016, at 10:34 AM, Wang Weijun wrote: >>> >>> Updated webrev again at >>> >>> http://cr.openjdk.java.net/~weijun/8051408/webrev.09/ >>> http://cr.openjdk.java.net/~weijun/8051408/webrev.09/spec >>> http://cr.openjdk.java.net/~weijun/8051408/webrev.09/specdiff >>> >>> The only change is that SecureRandomInstantiateParameters, SecureRandomNextBytesParameters and SecureRandomReseedParameters are removed and only a single SecureRandomParameters is added. There seems no reason to introduce 3 marker interfaces. >>> >>> Thanks >>> Max >> > From michael.osipov at siemens.com Tue Apr 19 09:05:37 2016 From: michael.osipov at siemens.com (Osipov, Michael) Date: Tue, 19 Apr 2016 09:05:37 +0000 Subject: JGSS fails with KrbException: Message stream modified (41) on cross-realm intermediate/unexpected TGT Message-ID: <68644224DA0DE64CA5A49838ED219A0425B43D8E@DEFTHW99EJ5MSX.ww902.siemens.net> Hi, I am trying to obtain a service ticket for a cross-realm service within one hierarchy (forest). The root realm is COMPANY.NET, my realm is R004.COMPANY.NET, target realm is R002.COMPANY.NET and SPN ldap/server.r002.company.net. Host to realm mapping in my krb5.conf: [domain_realm] .r004.company.net = R004.COMPANY.NET r004.company.net = R004.COMPANY.NET .company.net = COMPANY.NET company.net = COMPANY.NET I have tested the same case with MIT Kerberos and SSPI and both have a completely different approach of requesting service tickets. They do: TGS-REQ for ldap/server.r002.company.net to a KDC in my home realm TGS-REP is krbtgt/r002.company.net at R004.COMPANY.NET TGS-REQ for ldap/server.r002.company.net to a KDC in R002.COMPANY.NET with krbtgt/r002.company.net at R004.COMPANY.NET TGS-REP is ldap/server.r002.company.net at WW002.SIEMENS.NET This works as desired. JGSS in turn does this: Match hostname to domain realm => COMPANY.NET TGS-REQ for krbtgt/COMPANY.NET TGS-REP is krbtgt/company.net at R004.COMPANY.NET TGS-REQ for ldap/server.r002.company.net to a KDC in COMPANY.NET with krbtgt/company.net at R004.COMPANY.NET TGS-REP is krbtgt/r002.company.net at COMPANY.NET and here happens the crash KrbException: Message stream modified (41) KrbException: Fail to create credential. (63) - No service creds at sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:299) at sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454) at sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179) in KrbKdcRep.java#check(), lines 54 to 56: if (!req.reqBody.sname.equalsWithoutRealm(rep.encKDCRepPart.sname)) { rep.encKDCRepPart.key.destroy(); throw new KrbApErrException(Krb5.KRB_AP_ERR_MODIFIED); } This code assumes that the ticket is already the final service ticket but it is an intermediate TGT for the target realm. I would expect another TGS-REQ/TGS-REP from JGSS. Due to the logic implemented, the only known workaround is to add another [domain_realm] mapping but this is daunting because we have tens of those and I do not know all realms/hostnames upfront due to dynamic TGT referrals. Another case is HTTP proxy (HTTP/proxyfarm.company.net). JGSS requests at COMPANY.NET but receives a TGT for R002.COMPANY.NET. Especially in this case, I am not able to know the realm upfront. Adding the domain realm mapping does not help because this file is used initially only or even worse, direct hostname to realm mapping is hell. Removing [domain_realm] makes it immediately fail due to the TGT referral. MIT Kerberos follows all TGT referrals as necessary. The manpage for krb5.conf for [domain_realm] says: "If no translation entry applies to a hostname used for a service principal for a service ticket request, the library will try to get a referral to the appropriate realm from the client realm's KDC..." I would expect that the TGS logic would resemble the one described above, follow all referrals until it gets the desired service ticket. Ultimately, not [domain_realm] is necessary, at least with MIT Kerberos and Active Directory. Setup: * KDCs are Windows Server 2008/2012 * Clients are Windows 7 Enterprise * MIT Kerberos 1.14.1 on FreeBSD * Oracle JDKs 1.7.0_72 and 1.80_72 All tests happen on Windows, deployment happens on HP-UX with HP JVM which is merely a repackaged Oracle JVM with native patches for that OS. I have already created a bundle with log files, krb5.conf and Wireshark pcap files, debug screenshots for JGSS, MIT Kerberos and SSPI and will happily share in private. Also willing to assist as necessary. This is actually an annoying blocker disabling us to use cross-domain and cross-forest services. I would prefer a solution for Java 7 because we haven't migrated to Java 8 yet but willing to do so. How can we resolve this issue? Thanks and regards, Michael Osipov From xuelei.fan at oracle.com Tue Apr 19 09:41:11 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 19 Apr 2016 17:41:11 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <5715B569.4080404@oracle.com> Message-ID: <5715FD37.3080404@oracle.com> On 4/19/2016 4:05 PM, Wang Weijun wrote: >> > 2. DrbgParameters.Instantiate >> > Looks like this class would be better to an extendable individual class. >> > Declare this class as "static final" may limit it extension. > NIST SP 800-90A&C are quite clear on what parameters are required for a DRBG. ;-) Yes, a spec should be clear about what parameter are required for a algorithm. > If some implementation really wants to add more parameters, it can implement SecureRandomParameters directly as a new type. I was wondering, the current APIs may not define all parameters the NIST SP 800-90A&C defined. I'm OK with the current design if the current APIs has already define all parameter the NIST defined, or you don't want to define other parameters and don't allow other provider implement other parameters at present. Please ignore the following comments if you decide go with the current design. > In fact, SUN's DRBG uses this technique to pass in the configuration details encoded in the "drbg" security property. > Can you explain more about what kind of hijack will happen? > In fact, if you extend DrbgParameters.Instantiate and call getInstance("drbg", params), another implementation may hijack your params even if it does not understand the extra parameters. So I suppose you will only call getInstance("drbg", params, yourProvider), then why care about using a common base class? > See previous comment. > Also, it would make documenting SecureRandom#getParameters a little more complex. Should it return the new type or only return the base type? > The provider implemented type should be returned. It's up to the provider to make the decision of the returned type (SecureRandomSpi.engineGetParameters). It is not necessary to return the object of the exactly DrbgParameters.Instantiate (can be a sub-class). >> > >> > Further more, if you add a public construct (the same as >> > DrbgParameters.instantiate()), this class may be not necessary to be >> > wrapped in DrbgParameters. >> > >> > DrbgParameters { >> > public static final class Instantiate >> > implements SecureRandomParameters; >> > public static Instantiate instantiate(int strength, >> > Capability capability, byte[] personalizationString); >> > } >> > >> > -> >> > Public class DrbgInstantiateParameters { >> > public DrbgInstantiateParameters(int, Capability, byte[]); >> > ... >> > } >> > >> > Similar comments to NextBytes and Reseed. >> > >> > If classes Instantiate, NextBytes and Reseed are not wrapped in >> > DrbgParameters, you may not need DrbgParameters any more. > A constructor is not very useful for a final class. > I cannot agree with you on this point. Final class need and can have constructors. > The reason I put them into one compilation unit (is that the correct word?) is that I don't want to pollute the java.security package too much. DRBG is only one kind of SecureRandom. I know after compiled they will be different classes but putting the source code in one place makes me more comfortable. > ;-) But you did pollute the package with one additional class. If you use DrbgParameters, there are five classes: DrbgParameters DrbgParameters.Instantiate DrbgParameters.NextBytes DrbgParameters.Reseed DrbgParameters.Capability If you don't define DrbgParameters, need four classes only. ;-) Less pollution, right? In the source code, they are put into one unit class. But in Java doc, they are not displayed individually. Anyway, minor comments. You can go with the current design, please let me know. Xuelei From weijun.wang at oracle.com Tue Apr 19 10:39:14 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 19 Apr 2016 18:39:14 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <5715FD37.3080404@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <5715B569.4080404@oracle.com> <5715FD37.3080404@oracle.com> Message-ID: > On Apr 19, 2016, at 5:41 PM, Xuelei Fan wrote: > > On 4/19/2016 4:05 PM, Wang Weijun wrote: >>>> 2. DrbgParameters.Instantiate >>>> Looks like this class would be better to an extendable individual class. >>>> Declare this class as "static final" may limit it extension. >> NIST SP 800-90A&C are quite clear on what parameters are required for a DRBG. > ;-) Yes, a spec should be clear about what parameter are required for a > algorithm. > >> If some implementation really wants to add more parameters, it can implement SecureRandomParameters directly as a new type. > I was wondering, the current APIs may not define all parameters the NIST > SP 800-90A&C defined. I'm OK with the current design if the current > APIs has already define all parameter the NIST defined, or you don't > want to define other parameters and don't allow other provider implement > other parameters at present. > > Please ignore the following comments if you decide go with the current > design. > >> In fact, SUN's DRBG uses this technique to pass in the configuration details encoded in the "drbg" security property. >> > Can you explain more about what kind of hijack will happen? If you call SecureRandom.getInstance("drbg", params) and params is an instance of YourInstantiate that extends DrbgP.Instantiate, the DRBG implementation inside SUN will accept it and be returned. I call this hijack, even if DRBG in SUN does not fully understand params. > >> In fact, if you extend DrbgParameters.Instantiate and call getInstance("drbg", params), another implementation may hijack your params even if it does not understand the extra parameters. So I suppose you will only call getInstance("drbg", params, yourProvider), then why care about using a common base class? >> > See previous comment. > >> Also, it would make documenting SecureRandom#getParameters a little more complex. Should it return the new type or only return the base type? >> > The provider implemented type should be returned. It's up to the > provider to make the decision of the returned type > (SecureRandomSpi.engineGetParameters). It is not necessary to return > the object of the exactly DrbgParameters.Instantiate (can be a sub-class). But if DRBG in SUN hijack the getInstance() call, it will not be able to return one. Finally, the new type is restricted to your own implementation in a single provider. > >>>> >>>> Further more, if you add a public construct (the same as >>>> DrbgParameters.instantiate()), this class may be not necessary to be >>>> wrapped in DrbgParameters. >>>> >>>> DrbgParameters { >>>> public static final class Instantiate >>>> implements SecureRandomParameters; >>>> public static Instantiate instantiate(int strength, >>>> Capability capability, byte[] personalizationString); >>>> } >>>> >>>> -> >>>> Public class DrbgInstantiateParameters { >>>> public DrbgInstantiateParameters(int, Capability, byte[]); >>>> ... >>>> } >>>> >>>> Similar comments to NextBytes and Reseed. >>>> >>>> If classes Instantiate, NextBytes and Reseed are not wrapped in >>>> DrbgParameters, you may not need DrbgParameters any more. >> A constructor is not very useful for a final class. >> > I cannot agree with you on this point. Final class need and can have > constructors. I should say it's no more useful than a static method. The functions are equivalent. > >> The reason I put them into one compilation unit (is that the correct word?) is that I don't want to pollute the java.security package too much. DRBG is only one kind of SecureRandom. I know after compiled they will be different classes but putting the source code in one place makes me more comfortable. >> > ;-) But you did pollute the package with one additional class. > > If you use DrbgParameters, there are five classes: > DrbgParameters > DrbgParameters.Instantiate > DrbgParameters.NextBytes > DrbgParameters.Reseed > DrbgParameters.Capability > > If you don't define DrbgParameters, need four classes only. ;-) Less > pollution, right? Well, n vs n+1 is not very different, but 1 vs n is not. :-) It depends how you look at this. From a user's perspective who is using an IDE, he only needs to type "DrbgParameters." and everything is shown to him. I also find it convenient to document all DRBG-related things in a single place. In fact, those general concepts and examples do not seem to fit any single class, but they look more natural in this "useless" DrbgParameters outer class. > > In the source code, they are put into one unit class. But in Java doc, > they are not displayed individually. > > Anyway, minor comments. You can go with the current design, please let > me know. I'd like to keep the current design. Thanks Max > > Xuelei From weijun.wang at oracle.com Tue Apr 19 10:50:03 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 19 Apr 2016 18:50:03 +0800 Subject: JGSS fails with KrbException: Message stream modified (41) on cross-realm intermediate/unexpected TGT In-Reply-To: <68644224DA0DE64CA5A49838ED219A0425B43D8E@DEFTHW99EJ5MSX.ww902.siemens.net> References: <68644224DA0DE64CA5A49838ED219A0425B43D8E@DEFTHW99EJ5MSX.ww902.siemens.net> Message-ID: If you are sure the exception is thrown from the code snippet you quoted, that is because Java's Kerberos 5 implementation requires that the service name in TGS_REP must match the one in the TGS_REQ. Otherwise it fails. MIT and SSPI support referral so the names can be different. The workaround you described is the only solution by now. --Max > On Apr 19, 2016, at 5:05 PM, Osipov, Michael wrote: > > Hi, > > I am trying to obtain a service ticket for a cross-realm service within one hierarchy (forest). > > The root realm is COMPANY.NET, my realm is R004.COMPANY.NET, target realm is R002.COMPANY.NET and > SPN ldap/server.r002.company.net. > > Host to realm mapping in my krb5.conf: > [domain_realm] > .r004.company.net = R004.COMPANY.NET > r004.company.net = R004.COMPANY.NET > .company.net = COMPANY.NET > company.net = COMPANY.NET > > I have tested the same case with MIT Kerberos and SSPI and both have a completely different approach > of requesting service tickets. They do: > > TGS-REQ for ldap/server.r002.company.net to a KDC in my home realm > TGS-REP is krbtgt/r002.company.net at R004.COMPANY.NET > TGS-REQ for ldap/server.r002.company.net to a KDC in R002.COMPANY.NET with > krbtgt/r002.company.net at R004.COMPANY.NET > TGS-REP is ldap/server.r002.company.net at WW002.SIEMENS.NET > > This works as desired. > > JGSS in turn does this: > Match hostname to domain realm => COMPANY.NET > TGS-REQ for krbtgt/COMPANY.NET > TGS-REP is krbtgt/company.net at R004.COMPANY.NET > TGS-REQ for ldap/server.r002.company.net to a KDC in COMPANY.NET with > krbtgt/company.net at R004.COMPANY.NET > TGS-REP is krbtgt/r002.company.net at COMPANY.NET > and here happens the crash > KrbException: Message stream modified (41) > KrbException: Fail to create credential. (63) - No service creds > at sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:299) > at sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454) > at sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641) > at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248) > at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179) > in KrbKdcRep.java#check(), lines 54 to 56: > if (!req.reqBody.sname.equalsWithoutRealm(rep.encKDCRepPart.sname)) { > rep.encKDCRepPart.key.destroy(); > throw new KrbApErrException(Krb5.KRB_AP_ERR_MODIFIED); > } > > This code assumes that the ticket is already the final service ticket but it is an intermediate TGT > for the target realm. I would expect another TGS-REQ/TGS-REP from JGSS. Due to the logic implemented, > the only known workaround is to add another [domain_realm] mapping but this is daunting because we have > tens of those and I do not know all realms/hostnames upfront due to dynamic TGT referrals. > > Another case is HTTP proxy (HTTP/proxyfarm.company.net). JGSS requests at COMPANY.NET but > receives a TGT for R002.COMPANY.NET. Especially in this case, I am not able to know the realm upfront. > Adding the domain realm mapping does not help because this file is used initially only or even worse, > direct hostname to realm mapping is hell. Removing [domain_realm] makes it immediately fail due to > the TGT referral. MIT Kerberos follows all TGT referrals as necessary. > > The manpage for krb5.conf for [domain_realm] says: > "If no translation entry applies to a hostname used for a service principal for a service ticket request, > the library will try to get a referral to the appropriate realm from the client realm's KDC..." > > I would expect that the TGS logic would resemble the one described above, follow all referrals until > it gets the desired service ticket. Ultimately, not [domain_realm] is necessary, at least with MIT Kerberos > and Active Directory. > > Setup: > * KDCs are Windows Server 2008/2012 > * Clients are Windows 7 Enterprise > * MIT Kerberos 1.14.1 on FreeBSD > * Oracle JDKs 1.7.0_72 and 1.80_72 > > All tests happen on Windows, deployment happens on HP-UX with HP JVM which is merely a repackaged Oracle > JVM with native patches for that OS. > > I have already created a bundle with log files, krb5.conf and Wireshark pcap files, debug screenshots for > JGSS, MIT Kerberos and SSPI and will happily share in private. Also willing to assist as necessary. > > This is actually an annoying blocker disabling us to use cross-domain and cross-forest services. I would > prefer a solution for Java 7 because we haven't migrated to Java 8 yet but willing to do so. > > How can we resolve this issue? > > Thanks and regards, > > Michael Osipov > From michael.osipov at siemens.com Tue Apr 19 11:06:53 2016 From: michael.osipov at siemens.com (Osipov, Michael) Date: Tue, 19 Apr 2016 11:06:53 +0000 Subject: JGSS fails with KrbException: Message stream modified (41) on cross-realm intermediate/unexpected TGT In-Reply-To: References: <68644224DA0DE64CA5A49838ED219A0425B43D8E@DEFTHW99EJ5MSX.ww902.siemens.net> Message-ID: <68644224DA0DE64CA5A49838ED219A0425B43E67@DEFTHW99EJ5MSX.ww902.siemens.net> Hi Max, > If you are sure the exception is thrown from the code snippet you quoted, > that is because Java's Kerberos 5 implementation requires that the service > name in TGS_REP must match the one in the TGS_REQ. Otherwise it fails. I am quite certain, I have attached the OpenJDK code in Eclipse an stepped to this spot. It exactly happens and you say. It does not match. > MIT and SSPI support referral so the names can be different. > > The workaround you described is the only solution by now. Are there any plans to add referral support? Can we log this issue in bugs.openjdk.java.net/browse/JDK? As I have written, the workaround is feasible in few cases only. Not having referral support makes JGSS hardly usable in a big enterprise environment. Disappointing :-( Anyway thanks for the quick response and confirmation of the issue. Michael > > On Apr 19, 2016, at 5:05 PM, Osipov, Michael > wrote: > > > > Hi, > > > > I am trying to obtain a service ticket for a cross-realm service within > one hierarchy (forest). > > > > The root realm is COMPANY.NET, my realm is R004.COMPANY.NET, target > realm is R002.COMPANY.NET and > > SPN ldap/server.r002.company.net. > > > > Host to realm mapping in my krb5.conf: > > [domain_realm] > > .r004.company.net = R004.COMPANY.NET > > r004.company.net = R004.COMPANY.NET > > .company.net = COMPANY.NET > > company.net = COMPANY.NET > > > > I have tested the same case with MIT Kerberos and SSPI and both have a > completely different approach > > of requesting service tickets. They do: > > > > TGS-REQ for ldap/server.r002.company.net to a KDC in my home realm > > TGS-REP is krbtgt/r002.company.net at R004.COMPANY.NET > > TGS-REQ for ldap/server.r002.company.net to a KDC in R002.COMPANY.NET > with > > krbtgt/r002.company.net at R004.COMPANY.NET > > TGS-REP is ldap/server.r002.company.net at WW002.SIEMENS.NET > > > > This works as desired. > > > > JGSS in turn does this: > > Match hostname to domain realm => COMPANY.NET > > TGS-REQ for krbtgt/COMPANY.NET > > TGS-REP is krbtgt/company.net at R004.COMPANY.NET > > TGS-REQ for ldap/server.r002.company.net to a KDC in COMPANY.NET with > > krbtgt/company.net at R004.COMPANY.NET > > TGS-REP is krbtgt/r002.company.net at COMPANY.NET > > and here happens the crash > > KrbException: Message stream modified (41) > > KrbException: Fail to create credential. (63) - No service creds > > at > sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(Credentials > Util.java:299) > > at > sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:454) > > at > sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641) > > at > sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248) > > at > sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179) > > in KrbKdcRep.java#check(), lines 54 to 56: > > if (!req.reqBody.sname.equalsWithoutRealm(rep.encKDCRepPart.sname)) > { > > rep.encKDCRepPart.key.destroy(); > > throw new KrbApErrException(Krb5.KRB_AP_ERR_MODIFIED); > > } > > > > This code assumes that the ticket is already the final service ticket > but it is an intermediate TGT > > for the target realm. I would expect another TGS-REQ/TGS-REP from JGSS. > Due to the logic implemented, > > the only known workaround is to add another [domain_realm] mapping but > this is daunting because we have > > tens of those and I do not know all realms/hostnames upfront due to > dynamic TGT referrals. > > > > Another case is HTTP proxy (HTTP/proxyfarm.company.net). JGSS requests > at COMPANY.NET but > > receives a TGT for R002.COMPANY.NET. Especially in this case, I am not > able to know the realm upfront. > > Adding the domain realm mapping does not help because this file is used > initially only or even worse, > > direct hostname to realm mapping is hell. Removing [domain_realm] makes > it immediately fail due to > > the TGT referral. MIT Kerberos follows all TGT referrals as necessary. > > > > The manpage for krb5.conf for [domain_realm] says: > > "If no translation entry applies to a hostname used for a service > principal for a service ticket request, > > the library will try to get a referral to the appropriate realm from the > client realm's KDC..." > > > > I would expect that the TGS logic would resemble the one described > above, follow all referrals until > > it gets the desired service ticket. Ultimately, not [domain_realm] is > necessary, at least with MIT Kerberos > > and Active Directory. > > > > Setup: > > * KDCs are Windows Server 2008/2012 > > * Clients are Windows 7 Enterprise > > * MIT Kerberos 1.14.1 on FreeBSD > > * Oracle JDKs 1.7.0_72 and 1.80_72 > > > > All tests happen on Windows, deployment happens on HP-UX with HP JVM > which is merely a repackaged Oracle > > JVM with native patches for that OS. > > > > I have already created a bundle with log files, krb5.conf and Wireshark > pcap files, debug screenshots for > > JGSS, MIT Kerberos and SSPI and will happily share in private. Also > willing to assist as necessary. > > > > This is actually an annoying blocker disabling us to use cross-domain > and cross-forest services. I would > > prefer a solution for Java 7 because we haven't migrated to Java 8 yet > but willing to do so. > > > > How can we resolve this issue? > > > > Thanks and regards, > > > > Michael Osipov > > From xuelei.fan at oracle.com Tue Apr 19 11:39:24 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 19 Apr 2016 19:39:24 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <5715B569.4080404@oracle.com> <5715FD37.3080404@oracle.com> Message-ID: <571618EC.1010309@oracle.com> On 4/19/2016 6:39 PM, Wang Weijun wrote: >> > Anyway, minor comments. You can go with the current design, please let >> > me know. > I'd like to keep the current design. OK. Let's move on with the current design. Thanks, Xuelei From weijun.wang at oracle.com Tue Apr 19 12:37:29 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 19 Apr 2016 20:37:29 +0800 Subject: JGSS fails with KrbException: Message stream modified (41) on cross-realm intermediate/unexpected TGT In-Reply-To: <68644224DA0DE64CA5A49838ED219A0425B43E67@DEFTHW99EJ5MSX.ww902.siemens.net> References: <68644224DA0DE64CA5A49838ED219A0425B43D8E@DEFTHW99EJ5MSX.ww902.siemens.net> <68644224DA0DE64CA5A49838ED219A0425B43E67@DEFTHW99EJ5MSX.ww902.siemens.net> Message-ID: > > Are there any plans to add referral support? Not yet. > Can we log this issue in bugs.openjdk.java.net/browse/JDK? You can always do that, but such a feature should be covered by a JEP. --Max From michael.osipov at siemens.com Tue Apr 19 12:48:32 2016 From: michael.osipov at siemens.com (Osipov, Michael) Date: Tue, 19 Apr 2016 12:48:32 +0000 Subject: JGSS fails with KrbException: Message stream modified (41) on cross-realm intermediate/unexpected TGT In-Reply-To: References: <68644224DA0DE64CA5A49838ED219A0425B43D8E@DEFTHW99EJ5MSX.ww902.siemens.net> <68644224DA0DE64CA5A49838ED219A0425B43E67@DEFTHW99EJ5MSX.ww902.siemens.net> Message-ID: <68644224DA0DE64CA5A49838ED219A0425B43EDF@DEFTHW99EJ5MSX.ww902.siemens.net> > > Are there any plans to add referral support? > > Not yet. > > > Can we log this issue in bugs.openjdk.java.net/browse/JDK? > > You can always do that, but such a feature should be covered by a JEP. Only JDK devs have write access. All I can do is a bug report with http://bugreport.java.com/. A JEP can probably initiated by you or your colleagues. Even if, this probably won't make it into Java 9. In the meantime, can this be documented someone in the official docs of Oracle? Michael From xuelei.fan at oracle.com Tue Apr 19 13:09:57 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 19 Apr 2016 21:09:57 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> Message-ID: <57162E25.4090805@oracle.com> On 4/15/2016 9: > http://cr.openjdk.java.net/~weijun/8051408/webrev.10/ Please update copyright dates. src/java.base/share/classes/java/security/Provider.java ------------------------------------------------------- 145-151: Looks like the comment are not correct. There are getInstance(alg,params) since JDK 1.4 (See CertStore) 156-157: Fallback change the behavior significantly. Construct with or without parameter can be very differently. For example, LDAP cert store get requested, but the CertStore.getInstane(String, LDAPCertStoreParameters) may not return an LDAP cert store. Can you make more comment why the fallback is OK? src/java.base/share/classes/java/security/SecureRandom.java ----------------------------------------------------------- 456 SecureRandomSpi spi = (SecureRandomSpi) instance.impl; 457 SecureRandom r = new SecureRandom(spi, instance.provider, algorithm); 458 return r; 456, there is a whitespace of the casting. The compiler may optimize the code, but I may use the old style as line 401-402. Similar comment for 507-510, 553-556. 477 - secureRandomSpi.engineNextBytes(bytes); 667 + secureRandomSpi.engineNextBytes( 668 + Objects.requireNonNull(bytes)); Some provider may tolerant null bytes input (for example SunPKCS11). Please consider this update more for compatibility. src/java.base/share/classes/java/security/SecureRandomSpi.java -------------------------------------------------------------- 124 throw new UnsupportedOperationException("not supported"); 156 throw new UnsupportedOperationException("not supported"); I would like to use no-parameter exception, or more specific message. 174 @Override 175 public String toString() { 176 return getClass().getSimpleName(); 177 } What's the usage of this new toString() method? Review the DRBG impl later. Thanks, Xuelei From weijun.wang at oracle.com Tue Apr 19 15:11:32 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 19 Apr 2016 08:11:32 -0700 (PDT) Subject: JGSS fails with KrbException: Message stream modified (41) on cross-realm intermediate/unexpected TGT In-Reply-To: <68644224DA0DE64CA5A49838ED219A0425B43EDF@DEFTHW99EJ5MSX.ww902.siemens.net> References: <68644224DA0DE64CA5A49838ED219A0425B43D8E@DEFTHW99EJ5MSX.ww902.siemens.net> <68644224DA0DE64CA5A49838ED219A0425B43E67@DEFTHW99EJ5MSX.ww902.siemens.net> <68644224DA0DE64CA5A49838ED219A0425B43EDF@DEFTHW99EJ5MSX.ww902.siemens.net> Message-ID: <30A35706-7708-42D1-901E-3D015699B9C9@oracle.com> > On Apr 19, 2016, at 8:48 PM, Osipov, Michael wrote: > >>> Are there any plans to add referral support? >> >> Not yet. >> >>> Can we log this issue in bugs.openjdk.java.net/browse/JDK? >> >> You can always do that, but such a feature should be covered by a JEP. > > Only JDK devs have write access. All I can do is a bug report with > http://bugreport.java.com/. A JEP can probably initiated by you or your > colleagues. Even if, this probably won't make it into Java 9. There is another bug https://bugs.openjdk.java.net/browse/JDK-6631053 which is about referral for client. I've just added a comment on server and cross-realm routing. > In the meantime, can this be documented someone in the official docs > of Oracle? The documentation for Kerberos in Java is at http://download.java.net/jdk9/docs/technotes/guides/security/jgss/jgss-api-mechanism.html It has not listed RFC 6806. --Max > > Michael From weijun.wang at oracle.com Tue Apr 19 15:41:59 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 19 Apr 2016 08:41:59 -0700 (PDT) Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <57162E25.4090805@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> Message-ID: <37C74246-DDE9-4DD1-ABB0-9D7B916CC7B6@oracle.com> > On Apr 19, 2016, at 9:09 PM, Xuelei Fan wrote: > > On 4/15/2016 9: >> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/ > > Please update copyright dates. > > src/java.base/share/classes/java/security/Provider.java > ------------------------------------------------------- > 145-151: Looks like the comment are not correct. There are > getInstance(alg,params) since JDK 1.4 (See CertStore) Yes, but in those cases, there is either getInstance(alg) or getInstance(alg,params), but not both. In SecureRandom, we are now supporting both, and a fallback is needed for those implementations that does not override new SecureRandomSpi(SRP). > > 156-157: Fallback change the behavior significantly. Construct with or > without parameter can be very differently. For example, LDAP cert store > get requested, but the CertStore.getInstane(String, > LDAPCertStoreParameters) may not return an LDAP cert store. Can you > make more comment why the fallback is OK? For CertStore (and Configuration and Policy), all of its implementations only support the with-arg constructor, so NoSuchMethodException will never be thrown. Again, this fallback is only for SecureRandom now. > > src/java.base/share/classes/java/security/SecureRandom.java > ----------------------------------------------------------- > 456 SecureRandomSpi spi = (SecureRandomSpi) instance.impl; > 457 SecureRandom r = new SecureRandom(spi, instance.provider, > algorithm); > 458 return r; > > 456, there is a whitespace of the casting. Will remove. > > The compiler may optimize the code, but I may use the old style as line > 401-402. > > Similar comment for 507-510, 553-556. You mean inline and remove the spi variable? Sure I can. > > 477 - secureRandomSpi.engineNextBytes(bytes); > 667 + secureRandomSpi.engineNextBytes( > 668 + Objects.requireNonNull(bytes)); > Some provider may tolerant null bytes input (for example SunPKCS11). > Please consider this update more for compatibility. Oh, then this will be unspecified. I'll think about it. > > > src/java.base/share/classes/java/security/SecureRandomSpi.java > -------------------------------------------------------------- > 124 throw new UnsupportedOperationException("not supported"); > 156 throw new UnsupportedOperationException("not supported"); > > I would like to use no-parameter exception, or more specific message. No params. > > 174 @Override > 175 public String toString() { > 176 return getClass().getSimpleName(); > 177 } > What's the usage of this new toString() method? Testing and debugging. For DRBG, it returns a text like the "drbg" security property. Thanks Max > > > Review the DRBG impl later. > > Thanks, > Xuelei > > > From michael.osipov at siemens.com Tue Apr 19 20:35:02 2016 From: michael.osipov at siemens.com (Osipov, Michael) Date: Tue, 19 Apr 2016 20:35:02 +0000 Subject: JGSS fails with KrbException: Message stream modified (41) on cross-realm intermediate/unexpected TGT In-Reply-To: <30A35706-7708-42D1-901E-3D015699B9C9@oracle.com> References: <68644224DA0DE64CA5A49838ED219A0425B43D8E@DEFTHW99EJ5MSX.ww902.siemens.net> <68644224DA0DE64CA5A49838ED219A0425B43E67@DEFTHW99EJ5MSX.ww902.siemens.net> <68644224DA0DE64CA5A49838ED219A0425B43EDF@DEFTHW99EJ5MSX.ww902.siemens.net> <30A35706-7708-42D1-901E-3D015699B9C9@oracle.com> Message-ID: <68644224DA0DE64CA5A49838ED219A0425B44024@DEFTHW99EJ5MSX.ww902.siemens.net> > > On Apr 19, 2016, at 8:48 PM, Osipov, Michael > wrote: > > > >>> Are there any plans to add referral support? > >> > >> Not yet. > >> > >>> Can we log this issue in bugs.openjdk.java.net/browse/JDK? > >> > >> You can always do that, but such a feature should be covered by a JEP. > > > > Only JDK devs have write access. All I can do is a bug report with > > http://bugreport.java.com/. A JEP can probably initiated by you or your > > colleagues. Even if, this probably won't make it into Java 9. > > There is another bug https://bugs.openjdk.java.net/browse/JDK-6631053 > which is about referral for client. I've just added a comment on server > and cross-realm routing. I know this ticket and it does not describe what you think. This has nothing to do with canonicalize in KdcOptions and it won't solve the problem. Just tried that option on MIT Kerberos, no avail. This option applies to client principals only and is useful when you perform kinit with an enterprise principal. Back to the issue, in short, if you receive an LDAP referral from Active Directory, the URL contains not a hostname but a naming context name. For such a NC name does not exist a SPN, Kerberos will fail. Additional steps need to be taken to make it work. I am currently assessing how I can sovle this for us, because this is AD-specific. Of course, Oracle's support in extending their LDAP implementation would be awesome. If you'd like to know more about this, see [1] and [2]. > > In the meantime, can this be documented someone in the official docs > > of Oracle? > > The documentation for Kerberos in Java is at > > http://download.java.net/jdk9/docs/technotes/guides/security/jgss/jgss- > api-mechanism.html > > It has not listed RFC 6806. Exactly, that's the RFC I am talking about. Thank you for bringing this up. People once in while ask for client referrals on Stack Overflow [3], I'd rather see server referrals. Anyway, if you think that you or someone else will pick up this RFC, I'd be more than happy to test that. I have three forests, tens of domains to test and thousands of SPNs to test. Michael [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040347.html [2] http://tomcatspnegoad.sf.net/referral-handling [3] http://stackoverflow.com/q/34398114/696632 From xuelei.fan at oracle.com Tue Apr 19 23:41:43 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 19 Apr 2016 16:41:43 -0700 (PDT) Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <37C74246-DDE9-4DD1-ABB0-9D7B916CC7B6@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <37C74246-DDE9-4DD1-ABB0-9D7B916CC7B6@oracle.com> Message-ID: <5716C237.10704@oracle.com> On 4/19/2016 11:41 PM, Wang Weijun wrote: >>> >> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/ >> > >> > Please update copyright dates. >> > >> > src/java.base/share/classes/java/security/Provider.java >> > ------------------------------------------------------- >> > 145-151: Looks like the comment are not correct. There are >> > getInstance(alg,params) since JDK 1.4 (See CertStore) > Yes, but in those cases, there is either getInstance(alg) or getInstance(alg,params), but not both. In SecureRandom, we are now supporting both, and a fallback is needed for those implementations that does not override new SecureRandomSpi(SRP). > >> > >> > 156-157: Fallback change the behavior significantly. Construct with or >> > without parameter can be very differently. For example, LDAP cert store >> > get requested, but the CertStore.getInstane(String, >> > LDAPCertStoreParameters) may not return an LDAP cert store. Can you >> > make more comment why the fallback is OK? > For CertStore (and Configuration and Policy), all of its implementations only support the with-arg constructor, I think the constructor is not of CertStore, but of CertStoreSpi implementation. The provider implementation may support any kind of constructor (implicit or explicit, intended or not). The constructor should be unknown to Provider. > so NoSuchMethodException will never be thrown. Again, this fallback is only for SecureRandom now. > > Please add more comment and control so that this only apply to SecureRandom. Thanks, Xuelei From bradford.wetmore at oracle.com Wed Apr 20 00:54:42 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 19 Apr 2016 17:54:42 -0700 (PDT) Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> Message-ID: <5716D352.1020008@oracle.com> > Webrev updated again at > > http://cr.openjdk.java.net/~weijun/8051408/webrev.10/ > http://cr.openjdk.java.net/~weijun/8051408/webrev.10/spec > http://cr.openjdk.java.net/~weijun/8051408/webrev.10/specdiff Some initial comments. security/java.security ====================== 123-133: Would you consider changing the ordering of the algorithm names to be consistent between the two sections? Say: NativePRNG, SHA1PRNG, and DRBG. 175: Should we add DRBG:SUN as a backup for non-windows? 181: # NIST SP 800-90Ar1 lists several DRBG mechanisms, each can be configured with -> # NIST SP 800-90Ar1 lists several DRBG mechanisms. Each can be configured with 184: request of "DRBG" SecureRandom implemented in the SUN provider. -> request of "DRBG" SecureRandom implementations in the SUN provider. (Other DRBG implementations might also use this property.) 188: Can you adjust the line lengths so it looks polished, and not edited in place? I use a vi macro (using fmt) for this. 189: Do you want to add "currently", or leave as is? names are not configurable -> names are not currently configurable 194: Am I missing something? is a slash-separated list -> is a comma-separated list 198: Should we add a short 1-liner description for the fields? The variable meanings (esp pr/df) may not be obvious to a casual observer. For example, using these three fields as an example: mech_name: default "Hash_DRBG" "Hash_DRBG" | "HMAC_DRBG" | "CTR_DRBG" + The DRBG mechanism to use. pr: default "none" "pr_and_reseed" | "reseed_only" | "none" + Prediction resistance... df: default "use_df", only applicable to CTR_DRBG "use_df" | "no_df" + Derivation Function... 210: Instead of pointing to 800-90A here, you should instead point to the Sun Provider document. That document will then reference 800-90A/Section 10, and will use the Standard Algorithm names that you have defined for these algorithms. (I assume you'll be adding those to the standard algorithm name doc, right? I don't recall seeing that part of the review yet, but maybe haven't gotten that far.) 214: In the past, we've used spaces as a field separator for names in a provider, I'm wondering if we should make this name something like "3KeyTDEA" instead? 229: I hadn't noticed this before, but the Security variable "drbg" doesn't match the style of the other variables, securerandom.* or otherwise. I think we should use something like either: securerandom.drbg securerandom.drbg.config 229: Why an empty string here? Why not actually specify the default here instead of burying the default somewhere where it might changed without a corresponding update to this file? Thanks, Brad From weijun.wang at oracle.com Wed Apr 20 01:17:17 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 20 Apr 2016 09:17:17 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <5716C237.10704@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <37C74246-DDE9-4DD1-ABB0-9D7B916CC7B6@oracle.com> <5716C237.10704@oracle.com> Message-ID: <67FC7133-4D9D-438E-BF3A-7A1CA14DCAF3@oracle.com> > On Apr 20, 2016, at 7:41 AM, Xuelei Fan wrote: > > On 4/19/2016 11:41 PM, Wang Weijun wrote: >>>>>> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/ >>>> >>>> Please update copyright dates. >>>> >>>> src/java.base/share/classes/java/security/Provider.java >>>> ------------------------------------------------------- >>>> 145-151: Looks like the comment are not correct. There are >>>> getInstance(alg,params) since JDK 1.4 (See CertStore) >> Yes, but in those cases, there is either getInstance(alg) or getInstance(alg,params), but not both. In SecureRandom, we are now supporting both, and a fallback is needed for those implementations that does not override new SecureRandomSpi(SRP). >> >>>> >>>> 156-157: Fallback change the behavior significantly. Construct with or >>>> without parameter can be very differently. For example, LDAP cert store >>>> get requested, but the CertStore.getInstane(String, >>>> LDAPCertStoreParameters) may not return an LDAP cert store. Can you >>>> make more comment why the fallback is OK? >> For CertStore (and Configuration and Policy), all of its implementations only support the with-arg constructor, > I think the constructor is not of CertStore, but of CertStoreSpi > implementation. Yes. > The provider implementation may support any kind of > constructor (implicit or explicit, intended or not). The constructor > should be unknown to Provider. Not sure what you mean, but Provider uses reflection to get the constructor and create new instances. By convention, when something is created via getInstance(alg), the SPI class would provide the arg-less constructor; when via getInstance(alg,params), it would provide the with-arg constructor. > >> so NoSuchMethodException will never be thrown. Again, this fallback is only for SecureRandom now. >> >> > Please add more comment and control so that this only apply to SecureRandom. It already had "This is to support the enhanced SecureRandom". Thanks Max > > Thanks, > Xuelei From xuelei.fan at oracle.com Wed Apr 20 01:35:14 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 20 Apr 2016 09:35:14 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <67FC7133-4D9D-438E-BF3A-7A1CA14DCAF3@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <37C74246-DDE9-4DD1-ABB0-9D7B916CC7B6@oracle.com> <5716C237.10704@oracle.com> <67FC7133-4D9D-438E-BF3A-7A1CA14DCAF3@oracle.com> Message-ID: <5716DCD2.5050007@oracle.com> On 4/20/2016 9:17 AM, Wang Weijun wrote: > >> On Apr 20, 2016, at 7:41 AM, Xuelei Fan wrote: >> >> On 4/19/2016 11:41 PM, Wang Weijun wrote: >>>>>>> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/ >>>>> >>>>> Please update copyright dates. >>>>> >>>>> src/java.base/share/classes/java/security/Provider.java >>>>> ------------------------------------------------------- >>>>> 145-151: Looks like the comment are not correct. There are >>>>> getInstance(alg,params) since JDK 1.4 (See CertStore) >>> Yes, but in those cases, there is either getInstance(alg) or getInstance(alg,params), but not both. In SecureRandom, we are now supporting both, and a fallback is needed for those implementations that does not override new SecureRandomSpi(SRP). >>> >>>>> >>>>> 156-157: Fallback change the behavior significantly. Construct with or >>>>> without parameter can be very differently. For example, LDAP cert store >>>>> get requested, but the CertStore.getInstane(String, >>>>> LDAPCertStoreParameters) may not return an LDAP cert store. Can you >>>>> make more comment why the fallback is OK? >>> For CertStore (and Configuration and Policy), all of its implementations only support the with-arg constructor, >> I think the constructor is not of CertStore, but of CertStoreSpi >> implementation. > > Yes. > >> The provider implementation may support any kind of >> constructor (implicit or explicit, intended or not). The constructor >> should be unknown to Provider. > > Not sure what you mean, but Provider uses reflection to get the constructor and create new instances. By convention, when something is created via getInstance(alg), the SPI class would provide the arg-less constructor; when via getInstance(alg,params), it would provide the with-arg constructor. > Not sure what you mean. public MyCertStore extends CertStoreSpi { public MyCertStore() { // whatever // ;-) Don't ask me why this construct is necessary. } public MyCertStore(XXX params) { // throws NoSuchMethodException // ;-) Don't ask me why throw this exception. } } newInstanceUtil(MyCertStore, ...) The MyCertStore() would get called, unexpectly. Am I missing something? >> >>> so NoSuchMethodException will never be thrown. Again, this fallback is only for SecureRandom now. >>> >>> >> Please add more comment and control so that this only apply to SecureRandom. > > It already had "This is to support the enhanced SecureRandom". > My understanding is: this is to support the enhanced SecureRandom, and it now applies to non-SecureRandom too. If it does not apply to non-SecureRandom, please add comment and update the code accordingly. Xuelei From weijun.wang at oracle.com Wed Apr 20 01:41:55 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 20 Apr 2016 09:41:55 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <5716D352.1020008@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <5716D352.1020008@oracle.com> Message-ID: > On Apr 20, 2016, at 8:54 AM, Bradford Wetmore wrote: > > > Webrev updated again at > > > > http://cr.openjdk.java.net/~weijun/8051408/webrev.10/ > > http://cr.openjdk.java.net/~weijun/8051408/webrev.10/spec > > http://cr.openjdk.java.net/~weijun/8051408/webrev.10/specdiff > > Some initial comments. > > security/java.security > ====================== > 123-133: Would you consider changing the ordering of the algorithm > names to be consistent between the two sections? Say: > > NativePRNG, SHA1PRNG, and DRBG. Sure. > > 175: Should we add DRBG:SUN as a backup for non-windows? If NativePRNGBlocking:SUN is not always available, yes we can. > > 181: > # NIST SP 800-90Ar1 lists several DRBG mechanisms, each can be configured with > -> > # NIST SP 800-90Ar1 lists several DRBG mechanisms. Each can be configured with > > 184: > request of "DRBG" SecureRandom implemented in the SUN provider. > -> > request of "DRBG" SecureRandom implementations in the SUN provider. > (Other DRBG implementations might also use this property.) OK. > > 188: Can you adjust the line lengths so it looks polished, and not > edited in place? I use a vi macro (using fmt) for this. OK. > > 189: Do you want to add "currently", or leave as is? > names are not configurable > -> > names are not currently configurable Yes. > > 194: Am I missing something? > is a slash-separated list > -> > is a comma-separated list Oops, will correct. > > 198: Should we add a short 1-liner description for the fields? The > variable meanings (esp pr/df) may not be obvious to a casual observer. > For example, using these three fields as an example: > > mech_name: default "Hash_DRBG" > "Hash_DRBG" | "HMAC_DRBG" | "CTR_DRBG" > > + The DRBG mechanism to use. > > pr: default "none" > "pr_and_reseed" | "reseed_only" | "none" > > + Prediction resistance... > > df: default "use_df", only applicable to CTR_DRBG > "use_df" | "no_df" > > + Derivation Function... Not sure about the format, how about # # The DRBG mechanism to use. default "Hash_DRBG" # mech_name: # "Hash_DRBG" | "HMAC_DRBG" | "CTR_DRBG" So this is double comment. Please note I also put the default value into the comment. > > 210: Instead of pointing to 800-90A here, you should instead point to > the Sun Provider document. That document will then reference > 800-90A/Section 10, and will use the Standard Algorithm names that > you have defined for these algorithms. (I assume you'll be adding > those to the standard algorithm name doc, right? I don't recall seeing > that part of the review yet, but maybe haven't gotten that far.) Yes, I will. The standard algorithm name is only "DRBG", but here it's the DRBG algorithm name (SHA-256 etc). Are we going to talk about this in Sun Provider doc? > > 214: In the past, we've used spaces as a field separator for names in > a provider, I'm wondering if we should make this name something like > "3KeyTDEA" instead? OK. > > 229: I hadn't noticed this before, but the Security variable "drbg" > doesn't match the style of the other variables, securerandom.* or > otherwise. I think we should use something like either: > > securerandom.drbg > securerandom.drbg.config Will choose "securerandom.drbg.config". > > 229: Why an empty string here? Why not actually specify the default here > instead of burying the default somewhere where it might changed without > a corresponding update to this file? There is a small technical issue here. The problem is that the default value of algorithm_name depends on mech_name, and the default value of strength depends on algorithm_name. If we set "Hash_DRBG,SHA-256,128" here and we only change one of them, another one might be illegal. For example, if I want to create a SecureRandom using MoreDrbgParameters (yes, this is an internal class) with SecureRandom.getInstance("drbg", new MoreDrbgParameters( null, "CTR_DRBG", "3KeyTDEA", null, false, DrbgParameters.instantiate(-1, NONE, null))) it will fail, because with -1 in DrbgParameters.instantiate(), the new configuration will look like CTR_DRBG,3KeyTDEA,128 but CTR_DRBG,3KeyTDEA does not support 128 bit strength. I will have to use DrbgParameters.instantiate(112, NONE, null) but that does not looks comfortable because I thought the system can give me a default working strength. This won't be a problem if only public API is used, but I will have to redo some implementation codes. Thanks Max > > Thanks, > Brad > From weijun.wang at oracle.com Wed Apr 20 03:01:10 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 19 Apr 2016 20:01:10 -0700 (PDT) Subject: JGSS fails with KrbException: Message stream modified (41) on cross-realm intermediate/unexpected TGT In-Reply-To: <68644224DA0DE64CA5A49838ED219A0425B44024@DEFTHW99EJ5MSX.ww902.siemens.net> References: <68644224DA0DE64CA5A49838ED219A0425B43D8E@DEFTHW99EJ5MSX.ww902.siemens.net> <68644224DA0DE64CA5A49838ED219A0425B43E67@DEFTHW99EJ5MSX.ww902.siemens.net> <68644224DA0DE64CA5A49838ED219A0425B43EDF@DEFTHW99EJ5MSX.ww902.siemens.net> <30A35706-7708-42D1-901E-3D015699B9C9@oracle.com> <68644224DA0DE64CA5A49838ED219A0425B44024@DEFTHW99EJ5MSX.ww902.siemens.net> Message-ID: <48A427B9-C82B-48F8-A566-6BF4BB6C4267@oracle.com> > On Apr 20, 2016, at 4:35 AM, Osipov, Michael wrote: > >> >> It has not listed RFC 6806. > > Exactly, that's the RFC I am talking about. Thank you for bringing this up. > People once in while ask for client referrals on Stack Overflow [3], I'd > rather see server referrals. Anyway, if you think that you or someone else > will pick up this RFC, I'd be more than happy to test that. I have three > forests, tens of domains to test and thousands of SPNs to test. Thanks in advance. Once we decide to do this, we will file a JEP. Thanks Max > > Michael > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040347.html > [2] http://tomcatspnegoad.sf.net/referral-handling > [3] http://stackoverflow.com/q/34398114/696632 From xuelei.fan at oracle.com Wed Apr 20 03:34:59 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 19 Apr 2016 20:34:59 -0700 (PDT) Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <57162E25.4090805@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> Message-ID: <5716F8E3.8030006@oracle.com> On 4/19/2016 9:09 PM, Xuelei Fan wrote: > On 4/15/2016 9: >> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/ src/java.base/share/classes/sun/security/provider/AbstractDrbg.java =================================================================== line 66-68: My understanding is that ... I would suggest rewords or remove this sentence. "Not used much" does not mean needing no synchronization. As you have add synchronized keyword for engineGenerateSeed, I may suggest you remove lines 63-68, and move 57-61 to class description. I think comment are mainly used for code readers. You used a lot "my" and "I", and questions to yourself in the comments. Would you mind change to use neutral tones and remove unnecessary comments in the final code? ------ 662 // 6/7. Get entropy. TODO: 1st arg security strength? Do you want to complete the TODO task. Similar comments to other TODO tasks. ------ 670 nonce = longToByteArray(cc.incrementAndGet()); 685 private static byte[] longToByteArray(long l) The nonce is leading with "sun.drbg", and following by a 8-bytes integer value. This scheme only provider 8-bytes randomness. Looks like the quality does not meet the nonce requirements (8.7.6 NIST SP-800-90Ar1) for 256-bit strength. ------ 598 protected final synchronized void engineConfigure( engineConfigure is not part of SPI. Would you mind change the name and remove the leading "engine" in case of miss-understanding? It would be nice grant as less accessibility as possible. For the "protected" keyword, should it be package accessibility at present? Similar comment for other protected methods other than the override ones, and some public classes in the package. ------ Section 7.2 of NIST SP 800-90Ar1 says: "The personalization string should be unique for all instantiations of the same DRBG mechanism type". Please check the unique for the personalization string in the implementation. Looking forward to your next webrev. Xuelei From weijun.wang at oracle.com Wed Apr 20 04:00:55 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 20 Apr 2016 12:00:55 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <5716F8E3.8030006@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <5716F8E3.8030006@oracle.com> Message-ID: <8522950F-11B1-41EC-972C-5F9C8B24D6CE@oracle.com> > On Apr 20, 2016, at 11:34 AM, Xuelei Fan wrote: > > On 4/19/2016 9:09 PM, Xuelei Fan wrote: >> On 4/15/2016 9: >>> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/ > > src/java.base/share/classes/sun/security/provider/AbstractDrbg.java > =================================================================== > line 66-68: My understanding is that ... > > I would suggest rewords or remove this sentence. "Not used much" does > not mean needing no synchronization. Of course. Precisely engineNextBytes() should synchronize on both states and configuration, and engineGenerateSeed() should synchronize only on configuration. But since engineGenerateSeed() is not used a lot, I don't think it's not worth coding it with a special synchronize(configuration) so both now just synchronize on "this". > As you have add synchronized > keyword for engineGenerateSeed, I may suggest you remove lines 63-68, > and move 57-61 to class description. I'll move 57-61 to class description, and would like to keep 63-68 there, and update the words "does not need to be synchronized" to "does not need to be synchronized on the internal states". > > I think comment are mainly used for code readers. You used a lot "my" > and "I", and questions to yourself in the comments. Would you mind > change to use neutral tones and remove unnecessary comments in the final > code? OK. > > ------ > 662 // 6/7. Get entropy. TODO: 1st arg security strength? > > Do you want to complete the TODO task. Similar comments to other TODO > tasks. Will remove TODO word and add a clarification. > > ------ > 670 nonce = longToByteArray(cc.incrementAndGet()); > 685 private static byte[] longToByteArray(long l) > > The nonce is leading with "sun.drbg", and following by a 8-bytes integer > value. This scheme only provider 8-bytes randomness. Looks like the > quality does not meet the nonce requirements (8.7.6 NIST SP-800-90Ar1) > for 256-bit strength. 8.6.7 allows it to be a "monotonically increased sequence number". > > ------ > 598 protected final synchronized void engineConfigure( > > engineConfigure is not part of SPI. Would you mind change the name and > remove the leading "engine" in case of miss-understanding? s/engineConfigure/configure/ > > It would be nice grant as less accessibility as possible. For the > "protected" keyword, should it be package accessibility at present? > Similar comment for other protected methods other than the override > ones, and some public classes in the package. Will go through them. I created AbstractDrbg so that it can be the base for any DRBG not necessarily in this package. For example, the AbstractDrbgSpec test also contains an implementation. > > ------ > Section 7.2 of NIST SP 800-90Ar1 says: "The personalization string > should be unique for all instantiations of the same DRBG mechanism type". > > Please check the unique for the personalization string in the > implementation. "Should" is not "shall" (section 4, terms). Two other reasons: 1. Checking for uniqueness needs to save all strings in memory. 2. The default is null, and all nulls are the same. Why bother checking for those non-nulls for uniqueness? Thanks Max > > Looking forward to your next webrev. > > Xuelei > > From xuelei.fan at oracle.com Wed Apr 20 04:53:15 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 20 Apr 2016 12:53:15 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <8522950F-11B1-41EC-972C-5F9C8B24D6CE@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <5716F8E3.8030006@oracle.com> <8522950F-11B1-41EC-972C-5F9C8B24D6CE@oracle.com> Message-ID: <57170B3B.4020303@oracle.com> On 4/20/2016 12:00 PM, Wang Weijun wrote: > >> On Apr 20, 2016, at 11:34 AM, Xuelei Fan wrote: >> >> On 4/19/2016 9:09 PM, Xuelei Fan wrote: >>> On 4/15/2016 9: >>>> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/ >> >> src/java.base/share/classes/sun/security/provider/AbstractDrbg.java >> =================================================================== >> ------ >> 670 nonce = longToByteArray(cc.incrementAndGet()); >> 685 private static byte[] longToByteArray(long l) >> >> The nonce is leading with "sun.drbg", and following by a 8-bytes integer >> value. This scheme only provider 8-bytes randomness. Looks like the >> quality does not meet the nonce requirements (8.7.6 NIST SP-800-90Ar1) >> for 256-bit strength. > > 8.6.7 allows it to be a "monotonically increased sequence number". > I don't think it means you can downgrade the strength. 8-byte integer value may wrap and is not monotonically increased. A sequence number does not limited to 8-bytes integer. It can be unlimited. >> ------ >> Section 7.2 of NIST SP 800-90Ar1 says: "The personalization string >> should be unique for all instantiations of the same DRBG mechanism type". >> >> Please check the unique for the personalization string in the >> implementation. > > "Should" is not "shall" (section 4, terms). "should" is recommended. Better to adhere to. > Two other reasons: > > 1. Checking for uniqueness needs to save all strings in memory. > I see, but you need to find a smart solution. Add some randomness, or make some checking. It may be a security issue if you don't check the unique. > 2. The default is null, and all nulls are the same. Why bother checking for those non-nulls for uniqueness? > null is special. If "entropy+nonce+null" is safe, "entropy+nonce+'constant'" may be problematic for some crypto operation. Xuelei From sean.mullan at oracle.com Wed Apr 20 13:10:49 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 20 Apr 2016 09:10:49 -0400 Subject: Code Review Request 8144566, Custom HostnameVerifier disables SNI extension In-Reply-To: <5705932F.7030901@oracle.com> References: <56642AD3.6010904@oracle.com> <56662275.5000007@oracle.com> <5666C93E.6010306@oracle.com> <569EDF8A.5000603@oracle.com> <5705932F.7030901@oracle.com> Message-ID: <57177FD9.3080004@oracle.com> * SSLSocketImpl.java 2100 // ONLY used by ClientHandshaker for the server hostname during handshaling typo: handshaking 2114 synchronized private void useImplicitHost(boolean noSniUpdate) { the modifier order should be "private synchronized ..." See: http://cr.openjdk.java.net/~alundblad/styleguide/#toc-modifiers 2115 if ((host != null) && (host.length() != 0)) { 2116 return; 2117 } This seems redundant. You already check this before you call the method. 2150 // No explicitly specified hostname, no sserver name indication. typo: server 2610 if (sniNames.isEmpty()) { 2611 // need no SNI extension 2612 noSniExtension = true; 2613 } // Otherwise, need not to set noSniExtension 2614 Could write more compactly as: noSniExtension = sniNames.isEmpty(); same comment on lines 2620-4 * BestEffortOnLazyConnected.java, ImpactOnSNI.java 2 * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. 2016 I know this is just a test, but it seems like most of these methods and fields should be private. --Sean On 04/06/2016 06:52 PM, Xuelei Fan wrote: > Ping ... > > On 1/20/2016 9:14 AM, Xuelei Fan wrote: >> Ping ... >> >> On 12/8/2015 8:12 PM, Xuelei Fan wrote: >>> Good catch! >>> >>> I copied the comment here: >>> >>> ---------- >>> SocketFactory sslsf = SSLSocketFactory.getDefault(); >>> SSLSocket ssls = (SSLSocket) sslsf.createSocket(); >>> ssls.connect(new InetSocketAddress( >>> "bugs.openjdk.java.net", 443), 0); >>> ssls.startHandshake(); >>> >>> No SNI is sent in this case. >>> ---------- >>> >>> Although this is not a regression, but this is a very good catch. >>> >>> However, I don't think the code path is a best practice, as the actual >>> behavior depends on providers behaviors and platform behaviors too much. >>> I would recommend to use SSLParameters.setServerNames() to specify the >>> server names explicitly. >>> >>> But, best effort should be made for the default server names for such >>> code paths. Here is the webrev that also fixes this code path issue: >>> >>> http://cr.openjdk.java.net/~xuelei/8144566/webrev.01/ >>> >>> The fix gets a little bit complicated because of the need to consider >>> the SSLParameters.setServerNames() impact in the code path: >>> >>> SSLSocket ssls = (SSLSocket) sslsf.createSocket(); >>> >>> // before the connection, need to consider the impact: >>> // Get the SSLParameters from the socket, or create on the fly? >>> // Call ssls.setSSLParameters(params) or not? >>> ssls.connect(socketAddress); >>> >>> // after the connection, need to consider the impact: >>> // Call ssls.setSSLParameters(params) or not? >>> >>> Basically, the implementation honors the server name set by >>> SSLParameters.setServerNames(). >>> >>> Bernd's comment: >>>> Isnt this codepath used as a workaround for dynamically disabling >>>> SNI? Using connect(host..) instead of SSLSocket(host) was at >>>> least a common, well known workaround. >>> If the code path is really used in practice, the >>> SSLParameters.setServerNames() would better be called actually to >>> disable SNI explicitly. >>> >>> SocketFactory sslsf = SSLSocketFactory.getDefault(); >>> SSLSocket ssls = (SSLSocket) sslsf.createSocket(); >>> ssls.connect(new InetSocketAddress( >>> "bugs.openjdk.java.net", 443), 0); >>> sslParameters.setServerNames(emptyList); >>> ssls.setSSLParameters(sslParameters); >>> ssls.startHandshake(); >>> >>> Thank you, Bernd and Brad, for the feedback. >>> >>> Thanks, >>> Xuelei >>> >>> On 12/8/2015 8:21 AM, Bradford Wetmore wrote: >>>> >>>> Please see my comment in the bug. I haven't verified this, but it seems >>>> the problem might be generic to the codepath through SSLSocket, not just >>>> Https. >>>> >>>> Brad >>>> >>>> >>>> >>>> >>>> >>>> On 12/6/2015 4:32 AM, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> Please review the update for JDK-8144566: >>>>> >>>>> http://cr.openjdk.java.net/~xuelei/8144566/webrev.00/ >>>>> >>>>> For HttpsURLConnection, the server name may be set after the TLS >>>>> connection and handshake has been initialized. As may result in that >>>>> the server name does not present at TLS ClientHello messages. >>>>> >>>>> This fix resets the server name for the initialized handshake for above >>>>> cases. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>> >> > From weijun.wang at oracle.com Wed Apr 20 14:14:00 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 20 Apr 2016 22:14:00 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <57170B3B.4020303@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <5716F8E3.8030006@oracle.com> <8522950F-11B1-41EC-972C-5F9C8B24D6CE@oracle.com> <57170B3B.4020303@oracle.com> Message-ID: <0F1A5368-6FD4-4E25-B280-330ED7259658@oracle.com> > On Apr 20, 2016, at 12:53 PM, Xuelei Fan wrote: > > On 4/20/2016 12:00 PM, Wang Weijun wrote: >> >>> On Apr 20, 2016, at 11:34 AM, Xuelei Fan wrote: >>> >>> On 4/19/2016 9:09 PM, Xuelei Fan wrote: >>>> On 4/15/2016 9: >>>>> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/ >>> >>> src/java.base/share/classes/sun/security/provider/AbstractDrbg.java >>> =================================================================== > >>> ------ >>> 670 nonce = longToByteArray(cc.incrementAndGet()); >>> 685 private static byte[] longToByteArray(long l) >>> >>> The nonce is leading with "sun.drbg", and following by a 8-bytes integer >>> value. This scheme only provider 8-bytes randomness. Looks like the >>> quality does not meet the nonce requirements (8.7.6 NIST SP-800-90Ar1) >>> for 256-bit strength. >> >> 8.6.7 allows it to be a "monotonically increased sequence number". >> > I don't think it means you can downgrade the strength. 8-byte integer > value may wrap and is not monotonically increased. A sequence number > does not limited to 8-bytes integer. It can be unlimited. Really? You are worried about more than 2^64 instances of DRBG? How about System.currentMillis() and an increasing long together in 16 bytes? I know currentMillis will also wrap but please. > >>> ------ >>> Section 7.2 of NIST SP 800-90Ar1 says: "The personalization string >>> should be unique for all instantiations of the same DRBG mechanism type". >>> >>> Please check the unique for the personalization string in the >>> implementation. >> >> "Should" is not "shall" (section 4, terms). > "should" is recommended. Better to adhere to. > >> Two other reasons: >> >> 1. Checking for uniqueness needs to save all strings in memory. >> > I see, but you need to find a smart solution. Add some randomness, or > make some checking. It may be a security issue if you don't check the > unique. I cannot add any randomness. Personalization string is provided by a user and I don't think I cannot modify it. So if we want to make it unique, it will be a requirement of users to make it unique. I don't want to enforce this because I don't think users have the capability to make it unique. Finally nobody will use a personalization string. 8.7.1 has more description on personalization strings, and it "is not considered to be a critical security parameter". > >> 2. The default is null, and all nulls are the same. Why bother checking for those non-nulls for uniqueness? >> > null is special. If "entropy+nonce+null" is safe, > "entropy+nonce+'constant'" may be problematic for some crypto operation. I'm not sure of this. Thanks Max > > Xuelei > From weijun.wang at oracle.com Wed Apr 20 14:27:52 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 20 Apr 2016 22:27:52 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <8522950F-11B1-41EC-972C-5F9C8B24D6CE@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <5716F8E3.8030006@oracle.com> <8522950F-11B1-41EC-972C-5F9C8B24D6CE@oracle.com> Message-ID: > On Apr 20, 2016, at 12:00 PM, Wang Weijun wrote: > >> src/java.base/share/classes/sun/security/provider/AbstractDrbg.java >> =================================================================== >> line 66-68: My understanding is that ... >> >> I would suggest rewords or remove this sentence. "Not used much" does >> not mean needing no synchronization. > > Of course. > > Precisely engineNextBytes() should synchronize on both states and configuration, and engineGenerateSeed() should synchronize only on configuration. But since engineGenerateSeed() is not used a lot, I don't think it's not worth coding it with a special synchronize(configuration) so both now just synchronize on "this". > >> As you have add synchronized >> keyword for engineGenerateSeed, I may suggest you remove lines 63-68, >> and move 57-61 to class description. > > I'll move 57-61 to class description, and would like to keep 63-68 there, and update the words "does not need to be synchronized" to "does not need to be synchronized on the internal states". I rethink about this and decide to make a big change. Instead of from its own entropy source (in most cases just another DRBG), AbstractDrbg#engineGenerateSeed will read from SeedGenerator (the ultimate entropy source of all DRBGs) directly. Thus it is totally unrelated to this DRBG and the synchronized modifier will be removed. 63-68 will go too. This is modeled after SHA1PRNG. Thanks Max From weijun.wang at oracle.com Wed Apr 20 14:58:36 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 20 Apr 2016 22:58:36 +0800 Subject: RFR: 8154231: Simplify access to System properties from JDK code In-Reply-To: <571795C8.2010007@oracle.com> References: <571795C8.2010007@oracle.com> Message-ID: <15E99E17-D462-4578-9A34-58055F9F69D6@oracle.com> This is quite convenient. We not cover the other modules? exports sun.security.action to java.desktop, java.security.jgss, jdk.crypto.pkcs11; Thanks Max > On Apr 20, 2016, at 10:44 PM, Claes Redestad wrote: > > Hello, > > now that the sun.security.action package is encapsulated we can simplify internal code to get System properties. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154231 > Webrev: http://cr.openjdk.java.net/~redestad/8154231/webrev.01/ > > This adds a few convenience methods to GetPropertyAction[1] and GetIntegerAction[2]. Since the code calling into this can be streamlined, this leads to a net static footprint reduction of the java.base module and a tiny startup improvement. > > Thanks! > > /Claes > > [1] http://cr.openjdk.java.net/~redestad/8154231/webrev.01/src/java.base/share/classes/sun/security/action/GetPropertyAction.java.udiff.html > [2] http://cr.openjdk.java.net/~redestad/8154231/webrev.01/src/java.base/share/classes/sun/security/action/GetIntegerAction.java.udiff.html From xuelei.fan at oracle.com Wed Apr 20 15:13:31 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 20 Apr 2016 23:13:31 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <0F1A5368-6FD4-4E25-B280-330ED7259658@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <5716F8E3.8030006@oracle.com> <8522950F-11B1-41EC-972C-5F9C8B24D6CE@oracle.com> <57170B3B.4020303@oracle.com> <0F1A5368-6FD4-4E25-B280-330ED7259658@oracle.com> Message-ID: <57179C9B.1070904@oracle.com> On 4/20/2016 10:14 PM, Wang Weijun wrote: > >> On Apr 20, 2016, at 12:53 PM, Xuelei Fan wrote: >> >> On 4/20/2016 12:00 PM, Wang Weijun wrote: >>> >>>> On Apr 20, 2016, at 11:34 AM, Xuelei Fan wrote: >>>> >>>> On 4/19/2016 9:09 PM, Xuelei Fan wrote: >>>>> On 4/15/2016 9: >>>>>> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/ >>>> >>>> src/java.base/share/classes/sun/security/provider/AbstractDrbg.java >>>> =================================================================== >> >>>> ------ >>>> 670 nonce = longToByteArray(cc.incrementAndGet()); >>>> 685 private static byte[] longToByteArray(long l) >>>> >>>> The nonce is leading with "sun.drbg", and following by a 8-bytes integer >>>> value. This scheme only provider 8-bytes randomness. Looks like the >>>> quality does not meet the nonce requirements (8.7.6 NIST SP-800-90Ar1) >>>> for 256-bit strength. >>> >>> 8.6.7 allows it to be a "monotonically increased sequence number". >>> >> I don't think it means you can downgrade the strength. 8-byte integer >> value may wrap and is not monotonically increased. A sequence number >> does not limited to 8-bytes integer. It can be unlimited. > > Really? You are worried about more than 2^64 instances of DRBG? > SSL/TLS considers record sequence number wrapping, too. The nonce require at least half-strength randomness, I would like to follow this requirement. > How about System.currentMillis() and an increasing long together in 16 bytes? I know currentMillis will also wrap but please. > I may use a 16 bytes array ( 16 * 8 * 2 = 256), and increase for each acquire. See sun.security.ssl.Authenticator.acquireAuthenticationBytes(). > >> >>>> ------ >>>> Section 7.2 of NIST SP 800-90Ar1 says: "The personalization string >>>> should be unique for all instantiations of the same DRBG mechanism type". >>>> >>>> Please check the unique for the personalization string in the >>>> implementation. >>> >>> "Should" is not "shall" (section 4, terms). >> "should" is recommended. Better to adhere to. >> >>> Two other reasons: >>> >>> 1. Checking for uniqueness needs to save all strings in memory. >>> >> I see, but you need to find a smart solution. Add some randomness, or >> make some checking. It may be a security issue if you don't check the >> unique. > > I cannot add any randomness. Personalization string is provided by a user and I don't think I cannot modify it. > cannot->can? > So if we want to make it unique, it will be a requirement of users to make it unique. I don't want to enforce this because I don't think users have the capability to make it unique. It's easy, the spec talked about some approaches. NIST SP 800-90 does requires it to be unique, users would have found ways to make it. The revise is highly desire it to be unique, too. My understanding, personalization string is used to add additional randomness, so it is highly desired to be unique. > Finally nobody will use a personalization string. > > 8.7.1 has more description on personalization strings, and it "is not considered to be a critical security parameter". > I'm not sure I understand the sentence: When used within a cryptographic module, a personalization string is not considered to be a critical security parameter. The condition "when used within a cryptographic module", and the extra word "critical" make me confused very much. I don't understand why use a personalization string if it does not impact security. My suggestion to check the unique is more or less conservative. Do you know why use personalization string for DRBG? It's OK to me to have no uniqueness checking if you are sure personalization string does not impact security in our design, or you want to delegate the responsibility to users. >> >>> 2. The default is null, and all nulls are the same. Why bother checking for those non-nulls for uniqueness? >>> >> null is special. If "entropy+nonce+null" is safe, >> "entropy+nonce+'constant'" may be problematic for some crypto operation. > > I'm not sure of this. > I'm not sure too, so I cannot agree with your #2 comment. ;-) It's another more or less conservative. Xuelei From xuelei.fan at oracle.com Wed Apr 20 15:18:42 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 20 Apr 2016 23:18:42 +0800 Subject: Code Review Request 8144566, Custom HostnameVerifier disables SNI extension In-Reply-To: <57177FD9.3080004@oracle.com> References: <56642AD3.6010904@oracle.com> <56662275.5000007@oracle.com> <5666C93E.6010306@oracle.com> <569EDF8A.5000603@oracle.com> <5705932F.7030901@oracle.com> <57177FD9.3080004@oracle.com> Message-ID: <57179DD2.8020508@oracle.com> Thanks for the comments, all looks reasonable to me. Updated webrev: http://cr.openjdk.java.net/~xuelei/8144566/webrev.02/ Thanks, Xuelei On 4/20/2016 9:10 PM, Sean Mullan wrote: > * SSLSocketImpl.java > > 2100 // ONLY used by ClientHandshaker for the server hostname during > handshaling > > typo: handshaking > > 2114 synchronized private void useImplicitHost(boolean noSniUpdate) { > > the modifier order should be "private synchronized ..." > See: http://cr.openjdk.java.net/~alundblad/styleguide/#toc-modifiers > > 2115 if ((host != null) && (host.length() != 0)) { > 2116 return; > 2117 } > > This seems redundant. You already check this before you call the method. > > 2150 // No explicitly specified hostname, no sserver name > indication. > > typo: server > > 2610 if (sniNames.isEmpty()) { > 2611 // need no SNI extension > 2612 noSniExtension = true; > 2613 } // Otherwise, need not to set noSniExtension > 2614 > > Could write more compactly as: > > noSniExtension = sniNames.isEmpty(); > > same comment on lines 2620-4 > > * BestEffortOnLazyConnected.java, ImpactOnSNI.java > > 2 * Copyright (c) 2015, Oracle and/or its affiliates. All rights > reserved. > > 2016 > > I know this is just a test, but it seems like most of these methods and > fields should be private. > > --Sean > > On 04/06/2016 06:52 PM, Xuelei Fan wrote: >> Ping ... >> >> On 1/20/2016 9:14 AM, Xuelei Fan wrote: >>> Ping ... >>> >>> On 12/8/2015 8:12 PM, Xuelei Fan wrote: >>>> Good catch! >>>> >>>> I copied the comment here: >>>> >>>> ---------- >>>> SocketFactory sslsf = SSLSocketFactory.getDefault(); >>>> SSLSocket ssls = (SSLSocket) sslsf.createSocket(); >>>> ssls.connect(new InetSocketAddress( >>>> "bugs.openjdk.java.net", 443), 0); >>>> ssls.startHandshake(); >>>> >>>> No SNI is sent in this case. >>>> ---------- >>>> >>>> Although this is not a regression, but this is a very good catch. >>>> >>>> However, I don't think the code path is a best practice, as the actual >>>> behavior depends on providers behaviors and platform behaviors too >>>> much. >>>> I would recommend to use SSLParameters.setServerNames() to specify >>>> the >>>> server names explicitly. >>>> >>>> But, best effort should be made for the default server names for such >>>> code paths. Here is the webrev that also fixes this code path issue: >>>> >>>> http://cr.openjdk.java.net/~xuelei/8144566/webrev.01/ >>>> >>>> The fix gets a little bit complicated because of the need to consider >>>> the SSLParameters.setServerNames() impact in the code path: >>>> >>>> SSLSocket ssls = (SSLSocket) sslsf.createSocket(); >>>> >>>> // before the connection, need to consider the impact: >>>> // Get the SSLParameters from the socket, or create on the fly? >>>> // Call ssls.setSSLParameters(params) or not? >>>> ssls.connect(socketAddress); >>>> >>>> // after the connection, need to consider the impact: >>>> // Call ssls.setSSLParameters(params) or not? >>>> >>>> Basically, the implementation honors the server name set by >>>> SSLParameters.setServerNames(). >>>> >>>> Bernd's comment: >>>>> Isnt this codepath used as a workaround for dynamically disabling >>>>> SNI? Using connect(host..) instead of SSLSocket(host) was at >>>>> least a common, well known workaround. >>>> If the code path is really used in practice, the >>>> SSLParameters.setServerNames() would better be called actually to >>>> disable SNI explicitly. >>>> >>>> SocketFactory sslsf = SSLSocketFactory.getDefault(); >>>> SSLSocket ssls = (SSLSocket) sslsf.createSocket(); >>>> ssls.connect(new InetSocketAddress( >>>> "bugs.openjdk.java.net", 443), 0); >>>> sslParameters.setServerNames(emptyList); >>>> ssls.setSSLParameters(sslParameters); >>>> ssls.startHandshake(); >>>> >>>> Thank you, Bernd and Brad, for the feedback. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 12/8/2015 8:21 AM, Bradford Wetmore wrote: >>>>> >>>>> Please see my comment in the bug. I haven't verified this, but it >>>>> seems >>>>> the problem might be generic to the codepath through SSLSocket, not >>>>> just >>>>> Https. >>>>> >>>>> Brad >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 12/6/2015 4:32 AM, Xuelei Fan wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the update for JDK-8144566: >>>>>> >>>>>> http://cr.openjdk.java.net/~xuelei/8144566/webrev.00/ >>>>>> >>>>>> For HttpsURLConnection, the server name may be set after the TLS >>>>>> connection and handshake has been initialized. As may result in that >>>>>> the server name does not present at TLS ClientHello messages. >>>>>> >>>>>> This fix resets the server name for the initialized handshake for >>>>>> above >>>>>> cases. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>> >>> >> From claes.redestad at oracle.com Wed Apr 20 16:12:23 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 20 Apr 2016 18:12:23 +0200 Subject: RFR: 8154231: Simplify access to System properties from JDK code In-Reply-To: <5717A6D3.1060706@CoSoCo.de> References: <571795C8.2010007@oracle.com> <5717A6D3.1060706@CoSoCo.de> Message-ID: <5717AA67.40908@oracle.com> Thanks for looking at this, Ulf! On 2016-04-20 17:57, Ulf Zibis wrote: > Hi, > > here my comments: > > Am 20.04.2016 um 16:44 schrieb Claes Redestad: >> Hello, >> >> now that the sun.security.action package is encapsulated we can >> simplify internal code to get System properties. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154231 >> Webrev: http://cr.openjdk.java.net/~redestad/8154231/webrev.01/ >> >> This adds a few convenience methods to GetPropertyAction[1] and >> GetIntegerAction[2]. > > - In the original version of ProcessBuilder.java line 472 there was a > nice example using lambda expression. Wouldn't this be applicable also > for these new methods here? While perhaps a nice example in isolation, creating a lambda when there's already a specialized convenience class available expressing the same thing doesn't add any value. > - Isn't the "theProp" naming style something from an old usage where > all members have been named myXyz? I more would like "propName" or > just "property". I chose to go with keeping names in line with existing methods. If anything is to be done about this I'd prefer changing all names in the class to be consistent and modern, and that'd be a separate RFE. > - In Integer.getProperty the default substitution is done twice, > lines: 143, 148. So maybe return to the "immediate return in if...else > clause" style. The call to Integer.getInteger on line 143 was supposed to be without the defaultVal param to avoid always boxing the defaultVal. Fixed in-place. Thanks! /Claes From mark.reinhold at oracle.com Wed Apr 20 17:15:46 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 20 Apr 2016 10:15:46 -0700 (PDT) Subject: JEP 287: SHA-3 Hash Algorithms Message-ID: <20160420171546.61CB4A69C2@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/287 - Mark From mark.reinhold at oracle.com Wed Apr 20 17:31:15 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 20 Apr 2016 10:31:15 -0700 (PDT) Subject: JEP 288: Disable SHA-1 Certificates Message-ID: <20160420173115.E9167A69E9@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/288 - Mark From jamil.j.nimeh at oracle.com Wed Apr 20 17:40:54 2016 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 20 Apr 2016 10:40:54 -0700 Subject: RFR: Proposed HKDF API (JDK-8145255) In-Reply-To: <571180FA.1020509@comcast.net> References: <57112DBD.2090508@oracle.com> <571146FC.9020507@comcast.net> <57115E0F.4090705@oracle.com> <571180FA.1020509@comcast.net> Message-ID: <5717BF26.8010305@oracle.com> On 04/15/2016 05:02 PM, Michael StJohns wrote: > On 4/15/2016 5:33 PM, Jamil Nimeh wrote: >> Hi Mike, thanks for your comments and suggestions, I need to digest >> some of this but I have some follow-up questions to start: >> >> On 04/15/2016 12:54 PM, Michael StJohns wrote: >>> Hi Jamil - >>> >>> I need to look at this a bit more, but I think its probably >>> incorrect. Basically, KDFs should be able to provide multiple keys >>> from a single call, not a single key as you've described here. >> Would that mean that a second call to Kdf.generateKey() with no prior >> reinitialization would create a new key of whatever output length it >> was initialized with, assuming the end state from the previous call? >> In other words, the output from generateKey1 and generateKey2 would >> yield the same bytes as it would if a single call was made for the >> combined length and then segmented after the fact? > > No. Calling generateKey again would get you the exact same key as > before. Same initial key, same input data, same output data. I'd > probably wipe the state and require a reinitialization rather than do > that. You *don't* want to treat this like a DRBG. Ah, I understand what you mean now. The current implementation will not generate a different key if you call generateKey twice. As you said, same inputs yield the same result. > > >>> They may also may need to provide non-key cryptographic material >>> such as IV's. The TLS1.2 KDF (PRF) is an example of this. >>> >>> There's this other problem that you're outputting unwrapped data - >>> which means you can never define this to run as a hardware module as >>> the outputs are byte arrays. >> The output from SunJCE's implementation (the only one we're doing >> right off the bat) would start as a byte array internally from >> HKDFKeyGenerator, true. But SunJCE's implementation is supposed to >> be native and not assuming outside hardware, AFAIK. If we had to >> interact with an HSM, I would think we'd need to define an >> HKDFKeyGenerator class within the SunPKCS11 provider, or some other >> provider capable of speaking to said HSM. > > Probably, but for software keys you can usually use the "getBytes()" > or equivalent (getEncoded() for SecretKeySpec...) to get out the bytes > if you really need them. Its harder to do this the other way - if > you always have to output bytes, then it won't work in most HSMs. I'm not sure how HSMs are coming into play here, other than that they could possibly be the provider of the HMAC algorithm. SunJCE's implementation is going to build the key as it does successive HMAC operations. Even from an HSM, while the key for doing the HMAC might live in the HSM prior to starting HKDF, the output is going to be a byte array because it's HMAC. Until HSMs have their own way of providing HKDF that yields an object handle (to put it in PKCS#11 parlance) I don't see what we could do in this particular provider differently. Because we have to build the key as a byte array, we're already exposed in host memory. If such mechanisms come along from PKCS#11 providers, > > >> >> My PKCS#11 is a bit rusty, but if the underlying provider had its own >> HDKF mechanism then I would guess we could call into C_DeriveKey >> using that mech and the template could mark the resulting key as >> sensitive or sensitive/non-extractable. If it didn't have an HKDF >> mechanism (OASIS hasn't defined an HKDF mechanism yet, have they?) >> then we could implement HKDF in terms of HMAC calls, but that doesn't >> solve the concern you have, since IIRC C_Sign calls would be used and >> those return byte arrays which would expose the key as bytes until a >> C_CreateObject could be called. > > If the Master Key or Key Derivation Key is inside the HSM, then you > have to use whatever mechanism that gets described to do the KDF > function. AFAICT, Oasis hasn't yet done a KDF for HKDF. You might ask > Valerie Fenwick @oracle to put it on the list of things to do (or you > could even write a contribution :-) ). I'll leave HKDF at Solaris PKCS#11 to the Solaris PKCS#11 folks. But taking advantage of that feature once present wouldn't happen within a SunJCE provider. It would require new code in the PKCS#11 provider I would think. This first swing at HKDF doesn't tackle that. Even if we did, at this point it would be nothing more than a bunch of HMAC calls, which takes us right back to getting byte array output from the PKCS#11 target library/implementation/hardware. > >> >> Assuming though that SunPKCS11 could talk to an HSM that had an HKDF >> mech in their PKCS#11 library, and we added HKDF support to that >> provider, the output from KeyGenerator.generateKey() is a SecretKey, >> one that would I believe be a wrapper around an object handle rather >> than holding the actual key bytes (I'd have to go look to be sure). I >> think that's why calls like Key.getEncoded() are not guaranteed to >> return encoded data...in some cases like a PKCS#11 sensitive key we >> wouldn't be allowed access to it. > > Exactly. > >>> >>> So I'd generalize this more as: (This is a single pass design - I >>> haven't gone back and tweaked the obvious mistakes - not enough time >>> right now). >> Are you suggesting that your KDF solution below is accessed through >> the KeyGenerator API and the implementation would derive from >> KeyGeneratorSpi? I ask because two of the forms of init you provide >> below are not part of the API. > > I think a KDF is a different beast than a KeyGenerator. Trying to > overload KeyGenerator to work with KDF's is problematic. KeyGenerators > generate exactly one type of key. KeyDerivationFunctions can generate > ANY type of key. From talking with one of the other JSL guys here, they say that KeyGenerator is the vehicle usually employed for this kind of thing. I went back and forth with Xuelei on your point a bit over the last couple days. As I understand the API and its requirements, it seems like a different kind of key (say, a TLS 1.x key and mac block) requires a different algorithm provided to the KeyGenerator.getInstance() call, along with possibly a different AlgorithmParameterSpec (if you go that route to init). Some of the TLS key generators used for PRF are an example of this (also in com.sun.crypto.provider). They return SecretKey objects that are actually built from multiple SecretKey objects inside (client read/write keys, HMAC keys, etc.) > > >> >> Or are you thinking of it as standalone or derived from another API? >> Some of the calls make it look like it's intended to be a >> KeyGenerator and that's why I ask. >>> >>> Kdf.getInstance(String algName); >>> >>> Kdf.init (AlgorithmParameterSpec kdfSpec); // only one key >>> produced, well defined by the algName, no parameters required. >>> Kdf.init (AlgorithmParameterSpec kdfSpec, KDFAlgorithmParameterSpec >>> keyspec); >>> Kdf.init (AlgorithmParameterSpec kdfSpec, >>> KDFAlgorithmParameterSpec[] keyspecs); >>> >>> Key xxx = Kdf.generateKey(); >>> Key[] xxx = Kdf.generateKeys(); >> Why do we need an array form for generateKeys? Is that just a >> convenience? Is it inspired by the TLS-style key/mac/IV derivation? > > This goes back to the fact that you call generate only once per > init. You want to make sure that if the order of the keys to which > key material is assigned changes, then so to does the underlying > derived key stream. > > (I've got a long rant related to this - but basically, you want to > make it possible (or least have the API make it possible) to mixin all > of the assignment of key material to cryptographic objecs - e.g. key > type, key length, key protection bits etc. HDKF might not do this, > but other KDFs will and do. The makes it possible for an HSM to use > the mixin data to figure out what protection to assign to the > generated keys in a way that depends on the derivation constants - any > change to the constants changes the entire key stream). It turns > out that its trivial to extract TLS keys from an HSM because the TLS > KDF doesn't mixin the key type and lengths for the keys and IV it > generates, so the derived key stream doesn't change if you change the > keys to be produced. See > https://www.ietf.org/mail-archive/web/i-d-announce/current/msg67039.html > - I need to go back and get this accepted. Is that the stuff also talked about in OASIS where the TLS key and mac derivation template could be changed to setting zero-length data and hmac keys and size the IV output to the required keystream? I thought that was pretty clever. > > > >>> >>> public interface KDFAlgorithmParameterSpec extends >>> AlgorithmParameterSpec { >>> public KDFParameters[] getParams(); >>> } >>> >>> public class SecretKeyAlgorithmSpec implements >>> KDFAlgorithmParameterSpec { >>> public SecretKeyAlgorithmSpec (String algorithm, int size, >>> KDFParameters ... params ); >>> public int getSize(); >>> public String getAlgorithm(); >>> public KDFParameters[] getParams(); >>> } >>> >>> public interface KDFParameters{}; >>> >>> KDFParameters is a marker interface to deal with mixin parameters >>> that are specific to the key material. >>> >>> I'd define HKDF as the instance type for the Kdf.getInstance(). >>> >>> I'd define HKDFAlgorithmParameterSpec and place the info on which >>> PRF function to use in that spec along with any other instance >>> specific stuff. This is also where you put the context and label >>> mixin data. >>> >>> >>> I'd then define the "HKDFExtract" and "HKDFExpand" as two separate >>> KDFs. The first produces a single Key of instance type MasterKey >>> (which is a sub type of SecretKey) which is a well known length >>> based on the provided PRF. The second produces whatever you ask for >>> based on the key spec's you provide. >>> >>> This generalizes well to other KDFs including SP800-108. >> I'll have to spend a little time digesting what you put down here. >> Interesting stuff. > > Yeah - I think this is probably more than you want to do, and is going > to require an API change, but I also think that is the right way to do > it. > > Mike > >> >> --Jamil >>> >>> Mike >>> >>> >>> >>> >>> >>> >>> >>> >>> On 4/15/2016 2:06 PM, Jamil Nimeh wrote: >>>> Hello all, >>>> >>>> We are looking to add HKDF support as a KeyGenerator into OpenJDK >>>> 9. This will be available for general-purpose use. I've documented >>>> the proposed API below. >>>> >>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8145255 >>>> Proof-of-concept implementation: >>>> http://cr.openjdk.java.net/~jnimeh/reviews/8145255/webrev.1/ >>>> >>>> A set of new standard algorithm names would be created that define >>>> the HMAC algorithm used with HKDF: HkdfSHA224, HkdfSHA256, >>>> HkdfSHA384 and HkdfSHA512. We can at a later date include HKDF >>>> variants that use other supported HMAC algorithms. >>>> >>>> Instantiation: >>>> -------------- >>>> In order to do HKDF derivations, a KeyGenerator of the appropriate >>>> type must be obtained. This is done using one of the >>>> KeyGenerator.getInstance methods, specifying the underlying HMAC >>>> type using one of the names listed above. >>>> >>>> Initialization: >>>> --------------- >>>> The resulting HKDF KeyGenerator, in order to be compliant with the >>>> KeyGenerator API, may be used to generate a key without any further >>>> initialization. In this case, the Extract-then-Expand operation >>>> will be performed using null salt and application-specific >>>> information, and a random input key. The resulting output key will >>>> be sized to the output length of the underlying HMAC. This can be >>>> used as a way to obtain a random key. >>>> >>>> The HKDF KeyGenerator supports all five flavors of the init >>>> method. The resulting behavior differs between each flavor however. >>>> >>>> KeyGenerator.init(SecureRandom): >>>> -------------------------------- >>>> If this version of the init method is used, the KeyGenerator will >>>> behave similarly to the default initialization, with the exception >>>> that the caller may provide their own SecureRandom source for the >>>> input key. A null value is allowed, in which case the >>>> implementation will obtain the default SecureRandom implementation >>>> for generating the input key. >>>> >>>> KeyGenerator.init(int); >>>> KeyGenerator.init(int, SecureRandom); >>>> ------------------------------------- >>>> These two versions of the KeyGenerator allow the caller to provide >>>> the resulting key length and, in the second case provide a >>>> SecureRandom source. The caller must provide a non-negative length >>>> value in bytes. A value of zero is allowed and returns a key of >>>> the same length as the underlying HMAC. In both forms the >>>> Extract-then-Expand operation will be performed with null salt and >>>> application-specific information, and a random input key. If a >>>> SecureRandom value is provided, its behavior is similar to >>>> KeyGenerator.init(SecureRandom). >>>> >>>> KeyGenerator.init(AlgorithmParameterSpec); >>>> KeyGenerator.init(AlgorithmParameterSpec, SecureRandom); >>>> -------------------------------------------------------- >>>> These versions of the init method allow the caller to customize the >>>> input parameters to the HKDF generator as well as select the HKDF >>>> function to perform. >>>> >>>> Users desiring a specific HKDF function would initialize it using >>>> one of three new AlgorithmParameterSpec classes: >>>> HkdfExtractParameterSpec, HkdfExpandParameterSpec, or >>>> HkdfParameterSpec. These three parameter spec classes are used to >>>> initialize the HKDF key generator to perform the HKDF-Expand, >>>> HKDF-Extract or a combination HKDF-Extract-then-Expand operation, >>>> respectively. >>>> >>>> The init(AlgorithmParameterSpec, SecureRandom) ignores the >>>> SecureRandom parameter, and requires that input key material (IKM) >>>> or a pseudorandom key (PRK) is provided. >>>> >>>> Key Generation: >>>> --------------- >>>> Once initialized (default or via one of the init methods) a key is >>>> generated by calling KeyGenerator.generateKey(). >>>> >>>> >>>> The Specification: >>>> ------------------ >>>> Three new AlgorithmParameterSpec classes will be created to >>>> initialize HKDF KeyGenerator objects: >>>> HkdfParameterSpec: For performing the Extract-then-Expand operation >>>> HkdfExtractParameterSpec: For performingthe HKDF-Extract operation >>>> HkdfExpandParameterSpec: For performing the HKDF-Expand operation >>>> >>>> >>>> /** >>>> * Parameters for the Extract operation of the HMAC-based >>>> Extract-and-Expand >>>> * Key Derivation Function (HKDF). The HKDF function is defined in >>>> * RFC 5869. >>>> * This class is used to initialize KeyGenerators in the HKDF >>>> family of >>>> * generators, specifically for the HKDF Extract function. >>>> *

>>>> * Here is an example of how an HkdfExtractParameterSpec would be >>>> used to >>>> * initialize an HKDF KeyGenerator: >>>> *

>>>>  *     byte[] salt;
>>>>  *     SecretKey inputKey;
>>>>  *     SecretKey resultingPRK;
>>>>  *
>>>>  *     // salt and inputKey values populated with data
>>>>  *     ...
>>>>  *
>>>>  *     // Get an instance of the HKDF KeyGenerator
>>>>  *     hkdfGen = KeyGenerator.getInstance("HkdfSHA256");
>>>>  *
>>>>  *     // Create the spec object and use it to initialize the 
>>>> generator.
>>>>  *     hkdfGen.init(new HkdfExtractParameterSpec(salt, inputKey));
>>>>  *
>>>>  *     // Generate the PRK
>>>>  *     resultingPRK = hkdfGen.generateKey();
>>>>  * 
>>>> * >>>> * @since 9 >>>> */ >>>> public final class HkdfExtractParameterSpec implements >>>> AlgorithmParameterSpec { >>>> >>>> /** >>>> * Constructs a new HkdfExtractParameterSpec with the given >>>> salt value >>>> * and key material >>>> * >>>> * @param salt the salt value, or {@code null} if not >>>> specified. The >>>> * contents of the array are copied to protect against >>>> subsequent >>>> * modification. >>>> * @param inputKey the Input Keying Material (IKM). >>>> * >>>> * @throws NullPointerException if {@code inputKey} is {@code >>>> null}. >>>> */ >>>> public HkdfExtractParameterSpec(byte[] salt, SecretKey inputKey); >>>> >>>> /** >>>> * Returns the Input Keying Material (IKM). >>>> * >>>> * @return the Input Keying Material. >>>> */ >>>> public SecretKey getIKM(); >>>> >>>> /** >>>> * Returns the salt value. >>>> * >>>> * @return a copy of the salt value or {@code null} if no salt >>>> was provided. >>>> */ >>>> public byte[] getSalt(); >>>> } >>>> >>>> HkdfExpandParameterSpec: >>>> ------------------------ >>>> /** >>>> * Parameters for the Expand operation of the HMAC-based >>>> Extract-and-Expand >>>> * Key Derivation Function (HKDF). The HKDF function is defined in >>>> * RFC 5869. >>>> *

>>>> * Here is an example of how an HkdfExpandParameterSpec would be >>>> used to >>>> * initialize an HKDF KeyGenerator: >>>> *

>>>>  *     byte[] info;
>>>>  *     SecretKey pseudoRandomKey;
>>>>  *     SecretKey resultingKey;
>>>>  *
>>>>  *     // pseudoRandomKey and context info values populated with data
>>>>  *     ...
>>>>  *
>>>>  *     // Get an instance of the HKDF KeyGenerator
>>>>  *     hkdfGen = KeyGenerator.getInstance("HkdfSHA256");
>>>>  *
>>>>  *     // Create the spec object and use it to initialize the 
>>>> generator.
>>>>  *     // Ask for a 64-byte key to be output.
>>>>  *     hkdfGen.init(new HkdfExpandParameterSpec(pseudoRandomKey, 
>>>> info, 64));
>>>>  *
>>>>  *     // Generate the key
>>>>  *     resultingKey = hkdfGen.generateKey();
>>>>  * 
>>>> * >>>> * @since 9 >>>> */ >>>> public final class HkdfExpandParameterSpec implements >>>> AlgorithmParameterSpec { >>>> >>>> /** >>>> * Constructs a new HkdfExpandParameterSpec. >>>> * >>>> * @param prk the pseudorandom key used for HKDF-Expand. >>>> * @param info optional context and application specific >>>> information or >>>> * {@code null} if no info data is provided. The contents >>>> of the >>>> * array are copied to protect against subsequent >>>> modification. >>>> * @param outLen the length in bytes of the output data >>>> * >>>> * @throws NullPointerException if {@code prk} is {@code null}. >>>> * @throws IllegalArgumentException if {@code outLen} is a >>>> * non-positive value. >>>> */ >>>> public HkdfExpandParameterSpec(SecretKey prk, byte[] info, int >>>> outLen); >>>> >>>> /** >>>> * Returns a {@link SecretKey} object containing the >>>> pseudorandom key (PRK). >>>> * >>>> * @return a {@link SecretKey} object containing the >>>> pseudorandom key. >>>> */ >>>> public SecretKey getPRK(); >>>> >>>> /** >>>> * Returns a copy of the context and application specific >>>> information. >>>> * >>>> * @return a copy of the context and application specific >>>> information. >>>> * This may be {@code null} or empty if no specific >>>> information was >>>> * provided. >>>> */ >>>> public byte[] getInfo(); >>>> >>>> /** >>>> * Returns the length in bytes of the output key to be produced. >>>> * >>>> * @return the length in bytes of the output key to be produced. >>>> */ >>>> public int getOutputLength(); >>>> } >>>> >>>> >>>> HkdfParameterSpec: >>>> ------------------ >>>> >>>> /** >>>> * Parameters for the combined Extract-then-Expand operation of the >>>> HMAC-based >>>> * Extract-and-Expand Key Derivation Function (HKDF). The HKDF >>>> function >>>> * is defined in RFC >>>> 5869. >>>> *

>>>> * Here is an example of how an HkdfParameterSpec would be used to >>>> initialize >>>> * an HKDF KeyGenerator: >>>> *

>>>>  *     byte[] salt;
>>>>  *     byte[] info;
>>>>  *     SecretKey inputKey;
>>>>  *     SecretKey resultingKey;
>>>>  *
>>>>  *     // salt, info and inputKey values populated with data
>>>>  *     ...
>>>>  *
>>>>  *     // Get an instance of the HKDF KeyGenerator
>>>>  *     hkdfGen = KeyGenerator.getInstance("HkdfSHA256");
>>>>  *
>>>>  *     // Create the spec object and use it to initialize the 
>>>> generator.
>>>>  *     // Ask for a 64-byte key to be output.
>>>>  *     hkdfGen.init(new HkdfParameterSpec(inputKey, salt, info, 64));
>>>>  *
>>>>  *     // Generate the key
>>>>  *     resultingKey = hkdfGen.generateKey();
>>>>  * 
>>>> * >>>> * @since 9 >>>> */ >>>> public final class HkdfParameterSpec implements >>>> AlgorithmParameterSpec { >>>> >>>> /** >>>> * Constructs a new HkdfParameterSpec. >>>> * >>>> * @param inputKey the input keying material used for the >>>> * HKDF-Extract-then-Expand operation. >>>> * @param salt the salt value, or {@code null} if not >>>> specified. The >>>> * contents of the array are copied to protect against >>>> subsequent >>>> * modification. >>>> * @param info optional context and application specific >>>> information or >>>> * {@code null} if no info data is provided. The contents >>>> of the >>>> * array are copied to protect against subsequent >>>> modification. >>>> * @param outLen the length in bytes of the output data >>>> * >>>> * @throws NullPointerException if {@code inputKey} is {@code >>>> null}. >>>> * @throws IllegalArgumentException if {@code outLen} is a >>>> * non-positive value. >>>> */ >>>> public HkdfParameterSpec(SecretKey inputKey, byte[] salt, >>>> byte[] info, >>>> int outLen); >>>> >>>> /** >>>> * Returns the Input Keying Material (IKM). >>>> * >>>> * @return the Input Keying Material. >>>> */ >>>> public SecretKey getIKM(); >>>> >>>> /** >>>> * Returns the salt value. >>>> * >>>> * @return a copy of the salt value or {@code null} if no salt >>>> was provided. >>>> */ >>>> public byte[] getSalt(); >>>> >>>> /** >>>> * Returns a copy of the context and application specific >>>> information. >>>> * >>>> * @return a copy of the context and application specific >>>> information. >>>> * This may be {@code null} or empty if no specific >>>> information was >>>> * provided. >>>> */ >>>> public byte[] getInfo(); >>>> >>>> /** >>>> * Returns the length in bytes of the output key to be produced. >>>> * >>>> * @return the length in bytes of the output key to be produced. >>>> */ >>>> public int getOutputLength(); >>>> } >>> >> > From claes.redestad at oracle.com Wed Apr 20 14:44:24 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 20 Apr 2016 16:44:24 +0200 Subject: RFR: 8154231: Simplify access to System properties from JDK code Message-ID: <571795C8.2010007@oracle.com> Hello, now that the sun.security.action package is encapsulated we can simplify internal code to get System properties. Bug: https://bugs.openjdk.java.net/browse/JDK-8154231 Webrev: http://cr.openjdk.java.net/~redestad/8154231/webrev.01/ This adds a few convenience methods to GetPropertyAction[1] and GetIntegerAction[2]. Since the code calling into this can be streamlined, this leads to a net static footprint reduction of the java.base module and a tiny startup improvement. Thanks! /Claes [1] http://cr.openjdk.java.net/~redestad/8154231/webrev.01/src/java.base/share/classes/sun/security/action/GetPropertyAction.java.udiff.html [2] http://cr.openjdk.java.net/~redestad/8154231/webrev.01/src/java.base/share/classes/sun/security/action/GetIntegerAction.java.udiff.html From claes.redestad at oracle.com Wed Apr 20 15:17:56 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 20 Apr 2016 17:17:56 +0200 Subject: RFR: 8154231: Simplify access to System properties from JDK code In-Reply-To: <15E99E17-D462-4578-9A34-58055F9F69D6@oracle.com> References: <571795C8.2010007@oracle.com> <15E99E17-D462-4578-9A34-58055F9F69D6@oracle.com> Message-ID: <57179DA4.4070205@oracle.com> On 2016-04-20 16:58, Wang Weijun wrote: > This is quite convenient. Glad you like it! > We not cover the other modules? > > exports sun.security.action to > java.desktop, > java.security.jgss, > jdk.crypto.pkcs11; I was worried I included too many changes in this patch as it is. :-) If this patch is accepted my intention is to file follow-up RFEs for the other modules. /Claes > > Thanks > Max > >> On Apr 20, 2016, at 10:44 PM, Claes Redestad wrote: >> >> Hello, >> >> now that the sun.security.action package is encapsulated we can simplify internal code to get System properties. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154231 >> Webrev: http://cr.openjdk.java.net/~redestad/8154231/webrev.01/ >> >> This adds a few convenience methods to GetPropertyAction[1] and GetIntegerAction[2]. Since the code calling into this can be streamlined, this leads to a net static footprint reduction of the java.base module and a tiny startup improvement. >> >> Thanks! >> >> /Claes >> >> [1] http://cr.openjdk.java.net/~redestad/8154231/webrev.01/src/java.base/share/classes/sun/security/action/GetPropertyAction.java.udiff.html >> [2] http://cr.openjdk.java.net/~redestad/8154231/webrev.01/src/java.base/share/classes/sun/security/action/GetIntegerAction.java.udiff.html From Ulf.Zibis at CoSoCo.de Wed Apr 20 16:56:46 2016 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 20 Apr 2016 18:56:46 +0200 Subject: RFR: 8154231: Simplify access to System properties from JDK code In-Reply-To: <5717AA67.40908@oracle.com> References: <571795C8.2010007@oracle.com> <5717A6D3.1060706@CoSoCo.de> <5717AA67.40908@oracle.com> Message-ID: <5717B4CE.9040109@CoSoCo.de> Hi Claes, thanks. Am 20.04.2016 um 18:12 schrieb Claes Redestad: > Thanks for looking at this, Ulf! > >> - Isn't the "theProp" naming style something from an old usage where all members have been named >> myXyz? I more would like "propName" or just "property". > > I chose to go with keeping names in line with existing methods. If anything is to be done about > this I'd prefer changing all names in the class to be consistent and modern, and that'd be a > separate RFE. Oops, I didn't notice that. ... and semantically more precise would be: "propKey" or "propID". -Ulf From mstjohns at comcast.net Wed Apr 20 18:27:51 2016 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 20 Apr 2016 14:27:51 -0400 Subject: RFR: Proposed HKDF API (JDK-8145255) In-Reply-To: <5717BF26.8010305@oracle.com> References: <57112DBD.2090508@oracle.com> <571146FC.9020507@comcast.net> <57115E0F.4090705@oracle.com> <571180FA.1020509@comcast.net> <5717BF26.8010305@oracle.com> Message-ID: <5717CA27.1030506@comcast.net> On 4/20/2016 1:40 PM, Jamil Nimeh wrote: > > > On 04/15/2016 05:02 PM, Michael StJohns wrote: >> On 4/15/2016 5:33 PM, Jamil Nimeh wrote: >>> Hi Mike, thanks for your comments and suggestions, I need to digest >>> some of this but I have some follow-up questions to start: >>> >>> On 04/15/2016 12:54 PM, Michael StJohns wrote: >>>> Hi Jamil - >>>> >>>> I need to look at this a bit more, but I think its probably >>>> incorrect. Basically, KDFs should be able to provide multiple keys >>>> from a single call, not a single key as you've described here. >>> Would that mean that a second call to Kdf.generateKey() with no >>> prior reinitialization would create a new key of whatever output >>> length it was initialized with, assuming the end state from the >>> previous call? In other words, the output from generateKey1 and >>> generateKey2 would yield the same bytes as it would if a single call >>> was made for the combined length and then segmented after the fact? >> >> No. Calling generateKey again would get you the exact same key as >> before. Same initial key, same input data, same output data. I'd >> probably wipe the state and require a reinitialization rather than do >> that. You *don't* want to treat this like a DRBG. > Ah, I understand what you mean now. The current implementation will > not generate a different key if you call generateKey twice. As you > said, same inputs yield the same result. >> >> >>>> They may also may need to provide non-key cryptographic material >>>> such as IV's. The TLS1.2 KDF (PRF) is an example of this. >>>> >>>> There's this other problem that you're outputting unwrapped data - >>>> which means you can never define this to run as a hardware module >>>> as the outputs are byte arrays. >>> The output from SunJCE's implementation (the only one we're doing >>> right off the bat) would start as a byte array internally from >>> HKDFKeyGenerator, true. But SunJCE's implementation is supposed to >>> be native and not assuming outside hardware, AFAIK. If we had to >>> interact with an HSM, I would think we'd need to define an >>> HKDFKeyGenerator class within the SunPKCS11 provider, or some other >>> provider capable of speaking to said HSM. >> >> Probably, but for software keys you can usually use the "getBytes()" >> or equivalent (getEncoded() for SecretKeySpec...) to get out the >> bytes if you really need them. Its harder to do this the other way >> - if you always have to output bytes, then it won't work in most HSMs. > I'm not sure how HSMs are coming into play here, other than that they > could possibly be the provider of the HMAC algorithm. SunJCE's > implementation is going to build the key as it does successive HMAC > operations. Even from an HSM, while the key for doing the HMAC might > live in the HSM prior to starting HKDF, the output is going to be a > byte array because it's HMAC. Until HSMs have their own way of > providing HKDF that yields an object handle (to put it in PKCS#11 > parlance) I don't see what we could do in this particular provider > differently. Because we have to build the key as a byte array, we're > already exposed in host memory. A software-based provider of a KDF will produce a byte array and wrap it in a software Key implementation. The byte array will be extractable. A hardware-based provider of a KDF will produce a handle to an internal key and wrap the handle in a hardware Key implementation. The key stream that makes up the key may or may not be extractable for a hardware implementation, but is probably always extractable for a software one. Don't focus on the HMAC function - focus on the KDF function that uses the HMAC (or hash or CMAC) function as its RBG engine. The output of an HMAC function (or cmac or hash for that matter) is public data. The output of the KDF is mostly non-public key material. The fact that a given KDF uses a public output function as its engine function doesn't mean that the output of the KDF is always public data. Its somewhat a problem that the same key can be used to key both an HMAC and a KDF based on HMAC, but that's a bug, not a feature. The way you deal with this is bifurcate the key space or to tag the key material with its use. E.g. add a javax.crypto.kdf.MasterKey interface and use that to type what gets fed to the KDF. Even though it has the same general characteristics as a SecretKey, it can't be a sub interface to SecretKey so you can enforce the separation. > > If such mechanisms come along from PKCS#11 providers, The TLS 1.2/1.1 Mechanism already exists. But it's very clumsy and basically wrong. >> >> >>> >>> My PKCS#11 is a bit rusty, but if the underlying provider had its >>> own HDKF mechanism then I would guess we could call into C_DeriveKey >>> using that mech and the template could mark the resulting key as >>> sensitive or sensitive/non-extractable. If it didn't have an HKDF >>> mechanism (OASIS hasn't defined an HKDF mechanism yet, have they?) >>> then we could implement HKDF in terms of HMAC calls, but that >>> doesn't solve the concern you have, since IIRC C_Sign calls would be >>> used and those return byte arrays which would expose the key as >>> bytes until a C_CreateObject could be called. >> >> If the Master Key or Key Derivation Key is inside the HSM, then you >> have to use whatever mechanism that gets described to do the KDF >> function. AFAICT, Oasis hasn't yet done a KDF for HKDF. You might >> ask Valerie Fenwick @oracle to put it on the list of things to do (or >> you could even write a contribution :-) ). > I'll leave HKDF at Solaris PKCS#11 to the Solaris PKCS#11 folks. But > taking advantage of that feature once present wouldn't happen within a > SunJCE provider. It would require new code in the PKCS#11 provider I > would think. This first swing at HKDF doesn't tackle that. Even if > we did, at this point it would be nothing more than a bunch of HMAC > calls, which takes us right back to getting byte array output from the > PKCS#11 target library/implementation/hardware. I don't think you can do this with the current API and do what you want to do. I think you really do need a KDF API. In PKCS11 you get handles to the session keys if you call C_DeriveKey to derive TLS key material. The handles to the session key end up in the structure you pass to the call so the keys never actually come out as bytes. I would expect that to be true with the TLS1.3 HKDF function as well - or pretty close. If they actually come out as keys from a KDF, then you can't actually extract the key bytes from the keys if you do it correctly. If they come out as bytes into software land, then you have to put them back into the HSM and you lose the secrecy of the key material in the in and out process. >> >>> >>> Assuming though that SunPKCS11 could talk to an HSM that had an HKDF >>> mech in their PKCS#11 library, and we added HKDF support to that >>> provider, the output from KeyGenerator.generateKey() is a SecretKey, >>> one that would I believe be a wrapper around an object handle rather >>> than holding the actual key bytes (I'd have to go look to be sure). >>> I think that's why calls like Key.getEncoded() are not guaranteed to >>> return encoded data...in some cases like a PKCS#11 sensitive key we >>> wouldn't be allowed access to it. >> >> Exactly. >> >>>> >>>> So I'd generalize this more as: (This is a single pass design - I >>>> haven't gone back and tweaked the obvious mistakes - not enough >>>> time right now). >>> Are you suggesting that your KDF solution below is accessed through >>> the KeyGenerator API and the implementation would derive from >>> KeyGeneratorSpi? I ask because two of the forms of init you provide >>> below are not part of the API. >> >> I think a KDF is a different beast than a KeyGenerator. Trying to >> overload KeyGenerator to work with KDF's is problematic. >> KeyGenerators generate exactly one type of key. >> KeyDerivationFunctions can generate ANY type of key. > From talking with one of the other JSL guys here, they say that > KeyGenerator is the vehicle usually employed for this kind of thing. > I went back and forth with Xuelei on your point a bit over the last > couple days. As I understand the API and its requirements, it seems > like a different kind of key (say, a TLS 1.x key and mac block) > requires a different algorithm provided to the > KeyGenerator.getInstance() call, along with possibly a different > AlgorithmParameterSpec (if you go that route to init). Some of the TLS > key generators used for PRF are an example of this (also in > com.sun.crypto.provider). They return SecretKey objects that are > actually built from multiple SecretKey objects inside (client > read/write keys, HMAC keys, etc.) Yup... and it would be really nice to fix that and generalize that. KeyGeneration is *really* a different beast from KeyDerivation and the more I spend time on it, the more I realize how badly we've done on the design. (The TLS trick I mentioned about IVs? It can be repeated with IPSEC too....). >> >> >>> >>> Or are you thinking of it as standalone or derived from another >>> API? Some of the calls make it look like it's intended to be a >>> KeyGenerator and that's why I ask. >>>> >>>> Kdf.getInstance(String algName); >>>> >>>> Kdf.init (AlgorithmParameterSpec kdfSpec); // only one key >>>> produced, well defined by the algName, no parameters required. >>>> Kdf.init (AlgorithmParameterSpec kdfSpec, KDFAlgorithmParameterSpec >>>> keyspec); >>>> Kdf.init (AlgorithmParameterSpec kdfSpec, >>>> KDFAlgorithmParameterSpec[] keyspecs); >>>> >>>> Key xxx = Kdf.generateKey(); >>>> Key[] xxx = Kdf.generateKeys(); >>> Why do we need an array form for generateKeys? Is that just a >>> convenience? Is it inspired by the TLS-style key/mac/IV derivation? >> >> This goes back to the fact that you call generate only once per >> init. You want to make sure that if the order of the keys to which >> key material is assigned changes, then so to does the underlying >> derived key stream. >> >> (I've got a long rant related to this - but basically, you want to >> make it possible (or least have the API make it possible) to mixin >> all of the assignment of key material to cryptographic objecs - e.g. >> key type, key length, key protection bits etc. HDKF might not do >> this, but other KDFs will and do. The makes it possible for an HSM >> to use the mixin data to figure out what protection to assign to the >> generated keys in a way that depends on the derivation constants - >> any change to the constants changes the entire key stream). It >> turns out that its trivial to extract TLS keys from an HSM because >> the TLS KDF doesn't mixin the key type and lengths for the keys and >> IV it generates, so the derived key stream doesn't change if you >> change the keys to be produced. See >> https://www.ietf.org/mail-archive/web/i-d-announce/current/msg67039.html >> - I need to go back and get this accepted. > Is that the stuff also talked about in OASIS where the TLS key and mac > derivation template could be changed to setting zero-length data and > hmac keys and size the IV output to the required keystream? I thought > that was pretty clever. Yup. Since the assignment information (key type and length and other things) isn't a mixin to the key stream generation, simply changing the lengths of the individual element output lengths allows you to assign exactly the same key stream to any mix of public and non-public output elements. Mike >> >> >> >>>> >>>> public interface KDFAlgorithmParameterSpec extends >>>> AlgorithmParameterSpec { >>>> public KDFParameters[] getParams(); >>>> } >>>> >>>> public class SecretKeyAlgorithmSpec implements >>>> KDFAlgorithmParameterSpec { >>>> public SecretKeyAlgorithmSpec (String algorithm, int size, >>>> KDFParameters ... params ); >>>> public int getSize(); >>>> public String getAlgorithm(); >>>> public KDFParameters[] getParams(); >>>> } >>>> >>>> public interface KDFParameters{}; >>>> >>>> KDFParameters is a marker interface to deal with mixin parameters >>>> that are specific to the key material. >>>> >>>> I'd define HKDF as the instance type for the Kdf.getInstance(). >>>> >>>> I'd define HKDFAlgorithmParameterSpec and place the info on which >>>> PRF function to use in that spec along with any other instance >>>> specific stuff. This is also where you put the context and label >>>> mixin data. >>>> >>>> >>>> I'd then define the "HKDFExtract" and "HKDFExpand" as two separate >>>> KDFs. The first produces a single Key of instance type MasterKey >>>> (which is a sub type of SecretKey) which is a well known length >>>> based on the provided PRF. The second produces whatever you ask >>>> for based on the key spec's you provide. >>>> >>>> This generalizes well to other KDFs including SP800-108. >>> I'll have to spend a little time digesting what you put down here. >>> Interesting stuff. >> >> Yeah - I think this is probably more than you want to do, and is >> going to require an API change, but I also think that is the right >> way to do it. >> >> Mike >> >>> >>> --Jamil >>>> >>>> Mike >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 4/15/2016 2:06 PM, Jamil Nimeh wrote: >>>>> Hello all, >>>>> >>>>> We are looking to add HKDF support as a KeyGenerator into OpenJDK >>>>> 9. This will be available for general-purpose use. I've >>>>> documented the proposed API below. >>>>> >>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8145255 >>>>> Proof-of-concept implementation: >>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8145255/webrev.1/ >>>>> >>>>> A set of new standard algorithm names would be created that define >>>>> the HMAC algorithm used with HKDF: HkdfSHA224, HkdfSHA256, >>>>> HkdfSHA384 and HkdfSHA512. We can at a later date include HKDF >>>>> variants that use other supported HMAC algorithms. >>>>> >>>>> Instantiation: >>>>> -------------- >>>>> In order to do HKDF derivations, a KeyGenerator of the appropriate >>>>> type must be obtained. This is done using one of the >>>>> KeyGenerator.getInstance methods, specifying the underlying HMAC >>>>> type using one of the names listed above. >>>>> >>>>> Initialization: >>>>> --------------- >>>>> The resulting HKDF KeyGenerator, in order to be compliant with the >>>>> KeyGenerator API, may be used to generate a key without any >>>>> further initialization. In this case, the Extract-then-Expand >>>>> operation will be performed using null salt and >>>>> application-specific information, and a random input key. The >>>>> resulting output key will be sized to the output length of the >>>>> underlying HMAC. This can be used as a way to obtain a random key. >>>>> >>>>> The HKDF KeyGenerator supports all five flavors of the init >>>>> method. The resulting behavior differs between each flavor however. >>>>> >>>>> KeyGenerator.init(SecureRandom): >>>>> -------------------------------- >>>>> If this version of the init method is used, the KeyGenerator will >>>>> behave similarly to the default initialization, with the exception >>>>> that the caller may provide their own SecureRandom source for the >>>>> input key. A null value is allowed, in which case the >>>>> implementation will obtain the default SecureRandom implementation >>>>> for generating the input key. >>>>> >>>>> KeyGenerator.init(int); >>>>> KeyGenerator.init(int, SecureRandom); >>>>> ------------------------------------- >>>>> These two versions of the KeyGenerator allow the caller to provide >>>>> the resulting key length and, in the second case provide a >>>>> SecureRandom source. The caller must provide a non-negative >>>>> length value in bytes. A value of zero is allowed and returns a >>>>> key of the same length as the underlying HMAC. In both forms the >>>>> Extract-then-Expand operation will be performed with null salt and >>>>> application-specific information, and a random input key. If a >>>>> SecureRandom value is provided, its behavior is similar to >>>>> KeyGenerator.init(SecureRandom). >>>>> >>>>> KeyGenerator.init(AlgorithmParameterSpec); >>>>> KeyGenerator.init(AlgorithmParameterSpec, SecureRandom); >>>>> -------------------------------------------------------- >>>>> These versions of the init method allow the caller to customize >>>>> the input parameters to the HKDF generator as well as select the >>>>> HKDF function to perform. >>>>> >>>>> Users desiring a specific HKDF function would initialize it using >>>>> one of three new AlgorithmParameterSpec classes: >>>>> HkdfExtractParameterSpec, HkdfExpandParameterSpec, or >>>>> HkdfParameterSpec. These three parameter spec classes are used to >>>>> initialize the HKDF key generator to perform the HKDF-Expand, >>>>> HKDF-Extract or a combination HKDF-Extract-then-Expand operation, >>>>> respectively. >>>>> >>>>> The init(AlgorithmParameterSpec, SecureRandom) ignores the >>>>> SecureRandom parameter, and requires that input key material (IKM) >>>>> or a pseudorandom key (PRK) is provided. >>>>> >>>>> Key Generation: >>>>> --------------- >>>>> Once initialized (default or via one of the init methods) a key is >>>>> generated by calling KeyGenerator.generateKey(). >>>>> >>>>> >>>>> The Specification: >>>>> ------------------ >>>>> Three new AlgorithmParameterSpec classes will be created to >>>>> initialize HKDF KeyGenerator objects: >>>>> HkdfParameterSpec: For performing the Extract-then-Expand operation >>>>> HkdfExtractParameterSpec: For performingthe HKDF-Extract operation >>>>> HkdfExpandParameterSpec: For performing the HKDF-Expand operation >>>>> >>>>> >>>>> /** >>>>> * Parameters for the Extract operation of the HMAC-based >>>>> Extract-and-Expand >>>>> * Key Derivation Function (HKDF). The HKDF function is defined in >>>>> * RFC 5869. >>>>> * This class is used to initialize KeyGenerators in the HKDF >>>>> family of >>>>> * generators, specifically for the HKDF Extract function. >>>>> *

>>>>> * Here is an example of how an HkdfExtractParameterSpec would be >>>>> used to >>>>> * initialize an HKDF KeyGenerator: >>>>> *

>>>>>  *     byte[] salt;
>>>>>  *     SecretKey inputKey;
>>>>>  *     SecretKey resultingPRK;
>>>>>  *
>>>>>  *     // salt and inputKey values populated with data
>>>>>  *     ...
>>>>>  *
>>>>>  *     // Get an instance of the HKDF KeyGenerator
>>>>>  *     hkdfGen = KeyGenerator.getInstance("HkdfSHA256");
>>>>>  *
>>>>>  *     // Create the spec object and use it to initialize the 
>>>>> generator.
>>>>>  *     hkdfGen.init(new HkdfExtractParameterSpec(salt, inputKey));
>>>>>  *
>>>>>  *     // Generate the PRK
>>>>>  *     resultingPRK = hkdfGen.generateKey();
>>>>>  * 
>>>>> * >>>>> * @since 9 >>>>> */ >>>>> public final class HkdfExtractParameterSpec implements >>>>> AlgorithmParameterSpec { >>>>> >>>>> /** >>>>> * Constructs a new HkdfExtractParameterSpec with the given >>>>> salt value >>>>> * and key material >>>>> * >>>>> * @param salt the salt value, or {@code null} if not >>>>> specified. The >>>>> * contents of the array are copied to protect against >>>>> subsequent >>>>> * modification. >>>>> * @param inputKey the Input Keying Material (IKM). >>>>> * >>>>> * @throws NullPointerException if {@code inputKey} is {@code >>>>> null}. >>>>> */ >>>>> public HkdfExtractParameterSpec(byte[] salt, SecretKey inputKey); >>>>> >>>>> /** >>>>> * Returns the Input Keying Material (IKM). >>>>> * >>>>> * @return the Input Keying Material. >>>>> */ >>>>> public SecretKey getIKM(); >>>>> >>>>> /** >>>>> * Returns the salt value. >>>>> * >>>>> * @return a copy of the salt value or {@code null} if no salt >>>>> was provided. >>>>> */ >>>>> public byte[] getSalt(); >>>>> } >>>>> >>>>> HkdfExpandParameterSpec: >>>>> ------------------------ >>>>> /** >>>>> * Parameters for the Expand operation of the HMAC-based >>>>> Extract-and-Expand >>>>> * Key Derivation Function (HKDF). The HKDF function is defined in >>>>> * RFC 5869. >>>>> *

>>>>> * Here is an example of how an HkdfExpandParameterSpec would be >>>>> used to >>>>> * initialize an HKDF KeyGenerator: >>>>> *

>>>>>  *     byte[] info;
>>>>>  *     SecretKey pseudoRandomKey;
>>>>>  *     SecretKey resultingKey;
>>>>>  *
>>>>>  *     // pseudoRandomKey and context info values populated with data
>>>>>  *     ...
>>>>>  *
>>>>>  *     // Get an instance of the HKDF KeyGenerator
>>>>>  *     hkdfGen = KeyGenerator.getInstance("HkdfSHA256");
>>>>>  *
>>>>>  *     // Create the spec object and use it to initialize the 
>>>>> generator.
>>>>>  *     // Ask for a 64-byte key to be output.
>>>>>  *     hkdfGen.init(new HkdfExpandParameterSpec(pseudoRandomKey, 
>>>>> info, 64));
>>>>>  *
>>>>>  *     // Generate the key
>>>>>  *     resultingKey = hkdfGen.generateKey();
>>>>>  * 
>>>>> * >>>>> * @since 9 >>>>> */ >>>>> public final class HkdfExpandParameterSpec implements >>>>> AlgorithmParameterSpec { >>>>> >>>>> /** >>>>> * Constructs a new HkdfExpandParameterSpec. >>>>> * >>>>> * @param prk the pseudorandom key used for HKDF-Expand. >>>>> * @param info optional context and application specific >>>>> information or >>>>> * {@code null} if no info data is provided. The >>>>> contents of the >>>>> * array are copied to protect against subsequent >>>>> modification. >>>>> * @param outLen the length in bytes of the output data >>>>> * >>>>> * @throws NullPointerException if {@code prk} is {@code null}. >>>>> * @throws IllegalArgumentException if {@code outLen} is a >>>>> * non-positive value. >>>>> */ >>>>> public HkdfExpandParameterSpec(SecretKey prk, byte[] info, int >>>>> outLen); >>>>> >>>>> /** >>>>> * Returns a {@link SecretKey} object containing the >>>>> pseudorandom key (PRK). >>>>> * >>>>> * @return a {@link SecretKey} object containing the >>>>> pseudorandom key. >>>>> */ >>>>> public SecretKey getPRK(); >>>>> >>>>> /** >>>>> * Returns a copy of the context and application specific >>>>> information. >>>>> * >>>>> * @return a copy of the context and application specific >>>>> information. >>>>> * This may be {@code null} or empty if no specific >>>>> information was >>>>> * provided. >>>>> */ >>>>> public byte[] getInfo(); >>>>> >>>>> /** >>>>> * Returns the length in bytes of the output key to be produced. >>>>> * >>>>> * @return the length in bytes of the output key to be produced. >>>>> */ >>>>> public int getOutputLength(); >>>>> } >>>>> >>>>> >>>>> HkdfParameterSpec: >>>>> ------------------ >>>>> >>>>> /** >>>>> * Parameters for the combined Extract-then-Expand operation of >>>>> the HMAC-based >>>>> * Extract-and-Expand Key Derivation Function (HKDF). The HKDF >>>>> function >>>>> * is defined in RFC >>>>> 5869. >>>>> *

>>>>> * Here is an example of how an HkdfParameterSpec would be used to >>>>> initialize >>>>> * an HKDF KeyGenerator: >>>>> *

>>>>>  *     byte[] salt;
>>>>>  *     byte[] info;
>>>>>  *     SecretKey inputKey;
>>>>>  *     SecretKey resultingKey;
>>>>>  *
>>>>>  *     // salt, info and inputKey values populated with data
>>>>>  *     ...
>>>>>  *
>>>>>  *     // Get an instance of the HKDF KeyGenerator
>>>>>  *     hkdfGen = KeyGenerator.getInstance("HkdfSHA256");
>>>>>  *
>>>>>  *     // Create the spec object and use it to initialize the 
>>>>> generator.
>>>>>  *     // Ask for a 64-byte key to be output.
>>>>>  *     hkdfGen.init(new HkdfParameterSpec(inputKey, salt, info, 64));
>>>>>  *
>>>>>  *     // Generate the key
>>>>>  *     resultingKey = hkdfGen.generateKey();
>>>>>  * 
>>>>> * >>>>> * @since 9 >>>>> */ >>>>> public final class HkdfParameterSpec implements >>>>> AlgorithmParameterSpec { >>>>> >>>>> /** >>>>> * Constructs a new HkdfParameterSpec. >>>>> * >>>>> * @param inputKey the input keying material used for the >>>>> * HKDF-Extract-then-Expand operation. >>>>> * @param salt the salt value, or {@code null} if not >>>>> specified. The >>>>> * contents of the array are copied to protect against >>>>> subsequent >>>>> * modification. >>>>> * @param info optional context and application specific >>>>> information or >>>>> * {@code null} if no info data is provided. The >>>>> contents of the >>>>> * array are copied to protect against subsequent >>>>> modification. >>>>> * @param outLen the length in bytes of the output data >>>>> * >>>>> * @throws NullPointerException if {@code inputKey} is {@code >>>>> null}. >>>>> * @throws IllegalArgumentException if {@code outLen} is a >>>>> * non-positive value. >>>>> */ >>>>> public HkdfParameterSpec(SecretKey inputKey, byte[] salt, >>>>> byte[] info, >>>>> int outLen); >>>>> >>>>> /** >>>>> * Returns the Input Keying Material (IKM). >>>>> * >>>>> * @return the Input Keying Material. >>>>> */ >>>>> public SecretKey getIKM(); >>>>> >>>>> /** >>>>> * Returns the salt value. >>>>> * >>>>> * @return a copy of the salt value or {@code null} if no salt >>>>> was provided. >>>>> */ >>>>> public byte[] getSalt(); >>>>> >>>>> /** >>>>> * Returns a copy of the context and application specific >>>>> information. >>>>> * >>>>> * @return a copy of the context and application specific >>>>> information. >>>>> * This may be {@code null} or empty if no specific >>>>> information was >>>>> * provided. >>>>> */ >>>>> public byte[] getInfo(); >>>>> >>>>> /** >>>>> * Returns the length in bytes of the output key to be produced. >>>>> * >>>>> * @return the length in bytes of the output key to be produced. >>>>> */ >>>>> public int getOutputLength(); >>>>> } >>>> >>> >> > From chris.hegarty at oracle.com Wed Apr 20 18:51:54 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 20 Apr 2016 19:51:54 +0100 Subject: RFR: 8154231: Simplify access to System properties from JDK code In-Reply-To: <571795C8.2010007@oracle.com> References: <571795C8.2010007@oracle.com> Message-ID: <0E960228-9CA6-4E6F-8331-2338540B9F59@oracle.com> On 20 Apr 2016, at 15:44, Claes Redestad wrote: > Hello, > > now that the sun.security.action package is encapsulated we can simplify internal code to get System properties. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154231 > Webrev: http://cr.openjdk.java.net/~redestad/8154231/webrev.01/ This looks very nice. Did you accidentally remove supportsTransparentAuth in the unix version of NTLMAuthentication.java ? It is used reflectively by sun.net.www.protocol.http.NTLMAuthenticationProxy. Otherwise, this looks fine to me. -Chris. Note to self; I need to revisit the sun.reflect properties. > This adds a few convenience methods to GetPropertyAction[1] and GetIntegerAction[2]. Since the code calling into this can be streamlined, this leads to a net static footprint reduction of the java.base module and a tiny startup improvement. > > Thanks! > > /Claes > > [1] http://cr.openjdk.java.net/~redestad/8154231/webrev.01/src/java.base/share/classes/sun/security/action/GetPropertyAction.java.udiff.html > [2] http://cr.openjdk.java.net/~redestad/8154231/webrev.01/src/java.base/share/classes/sun/security/action/GetIntegerAction.java.udiff.html From bradford.wetmore at oracle.com Wed Apr 20 19:06:16 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 20 Apr 2016 12:06:16 -0700 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <5716D352.1020008@oracle.com> Message-ID: <5717D328.2060404@oracle.com> >> 175: Should we add DRBG:SUN as a backup for non-windows? > > If NativePRNGBlocking:SUN is not always available, yes we can. It should be available, unless someone decides to blow away /dev/(u)random. But then DRBG will have the same problem. One advantage about listing it here is that deployments know there is a good replacement if they don't like NativePRNG for some reason. I'm fine with adding or leaving alone. >> 198: Should we add a short 1-liner description for the fields? The >> variable meanings (esp pr/df) may not be obvious to a casual observer. >> For example, using these three fields as an example: >> >> mech_name: default "Hash_DRBG" >> "Hash_DRBG" | "HMAC_DRBG" | "CTR_DRBG" >> >> + The DRBG mechanism to use. >> >> pr: default "none" >> "pr_and_reseed" | "reseed_only" | "none" >> >> + Prediction resistance... >> >> df: default "use_df", only applicable to CTR_DRBG >> "use_df" | "no_df" >> >> + Derivation Function... > > Not sure about the format, how about > > # # The DRBG mechanism to use. default "Hash_DRBG" > # mech_name: > # "Hash_DRBG" | "HMAC_DRBG" | "CTR_DRBG" > > So this is double comment. Please note I also put the default value into the comment. Yes, that works. Or java-style comments /* */ or //. Maybe expanding the values too? # /* # * Prediction Resistance options # * default: "none" # */ # pr: # "pr_and_reseed" | "reseed_only" | "none" # # "pr_and_reseed" - Both Prediction Resistance and # reseeding support requested # "reseed_only" - Only reseeding support requested # "none" - Neither prediction resistance nor # reseeding support requested >> 210: Instead of pointing to 800-90A here, you should instead point to >> the Sun Provider document. That document will then reference >> 800-90A/Section 10, and will use the Standard Algorithm names that >> you have defined for these algorithms. (I assume you'll be adding >> those to the standard algorithm name doc, right? I don't recall seeing >> that part of the review yet, but maybe haven't gotten that far.) > > Yes, I will. StandardNames.html#SecureRandom =============================== NativePRNG Obtains... ... + DRBG Obtains from an 800-90A impl... SunProviders.html#SUNProvider ============================= SecureRandom: SHA1PRNG NativePRNG ... + DRBG > The standard algorithm name is only "DRBG", but here it's the DRBG algorithm > name (SHA-256 etc). Are we going to talk about this in Sun > Provider doc? Valid point, since we haven't standardized these options, then we probably shouldn't mention them in the Standard Alg names document. But we can still talk about this in the Sun Provider doc. You can make a new table and put it at the end of the Sun provider section. I suppose you could also put the expanded definitions here instead of java.security (or both). >> 229: I hadn't noticed this before, but the Security variable "drbg" >> doesn't match the style of the other variables, securerandom.* or >> otherwise. I think we should use something like either: >> >> securerandom.drbg >> securerandom.drbg.config > > Will choose "securerandom.drbg.config". Great, thanks. The CCC will need an update with the new name, or else a new CCC. There's been no votes on your "finalized" version yet, so you might be able to withdraw/resubmit. >> 229: Why an empty string here? Why not actually specify the default here >> instead of burying the default somewhere where it might changed without >> a corresponding update to this file? > > There is a small technical issue here. The problem is that the default value of algorithm_name depends on mech_name, and the default value of strength depends on algorithm_name. If we set "Hash_DRBG,SHA-256,128" here and we only change one of them, another one might be illegal. > > For example, if I want to create a SecureRandom using MoreDrbgParameters (yes, this is an internal class) with > > SecureRandom.getInstance("drbg", new MoreDrbgParameters( > null, "CTR_DRBG", "3KeyTDEA", null, false, > DrbgParameters.instantiate(-1, NONE, null))) > > it will fail, because with -1 in DrbgParameters.instantiate(), the new configuration will look like > > CTR_DRBG,3KeyTDEA,128 > > but CTR_DRBG,3KeyTDEA does not support 128 bit strength. > > I will have to use DrbgParameters.instantiate(112, NONE, null) but that does not looks comfortable because I thought the system can give me a default working strength. > > This won't be a problem if only public API is used, but I will have to redo some implementation codes. Ok. If you haven't already, please add a comment where the default value is stored to update the java.security file if this default value is ever changed. Thanks, Brad From claes.redestad at oracle.com Wed Apr 20 19:34:09 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 20 Apr 2016 21:34:09 +0200 Subject: RFR: 8154231: Simplify access to System properties from JDK code In-Reply-To: <0E960228-9CA6-4E6F-8331-2338540B9F59@oracle.com> References: <571795C8.2010007@oracle.com> <0E960228-9CA6-4E6F-8331-2338540B9F59@oracle.com> Message-ID: <5717D9B1.4070108@oracle.com> On 2016-04-20 20:51, Chris Hegarty wrote: > On 20 Apr 2016, at 15:44, Claes Redestad wrote: > >> Hello, >> >> now that the sun.security.action package is encapsulated we can simplify internal code to get System properties. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154231 >> Webrev: http://cr.openjdk.java.net/~redestad/8154231/webrev.01/ > This looks very nice. Thanks! > > Did you accidentally remove supportsTransparentAuth in the unix version > of NTLMAuthentication.java ? It is used reflectively by > sun.net.www.protocol.http.NTLMAuthenticationProxy. Otherwise, this looks > fine to me. Oops, nice catch. Updated. /Claes From rajan.halade at oracle.com Wed Apr 20 21:55:17 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Wed, 20 Apr 2016 14:55:17 -0700 Subject: RFR: [9]: 8129329: sun/security/ssl/SSLContextImpl/MD2InTrustAnchor.java failed intermittently Message-ID: <5717FAC5.9030606@oracle.com> Please provide your review of following patch to this test to start server in a separate thread, have additional logging and few other nits. Old test didn't have enough logging at the time of failure so it is not clear why client didn't connect which resulted in timeout on server accept. Bug: https://bugs.openjdk.java.net/browse/JDK-8129329 Webrev: http://cr.openjdk.java.net/~rhalade/8129329/webrev.00/ Thanks, Rajan From weijun.wang at oracle.com Wed Apr 20 23:30:53 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 21 Apr 2016 07:30:53 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <5717D328.2060404@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <5716D352.1020008@oracle.com> <5717D328.2060404@oracle.com> Message-ID: <60860A5B-85A9-436A-BA4C-34D30B7AEB1C@oracle.com> > On Apr 21, 2016, at 3:06 AM, Bradford Wetmore wrote: > > >>> 175: Should we add DRBG:SUN as a backup for non-windows? >> >> If NativePRNGBlocking:SUN is not always available, yes we can. > > It should be available, unless someone decides to blow away /dev/(u)random. But then DRBG will have the same problem. They will have to redefine securerandom.source then. > > One advantage about listing it here is that deployments know there is a good replacement if they don't like NativePRNG for some reason. Good point. > > I'm fine with adding or leaving alone. > >>> 198: Should we add a short 1-liner description for the fields? The >>> variable meanings (esp pr/df) may not be obvious to a casual observer. >>> For example, using these three fields as an example: >>> >>> mech_name: default "Hash_DRBG" >>> "Hash_DRBG" | "HMAC_DRBG" | "CTR_DRBG" >>> >>> + The DRBG mechanism to use. >>> >>> pr: default "none" >>> "pr_and_reseed" | "reseed_only" | "none" >>> >>> + Prediction resistance... >>> >>> df: default "use_df", only applicable to CTR_DRBG >>> "use_df" | "no_df" >>> >>> + Derivation Function... >> >> Not sure about the format, how about >> >> # # The DRBG mechanism to use. default "Hash_DRBG" >> # mech_name: >> # "Hash_DRBG" | "HMAC_DRBG" | "CTR_DRBG" >> >> So this is double comment. Please note I also put the default value into the comment. > > Yes, that works. Or java-style comments /* */ or //. > > Maybe expanding the values too? > > # /* > # * Prediction Resistance options > # * default: "none" > # */ > # pr: > # "pr_and_reseed" | "reseed_only" | "none" > # > # "pr_and_reseed" - Both Prediction Resistance and > # reseeding support requested > # "reseed_only" - Only reseeding support requested > # "none" - Neither prediction resistance nor > # reseeding support requested I'd keep the "pr_and_reseed" | "reseed_only" | "none" line and put all descriptions into the comment, to make this still BNF style. > >>> 210: Instead of pointing to 800-90A here, you should instead point to >>> the Sun Provider document. That document will then reference >>> 800-90A/Section 10, and will use the Standard Algorithm names that >>> you have defined for these algorithms. (I assume you'll be adding >>> those to the standard algorithm name doc, right? I don't recall seeing >>> that part of the review yet, but maybe haven't gotten that far.) >> >> Yes, I will. > > StandardNames.html#SecureRandom > =============================== > NativePRNG Obtains... > ... > + DRBG Obtains from an 800-90A impl... > > SunProviders.html#SUNProvider > ============================= > SecureRandom: SHA1PRNG > NativePRNG > ... > + DRBG > >> The standard algorithm name is only "DRBG", but here it's the DRBG algorithm > > name (SHA-256 etc). Are we going to talk about this in Sun > > Provider doc? > > Valid point, since we haven't standardized these options, then we probably shouldn't mention them in the Standard Alg names document. But we can still talk about this in the Sun Provider doc. > > You can make a new table and put it at the end of the Sun provider section. I suppose you could also put the expanded definitions here instead of java.security (or both). java.security is better. > >>> 229: I hadn't noticed this before, but the Security variable "drbg" >>> doesn't match the style of the other variables, securerandom.* or >>> otherwise. I think we should use something like either: >>> >>> securerandom.drbg >>> securerandom.drbg.config >> >> Will choose "securerandom.drbg.config". > > Great, thanks. The CCC will need an update with the new name, or else a new CCC. There's been no votes on your "finalized" version yet, so you might be able to withdraw/resubmit. Yes. > >>> 229: Why an empty string here? Why not actually specify the default here >>> instead of burying the default somewhere where it might changed without >>> a corresponding update to this file? >> >> There is a small technical issue here. The problem is that the default value of algorithm_name depends on mech_name, and the default value of strength depends on algorithm_name. If we set "Hash_DRBG,SHA-256,128" here and we only change one of them, another one might be illegal. >> >> For example, if I want to create a SecureRandom using MoreDrbgParameters (yes, this is an internal class) with >> >> SecureRandom.getInstance("drbg", new MoreDrbgParameters( >> null, "CTR_DRBG", "3KeyTDEA", null, false, >> DrbgParameters.instantiate(-1, NONE, null))) >> >> it will fail, because with -1 in DrbgParameters.instantiate(), the new configuration will look like >> >> CTR_DRBG,3KeyTDEA,128 >> >> but CTR_DRBG,3KeyTDEA does not support 128 bit strength. >> >> I will have to use DrbgParameters.instantiate(112, NONE, null) but that does not looks comfortable because I thought the system can give me a default working strength. >> >> This won't be a problem if only public API is used, but I will have to redo some implementation codes. > > Ok. If you haven't already, please add a comment where the default value is stored to update the java.security file if this default value is ever changed. A comment in java.security mentioning an internal class? Thanks Max > > Thanks, > > Brad > > > From weijun.wang at oracle.com Wed Apr 20 23:55:30 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 21 Apr 2016 07:55:30 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <57179C9B.1070904@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <5716F8E3.8030006@oracle.com> <8522950F-11B1-41EC-972C-5F9C8B24D6CE@oracle.com> <57170B3B.4020303@oracle.com> <0F1A5368-6FD4-4E25-B280-330ED7259658@oracle.com> <57179C9B.1070904@oracle.com> Message-ID: <81D437A8-DE0B-4E88-95CD-8156FBC15043@oracle.com> > On Apr 20, 2016, at 11:13 PM, Xuelei Fan wrote: > >> Really? You are worried about more than 2^64 instances of DRBG? >> > SSL/TLS considers record sequence number wrapping, too. The nonce > require at least half-strength randomness, I would like to follow this > requirement. > >> How about System.currentMillis() and an increasing long together in 16 bytes? I know currentMillis will also wrap but please. >> > I may use a 16 bytes array ( 16 * 8 * 2 = 256), and increase for each > acquire. See sun.security.ssl.Authenticator.acquireAuthenticationBytes(). I'll model after Authenticator. That would need some synchronization. > >> >>> >>>>> ------ >>>>> Section 7.2 of NIST SP 800-90Ar1 says: "The personalization string >>>>> should be unique for all instantiations of the same DRBG mechanism type". >>>>> >>>>> Please check the unique for the personalization string in the >>>>> implementation. >>>> >>>> "Should" is not "shall" (section 4, terms). >>> "should" is recommended. Better to adhere to. >>> >>>> Two other reasons: >>>> >>>> 1. Checking for uniqueness needs to save all strings in memory. >>>> >>> I see, but you need to find a smart solution. Add some randomness, or >>> make some checking. It may be a security issue if you don't check the >>> unique. >> >> I cannot add any randomness. Personalization string is provided by a user and I don't think I cannot modify it. >> > cannot->can? Yes. > >> So if we want to make it unique, it will be a requirement of users to make it unique. I don't want to enforce this because I don't think users have the capability to make it unique. > It's easy, the spec talked about some approaches. NIST SP 800-90 does > requires it to be unique, users would have found ways to make it. The > revise is highly desire it to be unique, too. My understanding, > personalization string is used to add additional randomness, so it is > highly desired to be unique. > >> Finally nobody will use a personalization string. >> >> 8.7.1 has more description on personalization strings, and it "is not considered to be a critical security parameter". >> > I'm not sure I understand the sentence: > > When used within a cryptographic module, a personalization string > is not considered to be a critical security parameter. > > The condition "when used within a cryptographic module", and the extra > word "critical" make me confused very much. My understanding is this means not choosing it correctly does not has a security impact. I am also confused on why "when used within a cryptographic module" is emphasized. > > I don't understand why use a personalization string if it does not > impact security. My suggestion to check the unique is more or less > conservative. Do you know why use personalization string for DRBG? No. I think it's something like a salt, and in DRBG salt has 2 parts: nonce is automatically provided by vendor, personalization string is provided by caller. > > It's OK to me to have no uniqueness checking if you are sure > personalization string does not impact security in our design, or you > want to delegate the responsibility to users. Both. I even dare not write "Users should provide unique personalization string" in the spec. That will scare away possible users. > >>> >>>> 2. The default is null, and all nulls are the same. Why bother checking for those non-nulls for uniqueness? >>>> >>> null is special. If "entropy+nonce+null" is safe, >>> "entropy+nonce+'constant'" may be problematic for some crypto operation. >> >> I'm not sure of this. >> > I'm not sure too, so I cannot agree with your #2 comment. ;-) It's > another more or less conservative. OK I should say I don't think so. :-) Thanks Max > > Xuelei From bradford.wetmore at oracle.com Thu Apr 21 00:03:19 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 20 Apr 2016 17:03:19 -0700 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <60860A5B-85A9-436A-BA4C-34D30B7AEB1C@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <5716D352.1020008@oracle.com> <5717D328.2060404@oracle.com> <60860A5B-85A9-436A-BA4C-34D30B7AEB1C@oracle.com> Message-ID: <571818C7.1040507@oracle.com> On 4/20/2016 4:30 PM, Wang Weijun wrote: >>>> 198: Should we add a short 1-liner description for the fields? The >>>> variable meanings (esp pr/df) may not be obvious to a casual observer. >>>> For example, using these three fields as an example: >>>> >>>> mech_name: default "Hash_DRBG" >>>> "Hash_DRBG" | "HMAC_DRBG" | "CTR_DRBG" >>>> >>>> + The DRBG mechanism to use. >>>> >>>> pr: default "none" >>>> "pr_and_reseed" | "reseed_only" | "none" >>>> >>>> + Prediction resistance... >>>> >>>> df: default "use_df", only applicable to CTR_DRBG >>>> "use_df" | "no_df" >>>> >>>> + Derivation Function... >>> >>> Not sure about the format, how about >>> >>> # # The DRBG mechanism to use. default "Hash_DRBG" >>> # mech_name: >>> # "Hash_DRBG" | "HMAC_DRBG" | "CTR_DRBG" >>> >>> So this is double comment. Please note I also put the default value into the comment. >> >> Yes, that works. Or java-style comments /* */ or //. >> >> Maybe expanding the values too? >> >> # /* >> # * Prediction Resistance options >> # * default: "none" >> # */ >> # pr: >> # "pr_and_reseed" | "reseed_only" | "none" >> # >> # "pr_and_reseed" - Both Prediction Resistance and >> # reseeding support requested >> # "reseed_only" - Only reseeding support requested >> # "none" - Neither prediction resistance nor >> # reseeding support requested > > I'd keep the > > "pr_and_reseed" | "reseed_only" | "none" > > line and put all descriptions into the comment, to make this still BNF style. Ah...something like: # /* # * Prediction Resistance options # * "pr_and_reseed" - Both Prediction Resistance and # * reseeding support requested # * "reseed_only" - Only reseeding support requested # * "none" - Neither prediction resistance nor # * reseeding support requested (DEFAULT) # */ # pr: # "pr_and_reseed" | "reseed_only" | "none" >>>> 210: Instead of pointing to 800-90A here, you should instead point to >>>> the Sun Provider document. That document will then reference >>>> 800-90A/Section 10, and will use the Standard Algorithm names that >>>> you have defined for these algorithms. (I assume you'll be adding >>>> those to the standard algorithm name doc, right? I don't recall seeing >>>> that part of the review yet, but maybe haven't gotten that far.) >>> >>> Yes, I will. >> >> StandardNames.html#SecureRandom >> =============================== >> NativePRNG Obtains... >> ... >> + DRBG Obtains from an 800-90A impl... >> >> SunProviders.html#SUNProvider >> ============================= >> SecureRandom: SHA1PRNG >> NativePRNG >> ... >> + DRBG >> >>> The standard algorithm name is only "DRBG", but here it's the DRBG algorithm >>> name (SHA-256 etc). Are we going to talk about this in Sun >>> Provider doc? >> >> Valid point, since we haven't standardized these options, then we probably shouldn't mention them in the Standard Alg names document. But we can still talk about this in the Sun Provider doc. >> >> You can make a new table and put it at the end of the Sun provider section. I suppose you could also put the expanded definitions here instead of java.security (or both). > > java.security is better. Are you going to at least list all the algorithms in SunProviders.html#SUNProvider too? >>>> 229: Why an empty string here? Why not actually specify the default here >>>> instead of burying the default somewhere where it might changed without >>>> a corresponding update to this file? >>> >>> There is a small technical issue here. The problem is that the default value of algorithm_name depends on mech_name, and the default value of strength depends on algorithm_name. If we set "Hash_DRBG,SHA-256,128" here and we only change one of them, another one might be illegal. >>> >>> For example, if I want to create a SecureRandom using MoreDrbgParameters (yes, this is an internal class) with >>> >>> SecureRandom.getInstance("drbg", new MoreDrbgParameters( >>> null, "CTR_DRBG", "3KeyTDEA", null, false, >>> DrbgParameters.instantiate(-1, NONE, null))) >>> >>> it will fail, because with -1 in DrbgParameters.instantiate(), the new configuration will look like >>> >>> CTR_DRBG,3KeyTDEA,128 >>> >>> but CTR_DRBG,3KeyTDEA does not support 128 bit strength. >>> >>> I will have to use DrbgParameters.instantiate(112, NONE, null) but that does not looks comfortable because I thought the system can give me a default working strength. >>> >>> This won't be a problem if only public API is used, but I will have to redo some implementation codes. >> >> Ok. If you haven't already, please add a comment where the default value is stored to update the java.security file if this default value is ever changed. > > A comment in java.security mentioning an internal class? Other way around. In the internal class where the defaults are set, you mention that if any of these change, you need to update the java.security accordingly. Brad From xuelei.fan at oracle.com Thu Apr 21 00:07:04 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 21 Apr 2016 08:07:04 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <81D437A8-DE0B-4E88-95CD-8156FBC15043@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <5716F8E3.8030006@oracle.com> <8522950F-11B1-41EC-972C-5F9C8B24D6CE@oracle.com> <57170B3B.4020303@oracle.com> <0F1A5368-6FD4-4E25-B280-330ED7259658@oracle.com> <57179C9B.1070904@oracle.com> <81D437A8-DE0B-4E88-95CD-8156FBC15043@oracle.com> Message-ID: <571819A8.40705@oracle.com> On 4/21/2016 7:55 AM, Wang Weijun wrote: > >> On Apr 20, 2016, at 11:13 PM, Xuelei Fan wrote: >> >>> Really? You are worried about more than 2^64 instances of DRBG? >>> >> SSL/TLS considers record sequence number wrapping, too. The nonce >> require at least half-strength randomness, I would like to follow this >> requirement. >> >>> How about System.currentMillis() and an increasing long together in 16 bytes? I know currentMillis will also wrap but please. >>> >> I may use a 16 bytes array ( 16 * 8 * 2 = 256), and increase for each >> acquire. See sun.security.ssl.Authenticator.acquireAuthenticationBytes(). > > I'll model after Authenticator. That would need some synchronization. > You have already make synchronization. >> >> It's OK to me to have no uniqueness checking if you are sure >> personalization string does not impact security in our design, or you >> want to delegate the responsibility to users. > > Both. OK, go ahead if you are sure. > I even dare not write "Users should provide unique personalization string" in the spec. That will scare away possible users. > Why scare away possible users? It is pretty easy to use unique strings. I think as spec say highly desire of unique, it would be better to make the recommendation in JDK spec. ;-) What do you mean delegate the responsibility to users (you said "Both") while you don't make the recommendation? >> >>>> >>>>> 2. The default is null, and all nulls are the same. Why bother checking for those non-nulls for uniqueness? >>>>> >>>> null is special. If "entropy+nonce+null" is safe, >>>> "entropy+nonce+'constant'" may be problematic for some crypto operation. >>> >>> I'm not sure of this. >>> >> I'm not sure too, so I cannot agree with your #2 comment. ;-) It's >> another more or less conservative. > > OK I should say I don't think so. :-) > OK, go ahead if you are sure of that. Xuelei From xuelei.fan at oracle.com Thu Apr 21 00:23:59 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 21 Apr 2016 08:23:59 +0800 Subject: RFR: [9]: 8129329: sun/security/ssl/SSLContextImpl/MD2InTrustAnchor.java failed intermittently In-Reply-To: <5717FAC5.9030606@oracle.com> References: <5717FAC5.9030606@oracle.com> Message-ID: <57181D9F.8020307@oracle.com> You made a few update of the coding style, for example line 60-62, which is different from the traditional coding. Are you following some coding conventions? As if you are already there, maybe you can do more revise. 1. although it is a test, most of the methods and fields can be private. 2. would you mind use try-with-resource for sslServerSocket, too. Thanks, Xuelei On 4/21/2016 5:55 AM, Rajan Halade wrote: > Please provide your review of following patch to this test to start > server in a separate thread, have additional logging and few other nits. > Old test didn't have enough logging at the time of failure so it is not > clear why client didn't connect which resulted in timeout on server accept. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8129329 > Webrev: http://cr.openjdk.java.net/~rhalade/8129329/webrev.00/ > > Thanks, > Rajan > > From weijun.wang at oracle.com Thu Apr 21 01:24:09 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 21 Apr 2016 09:24:09 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <571819A8.40705@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <5716F8E3.8030006@oracle.com> <8522950F-11B1-41EC-972C-5F9C8B24D6CE@oracle.com> <57170B3B.4020303@oracle.com> <0F1A5368-6FD4-4E25-B280-330ED7259658@oracle.com> <57179C9B.1070904@oracle.com> <81D437A8-DE0B-4E88-95CD-8156FBC15043@oracle.com> <571819A8.40705@oracle.com> Message-ID: > On Apr 21, 2016, at 8:07 AM, Xuelei Fan wrote: > >> I'll model after Authenticator. That would need some synchronization. >> > You have already make synchronization. You mean synchronized for instantiateIfNecessary? But this time I need to synchronize on cc which is static. > >> I even dare not write "Users should provide unique personalization string" in the spec. That will scare away possible users. >> > Why scare away possible users? It is pretty easy to use unique strings. I don't think so. For example, the NIST recommend a network card address and a library uses it as the personalization string. The NIC address is unique, but how to prevent an application call the library method twice and create 2 DRBGs with the same string? > I think as spec say highly desire of unique, it would be better to make > the recommendation in JDK spec. ;-) Because of the reason above, I don't want to put this burden on the user. > What do you mean delegate the > responsibility to users (you said "Both") while you don't make the > recommendation? The string itself is provided by user and we cannot modify it. Therefore if the string must be unique, then it's user's responsibility to make it unique and the best we can do is check and throw IAEs. --Max From xuelei.fan at oracle.com Thu Apr 21 01:46:36 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 21 Apr 2016 09:46:36 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <5716F8E3.8030006@oracle.com> <8522950F-11B1-41EC-972C-5F9C8B24D6CE@oracle.com> <57170B3B.4020303@oracle.com> <0F1A5368-6FD4-4E25-B280-330ED7259658@oracle.com> <57179C9B.1070904@oracle.com> <81D437A8-DE0B-4E88-95CD-8156FBC15043@oracle.com> <571819A8.40705@oracle.com> Message-ID: <571830FC.2010602@oracle.com> On 4/21/2016 9:24 AM, Wang Weijun wrote: > >> On Apr 21, 2016, at 8:07 AM, Xuelei Fan wrote: >> >>> I'll model after Authenticator. That would need some synchronization. >>> >> You have already make synchronization. > > You mean synchronized for instantiateIfNecessary? But this time I need to synchronize on cc which is static. > I see. >> >>> I even dare not write "Users should provide unique personalization string" in the spec. That will scare away possible users. >>> >> Why scare away possible users? It is pretty easy to use unique strings. > > I don't think so. OK. I should say I think it is pretty easy. > > For example, the NIST recommend a network card address and a library uses it as the personalization string. The NIC address is unique, but how to prevent an application call the library method twice and create 2 DRBGs with the same string? > ;-) You choose an example that the string is not unique for twice calling. >> I think as spec say highly desire of unique, it would be better to make >> the recommendation in JDK spec. ;-) > > Because of the reason above, I don't want to put this burden on the user. > I would suggest you have some words for the recommendation. ;-) But it's up to you. I would guess your final decision is that you will not say the recommendation in JDK spec. OK, go ahead. Xuelei >> What do you mean delegate the >> responsibility to users (you said "Both") while you don't make the >> recommendation? > > The string itself is provided by user and we cannot modify it. Therefore if the string must be unique, then it's user's responsibility to make it unique and the best we can do is check and throw IAEs. > > --Max > From weijun.wang at oracle.com Thu Apr 21 04:29:01 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 21 Apr 2016 12:29:01 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <5716DCD2.5050007@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <37C74246-DDE9-4DD1-ABB0-9D7B916CC7B6@oracle.com> <5716C237.10704@oracle.com> <67FC7133-4D9D-438E-BF3A-7A1CA14DCAF3@oracle.com> <5716DCD2.5050007@oracle.com> Message-ID: <1060C1E5-06E7-4847-B22F-456313720319@oracle.com> > On Apr 20, 2016, at 9:35 AM, Xuelei Fan wrote: > > On 4/20/2016 9:17 AM, Wang Weijun wrote: >> >>> On Apr 20, 2016, at 7:41 AM, Xuelei Fan wrote: >>> >>> On 4/19/2016 11:41 PM, Wang Weijun wrote: >>>>>>>> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/ >>>>>> >>>>>> Please update copyright dates. >>>>>> >>>>>> src/java.base/share/classes/java/security/Provider.java >>>>>> ------------------------------------------------------- >>>>>> 145-151: Looks like the comment are not correct. There are >>>>>> getInstance(alg,params) since JDK 1.4 (See CertStore) >>>> Yes, but in those cases, there is either getInstance(alg) or getInstance(alg,params), but not both. In SecureRandom, we are now supporting both, and a fallback is needed for those implementations that does not override new SecureRandomSpi(SRP). >>>> >>>>>> >>>>>> 156-157: Fallback change the behavior significantly. Construct with or >>>>>> without parameter can be very differently. For example, LDAP cert store >>>>>> get requested, but the CertStore.getInstane(String, >>>>>> LDAPCertStoreParameters) may not return an LDAP cert store. Can you >>>>>> make more comment why the fallback is OK? >>>> For CertStore (and Configuration and Policy), all of its implementations only support the with-arg constructor, >>> I think the constructor is not of CertStore, but of CertStoreSpi >>> implementation. >> >> Yes. >> >>> The provider implementation may support any kind of >>> constructor (implicit or explicit, intended or not). The constructor >>> should be unknown to Provider. >> >> Not sure what you mean, but Provider uses reflection to get the constructor and create new instances. By convention, when something is created via getInstance(alg), the SPI class would provide the arg-less constructor; when via getInstance(alg,params), it would provide the with-arg constructor. >> > Not sure what you mean. > > public MyCertStore extends CertStoreSpi { > > public MyCertStore() { > // whatever > // ;-) Don't ask me why this construct is necessary. > } > > public MyCertStore(XXX params) { > // throws NoSuchMethodException > // ;-) Don't ask me why throw this exception. > } > } > > newInstanceUtil(MyCertStore, ...) > > The MyCertStore() would get called, unexpectly. Am I missing something? Probably not, unless you call getInstance(arg, null). I am not sure this null will trigger some other exception along the way. OK, I admit there is a side effect here: If you design getInstance(alg,params) but params is always null, then you can only implement a constructor with no params. This is stupid and useless, but not really harmful. > >>> >>>> so NoSuchMethodException will never be thrown. Again, this fallback is only for SecureRandom now. >>>> >>>> >>> Please add more comment and control so that this only apply to SecureRandom. >> >> It already had "This is to support the enhanced SecureRandom". >> > My understanding is: this is to support the enhanced SecureRandom, and > it now applies to non-SecureRandom too. > > If it does not apply to non-SecureRandom, please add comment and update > the code accordingly. Comment added. As described above, there should not practical impact on non-SecureRandom primitives. I would revert the following line 159 throw new IllegalArgumentException(nsme); back to a simple "throw nsme". Thanks Max > > Xuelei From rajan.halade at oracle.com Thu Apr 21 05:48:45 2016 From: rajan.halade at oracle.com (Rajan Halade) Date: Wed, 20 Apr 2016 22:48:45 -0700 Subject: RFR: [9]: 8129329: sun/security/ssl/SSLContextImpl/MD2InTrustAnchor.java failed intermittently In-Reply-To: <57181D9F.8020307@oracle.com> References: <5717FAC5.9030606@oracle.com> <57181D9F.8020307@oracle.com> Message-ID: <571869BD.60508@oracle.com> Thanks for your comments! Updated webrev: http://cr.openjdk.java.net/~rhalade/8129329/webrev.01/ On 4/20/16 5:23 PM, Xuelei Fan wrote: > You made a few update of the coding style, for example line 60-62, which > is different from the traditional coding. Are you following some coding > conventions? I use netbeans auto-format which coding conventions [1] implemented. Per 4.2, general principal is to have line break before operator. [1] http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-136091.html#248 > > As if you are already there, maybe you can do more revise. > 1. although it is a test, most of the methods and fields can be private. > 2. would you mind use try-with-resource for sslServerSocket, too. These are addressed in new webrev. Thanks, Rajan > > Thanks, > Xuelei > > On 4/21/2016 5:55 AM, Rajan Halade wrote: >> Please provide your review of following patch to this test to start >> server in a separate thread, have additional logging and few other nits. >> Old test didn't have enough logging at the time of failure so it is not >> clear why client didn't connect which resulted in timeout on server accept. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8129329 >> Webrev: http://cr.openjdk.java.net/~rhalade/8129329/webrev.00/ >> >> Thanks, >> Rajan >> >> From ecki at zusammenkunft.net Thu Apr 21 08:36:23 2016 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Thu, 21 Apr 2016 10:36:23 +0200 Subject: JEP 287: SHA-3 Hash Algorithms In-Reply-To: <20160420171546.61CB4A69C2@eggemoggin.niobe.net> References: <20160420171546.61CB4A69C2@eggemoggin.niobe.net> Message-ID: <05e59737-c73c-4275-80da-d7ed7c7decac.maildroid@localhost> Hello, This is good news. Could the JEP talk about non-octet input length? If I read SHA3 correctly it will produce different hashes for 5- or 8-bit input. This means you cannot pad the input to byte boundaries and you would have to specify a length parameter to byte[] based doFinal(). Since the JEP mandates the NIST test vectors I guess the functionality cannot be skipped, as those specify odd input messages. With the recent work on HKDF is therr also a plan to provide a XOF API for sponge? Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: mark.reinhold at oracle.com To: valerie.peng at oracle.com Cc: security-dev at openjdk.java.net Sent: Mi., 20 Apr. 2016 20:46 Subject: JEP 287: SHA-3 Hash Algorithms New JEP Candidate: http://openjdk.java.net/jeps/287 - Mark From ecki at zusammenkunft.net Thu Apr 21 08:40:52 2016 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Thu, 21 Apr 2016 10:40:52 +0200 Subject: JEP 287: SHA-3 Hash Algorithms In-Reply-To: <05e59737-c73c-4275-80da-d7ed7c7decac.maildroid@localhost> References: <05e59737-c73c-4275-80da-d7ed7c7decac.maildroid@localhost> Message-ID: <2f32fffe-76f4-4cb7-9de1-a0abf271b41e.maildroid@localhost> Hello, Just noticed, the validation program allows BIT- or BYTE-only APIs, the existing ones are all BYTE constrained. That would be a good definition in the JEP: http://csrc.nist.gov/groups/STM/cavp/documents/sha3/sha3val.html Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: ecki at zusammenkunft.net To: security-dev at openjdk.java.net Sent: Do., 21 Apr. 2016 10:36 Subject: Re: JEP 287: SHA-3 Hash Algorithms Hello, This is good news. Could the JEP talk about non-octet input length? If I read SHA3 correctly it will produce different hashes for 5- or 8-bit input. This means you cannot pad the input to byte boundaries and you would have to specify a length parameter to byte[] based doFinal(). Since the JEP mandates the NIST test vectors I guess the functionality cannot be skipped, as those specify odd input messages. With the recent work on HKDF is therr also a plan to provide a XOF API for sponge? Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: mark.reinhold at oracle.com To: valerie.peng at oracle.com Cc: security-dev at openjdk.java.net Sent: Mi., 20 Apr. 2016 20:46 Subject: JEP 287: SHA-3 Hash Algorithms New JEP Candidate: http://openjdk.java.net/jeps/287 - Mark From ecki at zusammenkunft.net Thu Apr 21 08:51:18 2016 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Thu, 21 Apr 2016 10:51:18 +0200 Subject: JEP 288: Disable SHA-1 Certificates In-Reply-To: <20160420173115.E9167A69E9@eggemoggin.niobe.net> References: <20160420173115.E9167A69E9@eggemoggin.niobe.net> Message-ID: Hello, Two questions: the condition "starting on 2017-01-01" will this be part of the general algorithm deprecation or the jdkCA qualifier. I.e. if I add "SHA1" with no qualifier, will it be in effect immediatelly? The exception for timestamped code, does it also consider the actual signature hash algorithm? (Asuming SHA1 would be to weak I could also forge an backdated TS signature). I guess it is implicitely stated but not spelled out: the self signature on root certificates is not considered part of the path checking and can be SHA1, right? Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: mark.reinhold at oracle.com To: sean.mullan at oracle.com Cc: security-dev at openjdk.java.net Sent: Mi., 20 Apr. 2016 21:01 Subject: JEP 288: Disable SHA-1 Certificates New JEP Candidate: http://openjdk.java.net/jeps/288 - Mark From weijun.wang at oracle.com Thu Apr 21 08:52:38 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 21 Apr 2016 16:52:38 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <57162E25.4090805@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> Message-ID: <16410FF9-D4A6-4FA5-BCC6-F9AE5341F1F1@oracle.com> Hi All Webrev updated again at http://cr.openjdk.java.net/~weijun/8051408/webrev.11/ http://cr.openjdk.java.net/~weijun/8051408/webrev.11/spec http://cr.openjdk.java.net/~weijun/8051408/webrev.11/specdiff Changes since webrev.10: - DRBG's generateSeed() will directly read from securerandom.source and does not have the synchronized modifier anymore. This is the same as SHA1PRNG. - new Capability methods boolean supportsReseeding() and boolean supportsPredictionResistance() - The "drbg" security property is renamed to "securerandom.drbg.config". - SecureRandom#nextBytes(byte[]) will no longer throw an NPE. It's up to a provider to decide what to do. Currently, SunPKCS11 ignores it and all others throw an NPE. - Move spec in Instantiate#getCapability to Capability. - Internal nonce provider upgraded from a long to 16 bytes. - "DRBG:SUN" added as a fallback for "securerandom.strongAlgorithms" security property on *nix - Rename engineConfigure() to configure() in AbstractDrbg, and merge configureInternal() into it. - Provider#newInstanceUtil will throw NoSuchMethodException (instead of IAE) if a SecureRandom implementation has not provided a constructor with a params parameter and user is calling getInstance(alg,params). This is just an internal change since the exception thrown by getInstance() is always be NoSuchAlgorithmException. - More information in exceptions - Other refactoring Thanks Max From chris.hegarty at oracle.com Thu Apr 21 09:57:54 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 21 Apr 2016 10:57:54 +0100 Subject: RFR: 8154231: Simplify access to System properties from JDK code In-Reply-To: <5717D9B1.4070108@oracle.com> References: <571795C8.2010007@oracle.com> <0E960228-9CA6-4E6F-8331-2338540B9F59@oracle.com> <5717D9B1.4070108@oracle.com> Message-ID: <8941BC61-5F27-44EB-9C3E-FA1C0B60296E@oracle.com> On 20 Apr 2016, at 20:34, Claes Redestad wrote: > > > On 2016-04-20 20:51, Chris Hegarty wrote: >> On 20 Apr 2016, at 15:44, Claes Redestad wrote: >> >>> Hello, >>> >>> now that the sun.security.action package is encapsulated we can simplify internal code to get System properties. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154231 >>> Webrev: http://cr.openjdk.java.net/~redestad/8154231/webrev.01/ >> This looks very nice. > > Thanks! > >> >> Did you accidentally remove supportsTransparentAuth in the unix version >> of NTLMAuthentication.java ? It is used reflectively by >> sun.net.www.protocol.http.NTLMAuthenticationProxy. Otherwise, this looks >> fine to me. > > Oops, nice catch. Updated. I?m happy with this version. Thanks. -Chris. From xuelei.fan at oracle.com Thu Apr 21 13:02:17 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 21 Apr 2016 21:02:17 +0800 Subject: RFR: [9]: 8129329: sun/security/ssl/SSLContextImpl/MD2InTrustAnchor.java failed intermittently In-Reply-To: <571869BD.60508@oracle.com> References: <5717FAC5.9030606@oracle.com> <57181D9F.8020307@oracle.com> <571869BD.60508@oracle.com> Message-ID: <5718CF59.60107@oracle.com> Looks fine to me. On 4/21/2016 1:48 PM, Rajan Halade wrote: > Thanks for your comments! > > Updated webrev: http://cr.openjdk.java.net/~rhalade/8129329/webrev.01/ > > On 4/20/16 5:23 PM, Xuelei Fan wrote: >> You made a few update of the coding style, for example line 60-62, which >> is different from the traditional coding. Are you following some coding >> conventions? I don't like the conventions. We used to have "=" in the same line with the variable so that in vi/vim, you can search assignment easily ("variable ="). Thanks, Xuelei > I use netbeans auto-format which coding conventions [1] implemented. Per > 4.2, general principal is to have line break before operator. > > [1] > http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-136091.html#248 > >> >> As if you are already there, maybe you can do more revise. >> 1. although it is a test, most of the methods and fields can be private. >> 2. would you mind use try-with-resource for sslServerSocket, too. > These are addressed in new webrev. > > Thanks, > Rajan >> >> Thanks, >> Xuelei >> >> On 4/21/2016 5:55 AM, Rajan Halade wrote: >>> Please provide your review of following patch to this test to start >>> server in a separate thread, have additional logging and few other nits. >>> Old test didn't have enough logging at the time of failure so it is not >>> clear why client didn't connect which resulted in timeout on server >>> accept. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8129329 >>> Webrev: http://cr.openjdk.java.net/~rhalade/8129329/webrev.00/ >>> >>> Thanks, >>> Rajan >>> >>> > From xuelei.fan at oracle.com Thu Apr 21 13:44:58 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 21 Apr 2016 21:44:58 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <1060C1E5-06E7-4847-B22F-456313720319@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <37C74246-DDE9-4DD1-ABB0-9D7B916CC7B6@oracle.com> <5716C237.10704@oracle.com> <67FC7133-4D9D-438E-BF3A-7A1CA14DCAF3@oracle.com> <5716DCD2.5050007@oracle.com> <1060C1E5-06E7-4847-B22F-456313720319@oracle.com> Message-ID: <5718D95A.4030400@oracle.com> On 4/21/2016 12:29 PM, Wang Weijun wrote: > >> On Apr 20, 2016, at 9:35 AM, Xuelei Fan wrote: >> >> On 4/20/2016 9:17 AM, Wang Weijun wrote: >>> >>>> On Apr 20, 2016, at 7:41 AM, Xuelei Fan wrote: >>>> >>>> On 4/19/2016 11:41 PM, Wang Weijun wrote: >>>>>>>>> http://cr.openjdk.java.net/~weijun/8051408/webrev.10/ >>>>>>> >>>>>>> Please update copyright dates. >>>>>>> >>>>>>> src/java.base/share/classes/java/security/Provider.java >>>>>>> ------------------------------------------------------- >>>>>>> 145-151: Looks like the comment are not correct. There are >>>>>>> getInstance(alg,params) since JDK 1.4 (See CertStore) >>>>> Yes, but in those cases, there is either getInstance(alg) or getInstance(alg,params), but not both. In SecureRandom, we are now supporting both, and a fallback is needed for those implementations that does not override new SecureRandomSpi(SRP). >>>>> >>>>>>> >>>>>>> 156-157: Fallback change the behavior significantly. Construct with or >>>>>>> without parameter can be very differently. For example, LDAP cert store >>>>>>> get requested, but the CertStore.getInstane(String, >>>>>>> LDAPCertStoreParameters) may not return an LDAP cert store. Can you >>>>>>> make more comment why the fallback is OK? >>>>> For CertStore (and Configuration and Policy), all of its implementations only support the with-arg constructor, >>>> I think the constructor is not of CertStore, but of CertStoreSpi >>>> implementation. >>> >>> Yes. >>> >>>> The provider implementation may support any kind of >>>> constructor (implicit or explicit, intended or not). The constructor >>>> should be unknown to Provider. >>> >>> Not sure what you mean, but Provider uses reflection to get the constructor and create new instances. By convention, when something is created via getInstance(alg), the SPI class would provide the arg-less constructor; when via getInstance(alg,params), it would provide the with-arg constructor. >>> >> Not sure what you mean. >> >> public MyCertStore extends CertStoreSpi { >> >> public MyCertStore() { >> // whatever >> // ;-) Don't ask me why this construct is necessary. >> } >> >> public MyCertStore(XXX params) { >> // throws NoSuchMethodException >> // ;-) Don't ask me why throw this exception. >> } >> } >> >> newInstanceUtil(MyCertStore, ...) >> >> The MyCertStore() would get called, unexpectly. Am I missing something? > > Probably not, unless you call getInstance(arg, null). I am not sure this null will trigger some other exception along the way. > > OK, I admit there is a side effect here: If you design getInstance(alg,params) but params is always null, then you can only implement a constructor with no params. > > This is stupid and useless, but not really harmful. > Can you explain more here? Xuelei From sean.mullan at oracle.com Thu Apr 21 14:54:44 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 21 Apr 2016 10:54:44 -0400 Subject: Code Review Request 8144566, Custom HostnameVerifier disables SNI extension In-Reply-To: <57179DD2.8020508@oracle.com> References: <56642AD3.6010904@oracle.com> <56662275.5000007@oracle.com> <5666C93E.6010306@oracle.com> <569EDF8A.5000603@oracle.com> <5705932F.7030901@oracle.com> <57177FD9.3080004@oracle.com> <57179DD2.8020508@oracle.com> Message-ID: <5718E9B4.90406@oracle.com> Updated webrev looks fine to me. --Sean On 04/20/2016 11:18 AM, Xuelei Fan wrote: > Thanks for the comments, all looks reasonable to me. > > Updated webrev: http://cr.openjdk.java.net/~xuelei/8144566/webrev.02/ > > Thanks, > Xuelei > > On 4/20/2016 9:10 PM, Sean Mullan wrote: >> * SSLSocketImpl.java >> >> 2100 // ONLY used by ClientHandshaker for the server hostname during >> handshaling >> >> typo: handshaking >> >> 2114 synchronized private void useImplicitHost(boolean noSniUpdate) { >> >> the modifier order should be "private synchronized ..." >> See: http://cr.openjdk.java.net/~alundblad/styleguide/#toc-modifiers >> >> 2115 if ((host != null) && (host.length() != 0)) { >> 2116 return; >> 2117 } >> >> This seems redundant. You already check this before you call the method. >> >> 2150 // No explicitly specified hostname, no sserver name >> indication. >> >> typo: server >> >> 2610 if (sniNames.isEmpty()) { >> 2611 // need no SNI extension >> 2612 noSniExtension = true; >> 2613 } // Otherwise, need not to set noSniExtension >> 2614 >> >> Could write more compactly as: >> >> noSniExtension = sniNames.isEmpty(); >> >> same comment on lines 2620-4 >> >> * BestEffortOnLazyConnected.java, ImpactOnSNI.java >> >> 2 * Copyright (c) 2015, Oracle and/or its affiliates. All rights >> reserved. >> >> 2016 >> >> I know this is just a test, but it seems like most of these methods and >> fields should be private. >> >> --Sean >> >> On 04/06/2016 06:52 PM, Xuelei Fan wrote: >>> Ping ... >>> >>> On 1/20/2016 9:14 AM, Xuelei Fan wrote: >>>> Ping ... >>>> >>>> On 12/8/2015 8:12 PM, Xuelei Fan wrote: >>>>> Good catch! >>>>> >>>>> I copied the comment here: >>>>> >>>>> ---------- >>>>> SocketFactory sslsf = SSLSocketFactory.getDefault(); >>>>> SSLSocket ssls = (SSLSocket) sslsf.createSocket(); >>>>> ssls.connect(new InetSocketAddress( >>>>> "bugs.openjdk.java.net", 443), 0); >>>>> ssls.startHandshake(); >>>>> >>>>> No SNI is sent in this case. >>>>> ---------- >>>>> >>>>> Although this is not a regression, but this is a very good catch. >>>>> >>>>> However, I don't think the code path is a best practice, as the actual >>>>> behavior depends on providers behaviors and platform behaviors too >>>>> much. >>>>> I would recommend to use SSLParameters.setServerNames() to specify >>>>> the >>>>> server names explicitly. >>>>> >>>>> But, best effort should be made for the default server names for such >>>>> code paths. Here is the webrev that also fixes this code path issue: >>>>> >>>>> http://cr.openjdk.java.net/~xuelei/8144566/webrev.01/ >>>>> >>>>> The fix gets a little bit complicated because of the need to consider >>>>> the SSLParameters.setServerNames() impact in the code path: >>>>> >>>>> SSLSocket ssls = (SSLSocket) sslsf.createSocket(); >>>>> >>>>> // before the connection, need to consider the impact: >>>>> // Get the SSLParameters from the socket, or create on the fly? >>>>> // Call ssls.setSSLParameters(params) or not? >>>>> ssls.connect(socketAddress); >>>>> >>>>> // after the connection, need to consider the impact: >>>>> // Call ssls.setSSLParameters(params) or not? >>>>> >>>>> Basically, the implementation honors the server name set by >>>>> SSLParameters.setServerNames(). >>>>> >>>>> Bernd's comment: >>>>>> Isnt this codepath used as a workaround for dynamically disabling >>>>>> SNI? Using connect(host..) instead of SSLSocket(host) was at >>>>>> least a common, well known workaround. >>>>> If the code path is really used in practice, the >>>>> SSLParameters.setServerNames() would better be called actually to >>>>> disable SNI explicitly. >>>>> >>>>> SocketFactory sslsf = SSLSocketFactory.getDefault(); >>>>> SSLSocket ssls = (SSLSocket) sslsf.createSocket(); >>>>> ssls.connect(new InetSocketAddress( >>>>> "bugs.openjdk.java.net", 443), 0); >>>>> sslParameters.setServerNames(emptyList); >>>>> ssls.setSSLParameters(sslParameters); >>>>> ssls.startHandshake(); >>>>> >>>>> Thank you, Bernd and Brad, for the feedback. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 12/8/2015 8:21 AM, Bradford Wetmore wrote: >>>>>> >>>>>> Please see my comment in the bug. I haven't verified this, but it >>>>>> seems >>>>>> the problem might be generic to the codepath through SSLSocket, not >>>>>> just >>>>>> Https. >>>>>> >>>>>> Brad >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 12/6/2015 4:32 AM, Xuelei Fan wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review the update for JDK-8144566: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~xuelei/8144566/webrev.00/ >>>>>>> >>>>>>> For HttpsURLConnection, the server name may be set after the TLS >>>>>>> connection and handshake has been initialized. As may result in that >>>>>>> the server name does not present at TLS ClientHello messages. >>>>>>> >>>>>>> This fix resets the server name for the initialized handshake for >>>>>>> above >>>>>>> cases. >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>> >>>> >>> > From weijun.wang at oracle.com Thu Apr 21 15:10:12 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 21 Apr 2016 23:10:12 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <5718D95A.4030400@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <37C74246-DDE9-4DD1-ABB0-9D7B916CC7B6@oracle.com> <5716C237.10704@oracle.com> <67FC7133-4D9D-438E-BF3A-7A1CA14DCAF3@oracle.com> <5716DCD2.5050007@oracle.com> <1060C1E5-06E7-4847-B22F-456313720319@oracle.com> <5718D95A.4030400@oracle.com> Message-ID: > On Apr 21, 2016, at 9:44 PM, Xuelei Fan wrote: > >>> public MyCertStore extends CertStoreSpi { >>> >>> public MyCertStore() { >>> // whatever >>> // ;-) Don't ask me why this construct is necessary. >>> } >>> >>> public MyCertStore(XXX params) { >>> // throws NoSuchMethodException >>> // ;-) Don't ask me why throw this exception. >>> } >>> } >>> >>> newInstanceUtil(MyCertStore, ...) >>> >>> The MyCertStore() would get called, unexpectly. Am I missing something? >> >> Probably not, unless you call getInstance(arg, null). I am not sure this null will trigger some other exception along the way. >> >> OK, I admit there is a side effect here: If you design getInstance(alg,params) but params is always null, then you can only implement a constructor with no params. >> >> This is stupid and useless, but not really harmful. >> > Can you explain more here? The code change looks like this private static Object newInstanceUtil(final Class clazz, final Class ctrParamClz, final Object ctorParamObj) throws Exception { if (ctrParamClz == null) { Constructor con = clazz.getConstructor(); return con.newInstance(); } else { - Constructor con = clazz.getConstructor(ctrParamClz); - return con.newInstance(ctorParamObj); + try { + Constructor con = clazz.getConstructor(ctrParamClz); + return con.newInstance(ctorParamObj); + } catch (NoSuchMethodException nsme) { + if (ctorParamObj == null) { + try { + Constructor con = clazz.getConstructor(); + return con.newInstance(); + } catch (NoSuchMethodException nsme2) { + nsme.addSuppressed(nsme2); + throw nsme; + } + } else { + throw nsme; + } + } } } So in order for the arg-less constructor to be called, you will need 1. ctrParamClz != null, i.e. there is a getInstance(arg,params) API. 2. ctorParamObj == null, i.e. someone calls it with getInstance(arg) or getInstance(arg,null). 3. nsme caught, i.e. the implementation has not provided a constructor with args This matches the "otherwise" part of what I described in the @implSpec of SecureRandomSpi, which I don't suggest new implementation doing it, and is not what all non-SecureRandom implementations are doing now (they always have a constructor with args). >>> public MyCertStore(XXX params) { >>> // throws NoSuchMethodException >>> // ;-) Don't ask me why throw this exception. >>> } When this constructor throws a NoSuchMethodException, calling con.newInstance() will throw an InvocationTargetException, the NoSuchMethodException should only be caught if clazz.getConstructor(ctrParamClz) fails. From joe.darcy at oracle.com Thu Apr 21 16:31:32 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 21 Apr 2016 09:31:32 -0700 Subject: Fwd: Re: JDK 9 pre-review of JDK-6850612: Deprecate Class.newInstance since it violates the checked exception language contract In-Reply-To: <5718FEF7.1020807@oracle.com> References: <5718FEF7.1020807@oracle.com> Message-ID: <57190064.9080003@oracle.com> Security libs team, Over on core-libs, the Class.newInstance method is up for deprecation since it does not obey the general checked exceptions contract. Please review the security-libs portion of http://cr.openjdk.java.net/~darcy/6850612.0/ Generally a new variable was introduced to host the Class.newInstance call so that the minimal-size region would be affected by the @SuppressWarnings("deprecation") annotation. Thanks, -Joe -------- Forwarded Message -------- Subject: Re: JDK 9 pre-review of JDK-6850612: Deprecate Class.newInstance since it violates the checked exception language contract Date: Thu, 21 Apr 2016 09:25:27 -0700 From: joe darcy Organization: Oracle Corporation To: core-libs-dev Hello, After a generally positive reception, please review the webrev to implement the deprecation of Class.newInstance and the suppression of the resulting warnings: http://cr.openjdk.java.net/~darcy/6850612.0/ There are also some changes in the langtools repo; I'll send a separate review request for those changes to compiler-dev. I'll also forward this review request to other areas with affected code. Thanks, -Joe On 4/17/2016 10:31 AM, joe darcy wrote: > Hello, > > With talk of deprecation in the air [1], I thought it would be a fine > time to examine one of the bugs on my list > > JDK-6850612: Deprecate Class.newInstance since it violates the > checked exception language contract > > As the title of the bug implies, The Class.newInstance method > knowingly violates the checking exception contract. This has long been > documented in its specification: > >> Note that this method propagates any exception thrown by the nullary >> constructor, including a checked exception. Use of this method >> effectively bypasses the compile-time exception checking that would >> otherwise be performed by the compiler. The Constructor.newInstance >> method avoids this problem by wrapping any exception thrown by the >> constructor in a (checked) InvocationTargetException. > > Roughly, the fix would be to turn the text of this note into the > @deprecated text and to add a @Deprecated(since="9") annotation to the > method. There are a few dozen uses of the method in the JDK that would > have to be @SuppressWarning-ed or otherwise updated. > > Thoughts on the appropriateness of deprecating this method at this time? > > Comments on the bug have suggested that besides deprecating the > method, a new method on Class could be introduced, > newInstanceWithProperExceptionBehavior, that had the same signature > but wrapped exceptions thrown by the constructor call in the same way > Constructor.newInstance does. > > Thanks, > > -Joe > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040192.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Thu Apr 21 20:18:02 2016 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Thu, 21 Apr 2016 22:18:02 +0200 Subject: JEP 288: Disable SHA-1 Certificates Message-ID: <8bf68175-7eb2-47ea-a94b-cf22d9516567.maildroid@localhost> Hello, can answer the first question myself, the additional attribute deny after is not documented in the JEP but in this task: https://bugs.openjdk.java.net/browse/JDK-8153777 Gruss Bernd -----Original Message----- From: ecki at zusammenkunft.net To: security-dev at openjdk.java.net Sent: Do., 21 Apr. 2016 10:51 Subject: Re: JEP 288: Disable SHA-1 Certificates Hello, Two questions: the condition "starting on 2017-01-01" will this be part of the general algorithm deprecation or the jdkCA qualifier. I.e. if I add "SHA1" with no qualifier, will it be in effect immediatelly? The exception for timestamped code, does it also consider the actual signature hash algorithm? (Asuming SHA1 would be to weak I could also forge an backdated TS signature). I guess it is implicitely stated but not spelled out: the self signature on root certificates is not considered part of the path checking and can be SHA1, right? Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: mark.reinhold at oracle.com To: sean.mullan at oracle.com Cc: security-dev at openjdk.java.net Sent: Mi., 20 Apr. 2016 21:01 Subject: JEP 288: Disable SHA-1 Certificates New JEP Candidate: http://openjdk.java.net/jeps/288 - Mark From sean.mullan at oracle.com Thu Apr 21 20:48:06 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 21 Apr 2016 16:48:06 -0400 Subject: JEP 288: Disable SHA-1 Certificates In-Reply-To: References: <20160420173115.E9167A69E9@eggemoggin.niobe.net> Message-ID: <57193C86.1090008@oracle.com> On 04/21/2016 04:51 AM, ecki at zusammenkunft.net wrote: > Hello, > > Two questions: the condition "starting on 2017-01-01" will this be > part of the general algorithm deprecation or the jdkCA qualifier. > I.e. if I add "SHA1" with no qualifier, will it be in effect > immediatelly? We are going to add a field to the constraint that indicates the start date of the restrictions, but it is not reflected in the JEP yet. You will be able to adjust this date, or remove it, in which case the restrictions would take effect immediately. > The exception for timestamped code, does it also consider the actual > signature hash algorithm? (Asuming SHA1 would be to weak I could also > forge an backdated TS signature). That's the intention. We are still working through some of the details on that and doing more testing. > I guess it is implicitely stated but not spelled out: the self > signature on root certificates is not considered part of the path > checking and can be SHA1, right? Yes. I'll clarify that in the JEP. Thanks for the comments/questions. --Sean From valerie.peng at oracle.com Thu Apr 21 23:40:01 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 21 Apr 2016 16:40:01 -0700 Subject: JEP 287: SHA-3 Hash Algorithms In-Reply-To: <2f32fffe-76f4-4cb7-9de1-a0abf271b41e.maildroid@localhost> References: <05e59737-c73c-4275-80da-d7ed7c7decac.maildroid@localhost> <2f32fffe-76f4-4cb7-9de1-a0abf271b41e.maildroid@localhost> Message-ID: <571964D1.2020708@oracle.com> Existing security/crypto APIs in JDK are all BYTE constrained. So, the implementation will be "BYTE-only". Are you suggesting to explicitly mention in the SHA-3 JEP that these algorithm impl will be "BYTE-only"? Valerie On 4/21/2016 1:40 AM, ecki at zusammenkunft.net wrote: > Hello, > > Just noticed, the validation program allows BIT- or BYTE-only APIs, the existing ones are all BYTE constrained. That would be a good definition in the JEP: > > http://csrc.nist.gov/groups/STM/cavp/documents/sha3/sha3val.html > > Gruss > Bernd From xuelei.fan at oracle.com Fri Apr 22 05:15:58 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 22 Apr 2016 13:15:58 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <37C74246-DDE9-4DD1-ABB0-9D7B916CC7B6@oracle.com> <5716C237.10704@oracle.com> <67FC7133-4D9D-438E-BF3A-7A1CA14DCAF3@oracle.com> <5716DCD2.5050007@oracle.com> <1060C1E5-06E7-4847-B22F-456313720319@oracle.com> <5718D95A.4030400@oracle.com> Message-ID: <5719B38E.7050104@oracle.com> On 4/21/2016 11:10 PM, Wang Weijun wrote: > >> On Apr 21, 2016, at 9:44 PM, Xuelei Fan wrote: >> >>>> public MyCertStore extends CertStoreSpi { >>>> >>>> public MyCertStore() { >>>> // whatever >>>> // ;-) Don't ask me why this construct is necessary. >>>> } >>>> >>>> public MyCertStore(XXX params) { >>>> // throws NoSuchMethodException >>>> // ;-) Don't ask me why throw this exception. >>>> } >>>> } >>>> >>>> newInstanceUtil(MyCertStore, ...) >>>> >>>> The MyCertStore() would get called, unexpectly. Am I missing something? >>> >>> Probably not, unless you call getInstance(arg, null). I am not sure this null will trigger some other exception along the way. >>> >>> OK, I admit there is a side effect here: If you design getInstance(alg,params) but params is always null, then you can only implement a constructor with no params. >>> >>> This is stupid and useless, but not really harmful. >>> >> Can you explain more here? > > The code change looks like this > > private static Object newInstanceUtil(final Class clazz, > final Class ctrParamClz, final Object ctorParamObj) > throws Exception { > if (ctrParamClz == null) { > Constructor con = clazz.getConstructor(); > return con.newInstance(); > } else { > - Constructor con = clazz.getConstructor(ctrParamClz); > - return con.newInstance(ctorParamObj); > + try { > + Constructor con = clazz.getConstructor(ctrParamClz); > + return con.newInstance(ctorParamObj); > + } catch (NoSuchMethodException nsme) { > + if (ctorParamObj == null) { > + try { > + Constructor con = clazz.getConstructor(); > + return con.newInstance(); > + } catch (NoSuchMethodException nsme2) { > + nsme.addSuppressed(nsme2); > + throw nsme; > + } > + } else { > + throw nsme; > + } > + } > } > } > > So in order for the arg-less constructor to be called, you will need > > 1. ctrParamClz != null, i.e. there is a getInstance(arg,params) API. > > 2. ctorParamObj == null, i.e. someone calls it with getInstance(arg) or getInstance(arg,null). > > 3. nsme caught, i.e. the implementation has not provided a constructor with args > > This matches the "otherwise" part of what I described in the @implSpec of SecureRandomSpi, which I don't suggest new implementation doing it, and is not what all non-SecureRandom implementations are doing now (they always have a constructor with args). > Got it. Constructor-Fall-back is not common in general. I think this is only apply to SecureRandom. No problem for known engines. In the new update, there are a few description about SecureRandom, but no control code related to SecureRandom explicitly. A reader like me would have to ask a lot questions before I can understand the logic. For safe, what do you think about adding a check to make sure it is for SecureRandom only (instanceof, etc), or a note so that we don't forgot to revise if thing get changed in the future? A simple update may be: - // For other primitives using params, ctorParamObj should not + // For other known primitives using params, ctorParamObj should not // be null and nsme is thrown, just like before. Thanks, Xuelei From ecki at zusammenkunft.net Fri Apr 22 08:15:49 2016 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Fri, 22 Apr 2016 10:15:49 +0200 Subject: JEP 287: SHA-3 Hash Algorithms In-Reply-To: <571964D1.2020708@oracle.com> References: <05e59737-c73c-4275-80da-d7ed7c7decac.maildroid@localhost> <2f32fffe-76f4-4cb7-9de1-a0abf271b41e.maildroid@localhost> <571964D1.2020708@oracle.com> Message-ID: <63e4a728-0d97-4e69-a209-69aee4c8b2f6.maildroid@localhost> Hello Valerie, Yes that is what I was trying to say. :) However I dont know if this is clear to everybody else. It confused me, since most of the example testcases in the linked standard are BIT aligned, only the Validation subproject mentions the possibility of a byte mode. But I guess if the distinction is normal it does not need to be documented. On the other hand, it does not hurt to add it to the non-goals. Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: Valerie Peng To: security-dev at openjdk.java.net Sent: Fr., 22 Apr. 2016 2:40 Subject: Re: JEP 287: SHA-3 Hash Algorithms Existing security/crypto APIs in JDK are all BYTE constrained. So, the implementation will be "BYTE-only". Are you suggesting to explicitly mention in the SHA-3 JEP that these algorithm impl will be "BYTE-only"? Valerie On 4/21/2016 1:40 AM, ecki at zusammenkunft.net wrote: > Hello, > > Just noticed, the validation program allows BIT- or BYTE-only APIs, the existing ones are all BYTE constrained. That would be a good definition in the JEP: > > http://csrc.nist.gov/groups/STM/cavp/documents/sha3/sha3val.html > > Gruss > Bernd From xuelei.fan at oracle.com Fri Apr 22 13:50:45 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 22 Apr 2016 21:50:45 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <16410FF9-D4A6-4FA5-BCC6-F9AE5341F1F1@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <16410FF9-D4A6-4FA5-BCC6-F9AE5341F1F1@oracle.com> Message-ID: <571A2C35.6000304@oracle.com> On 4/21/2016 4:52 PM, Wang Weijun wrote: > http://cr.openjdk.java.net/~weijun/8051408/webrev.11/ src/java.base/share/classes/sun/security/provider/AbstractDrbg.java ========================= 343 if (debug != null) { 344 debug.println("nextBytes"); 345 } Would you mind add more information in the log except printing the method name? I like the following debug more: 588 debug.println("configure " + this + " with " + params); If you're OK with this comment, I would suggest you check the debug log message in other places and expose more debugging information. BTW, security random may be a operation used frequently. Performance is critical. Maybe, it is worthy to consider to remove some debug log if the log is not necessary for application debugging (for example HmacDrbg.status() might be not very useful once some basic tests passed). src/java.base/share/conf/security/java.security ============ 211 # algorithm_name: 212 # Any supported MessageDigest or Cipher algorithm name as described 213 # in Section 10 of SP 800-90Ar1 The reader may have to look for and look at SP 800-90r1, and may not find the right name. For example, "3 Key TDEA" is a name in NIST SP 800-90r1, we may want to use Java standard name instead. Using Java Standard names may be a little bit easier to read. A Java Doc would help to explain the supported names. 235 # securerandom.drbg.config=Hash_DRBG,SHA-1,112,none What do you think if we use SHA2 algorithm here, and probably does not support SHA-1 based DRBG as SHA-1 may be fading out slowly? src/java.base/share/classes/sun/security/provider/AbstractHashDrbg.java ====================== 42 case "SHA-1": 43 return 128; See the previous comment. Please consider whether it is OK to remove the support of SHA-1 based DRBG. src/java.base/share/classes/sun/security/provider/HashDrbg.java ====================== 37 public class HashDrbg extends AbstractHashDrbg { Instead of public, is it good to use package accessibility? Please consider other classes in the package except DRBG.java if you would like to remove the public keyword. Xuelei From ivan.gerasimov at oracle.com Fri Apr 22 17:09:34 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 22 Apr 2016 20:09:34 +0300 Subject: [jdk9] RFR: 8154947: Send empty list of authorities in CertificateRequest, if server has too many of them Message-ID: <571A5ACE.1010905@oracle.com> Hello everyone! During TLS handshake, a server may be required to send a CertificateRequest, which contains a list of authorities. If the list happens to be too long, the server is throwing an exception, indicating an overflow. It may be convenient to be able to just drop the list altogether, and let the client to choose a certificate randomly. In certain situation this may be more preferable that just block communication. Would you please help review a patch, which introduces an command-line option that controls this behavior of the server? If the approach is approved, I'll file a CCC request for that option. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8154947 WEBREV: http://cr.openjdk.java.net/~igerasim/8154947/00/webrev/ With the proposed fix all the security-related regression tests, including the modified one, passed on all supported platforms. With kind regards, Ivan From valerie.peng at oracle.com Sat Apr 23 00:30:18 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 22 Apr 2016 17:30:18 -0700 Subject: JEP 287: SHA-3 Hash Algorithms In-Reply-To: <63e4a728-0d97-4e69-a209-69aee4c8b2f6.maildroid@localhost> References: <05e59737-c73c-4275-80da-d7ed7c7decac.maildroid@localhost> <2f32fffe-76f4-4cb7-9de1-a0abf271b41e.maildroid@localhost> <571964D1.2020708@oracle.com> <63e4a728-0d97-4e69-a209-69aee4c8b2f6.maildroid@localhost> Message-ID: <571AC21A.3040705@oracle.com> Thanks for the comment. The JEP has already passed the review phase though. I will see if I can mention this somewhere. Regards, Valerie On 4/22/2016 1:15 AM, ecki at zusammenkunft.net wrote: > Hello Valerie, > > Yes that is what I was trying to say. :) However I dont know if this is clear to everybody else. > > It confused me, since most of the example testcases in the linked standard are BIT aligned, only the Validation subproject mentions the possibility of a byte mode. But I guess if the distinction is normal it does not need to be documented. On the other hand, it does not hurt to add it to the non-goals. > > Gruss > Bernd > From kungu.mjh at alibaba-inc.com Sat Apr 23 10:33:10 2016 From: kungu.mjh at alibaba-inc.com (=?UTF-8?B?6I6r566A6LGqKOWdpOiwtyk=?=) Date: Sat, 23 Apr 2016 18:33:10 +0800 Subject: =?UTF-8?B?YmFja3BvcnQgODEzMzA3MA==?= Message-ID: Hi Xuelei, Thank you for fixing https://bugs.openjdk.java.net/browse/JDK-8133070 .I have been waiting for the backport https://bugs.openjdk.java.net/browse/JDK-8146057?for months. May be I can contribute my backport to help making this happen faster. Attach please my backport.? BTW, Alibaba has signed the OCA. Regards, Jianhao Mo -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 8133070.patch Type: application/octet-stream Size: 50762 bytes Desc: not available URL: From bechler at agno3.eu Sun Apr 24 19:21:04 2016 From: bechler at agno3.eu (Moritz Bechler) Date: Sun, 24 Apr 2016 21:21:04 +0200 Subject: SSLEngine improper close invalidates session Message-ID: <571D1CA0.9080203@agno3.eu> Hi, Debugging a session resumption issue I found that SSLEngine.closeInbound will always invalidate the TLS session if no close_notify alert has been received. This behavior is no longer mandated by the TLS specification (RFC 5246 7.2.1): close_notify This message notifies the recipient that the sender will not send any more messages on this connection. Note that as of TLS 1.1, failure to properly close a connection no longer requires that a session not be resumed. This is a change from TLS 1.0 to conform with widespread implementation practice. and there are a couple of broken clients around that do not send close_notify at all (e.g. the Microsoft ones) so the current behavior will cause failed resumptions/full handshakes for these clients. Any thoughts on this? regards Moritz From bradford.wetmore at oracle.com Sun Apr 24 23:40:35 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Sun, 24 Apr 2016 16:40:35 -0700 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <16410FF9-D4A6-4FA5-BCC6-F9AE5341F1F1@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <16410FF9-D4A6-4FA5-BCC6-F9AE5341F1F1@oracle.com> Message-ID: <74879272-ac24-b389-92fd-c9242ebab8a3@oracle.com> I haven't followed much of the discussion between you/Xuelei, I will hopefully look at this tomorrow. I just started with webrev.11 and ran heads down with it for the last few days. Comments attached. Brad On 4/21/2016 1:52 AM, Wang Weijun wrote: > Hi All > > Webrev updated again at > > http://cr.openjdk.java.net/~weijun/8051408/webrev.11/ > http://cr.openjdk.java.net/~weijun/8051408/webrev.11/spec > http://cr.openjdk.java.net/~weijun/8051408/webrev.11/specdiff > > Changes since webrev.10: > > - DRBG's generateSeed() will directly read from securerandom.source and does not have the synchronized modifier anymore. This is the same as SHA1PRNG. > > - new Capability methods boolean supportsReseeding() and boolean supportsPredictionResistance() > > - The "drbg" security property is renamed to "securerandom.drbg.config". > > - SecureRandom#nextBytes(byte[]) will no longer throw an NPE. It's up to a provider to decide what to do. Currently, SunPKCS11 ignores it and all others throw an NPE. > > - Move spec in Instantiate#getCapability to Capability. > > - Internal nonce provider upgraded from a long to 16 bytes. > > - "DRBG:SUN" added as a fallback for "securerandom.strongAlgorithms" security property on *nix > > - Rename engineConfigure() to configure() in AbstractDrbg, and merge configureInternal() into it. > > - Provider#newInstanceUtil will throw NoSuchMethodException (instead of IAE) if a SecureRandom implementation has not provided a constructor with a params parameter and user is calling getInstance(alg,params). This is just an internal change since the exception thrown by getInstance() is always be NoSuchAlgorithmException. > > - More information in exceptions > > - Other refactoring > > Thanks > Max > -------------- next part -------------- Overall: ======== I apologize if some of the comments ended up on the wrong line, or my wording is unclear. I ran out of time to double check them before I had to leave today. IMPORTANT: By 800-90Ar1, sections 8.3/8.5, I don't think outputting the internal state is allowed, even for debugging. Please recheck this and let's discuss. Also by the 800-90Ar1 spec, and given that SecureRandom is supposedly serializable, I don't think serialization to recover the exact state is (or should be) allowed: The internal state for one DRBG instantiation shall not be used as the internal state for a different instantiation. I'll/we'll need to think about this some more. Now that we have a standardized/supported/documented/evaluated algorithm in the form of DRBG, I think the time has come to add our first required SecureRandom algorithm. You'll want to add some verbiage like this to SecureRandome. See MessageDigest for an example. ---begin---

Every implementation of the Java platform is required to support the following standard {@code SecureRandom} algorithm:

  • {@code DRBG}
This algorithms are described in the SecureRandom section of the Java Cryptography Architecture Standard Algorithm Name Documentation. Consult the release documentation for your implementation to see if any other algorithms are supported. ---end--- I didn't see any checks for repeated input parameters. IIRC, if you get entropy repeating, that's a failure case. I didn't see any health tests. What is your plan for that? security/java.security ====================== A couple of my previous comments were not yet addressed. Please see my previous email. 123-128: Ordering still the same. NativePRNG, SHA1PRNG, and DRBG. 181: mechanisms, Each -> mechanisms. Each 186: Applications can request for different instantiation parameters -> Applications can request different instantiation parameters 212-213: Still talks about 800-90 instead of the Sun provider document. I notice the particular value of "3KeyTDEA" is mentioned later in this file, but not the other string values. java/security/Provider.java =========================== Copyright date. I'm really tempted to file a bug to clean up the really long lines added by the lambda folks. Ugh...This make reviewing changes in frame-based webrevs hard. java/security/SecureRandom.java =============================== 54,78,406,439,513,etc: > 80 chars. I won't list any more, but expect it might occur in other files as well. 74: The effective instantiate parameters used in the instantiation must match -> The implementation's effective instantiated parameters must match 72: I don't know for sure about this, but I don't think you need a

following a

. It gives extra vertical space in the output. I noticed this several places in the resulting javadoc. 79: Not quite sure what "must be determined at the beginning..." Did you mean something like: The underlying SecureRandom impl may lazily configure itself, but the effective parameters must be determined on the first operation. 110: Please note that {@code reseed} is not always supported. -> Please note that {@code reseed} may not be supported by all SecureRandom implementations. 230/653: Just curious why you made this change. Seems like it just adds an extra stack frame. 325: I just noticed that all of the getInstance() variants have the exact same opening sentence, even when the provider parameters are different. Probably not worth changing at this point. 592: I've not be happy with the wording both here and in SecureRandomSpi. The value returned here may not be the same as the one used to instantiate it. I'm wondering if maybe something like this would be clearer: Returns the effective {@link SecureRandomParameters} that is actually used to instantiate this {@code SecureRandom}. -> Returns the effective SRP for this SecureRandom instance. 660: Reading the next method, I wonder if we should we also add a @throws NPE here for then bytes is null? It's undocumented currently. 673-677: You probably know this, but according to: http://www.oracle.com/technetwork/articles/java/index-137868.html a @param ends with a period if another sentence follows it. But it's done throughout this file, so suggest you not change all the other places in this push, but you may want to keep it consistent within your new method. 676: You mention unrecognizable/unsupported, does that include illegal? For example, if prediction_resistance_flag was not set at instantiate, but Prediction_reistance_request was set in this method? XXX: what do you do bout large size requests or things that can't be reseeded? 752: I don't think this addition made it into your CCC. java/security/SecureRandomSpi.java ================================== See comment in SecureRandom:592. java/security/DrbgParameters.java ================================= The current document is 800-90Ar1 but you later mention the older 800-90A in various places? Should probably be consisent? 47: A DRBG implementation has a configuration, including but not limited to, -> A DRBG implementation has a configuration, including but not limited to: Also in this section, you mention that a DRBG has a "configuration," but to me that immediately implies there might be an API to configure it, but that implication isn't denied until after the list appears. Maybe: The 800-90Ar1 specification allows for a variety of DRBG implementation choices, such as: entropy source DRBG mechanism .... These choices are set in each implementation and are not directly managed by the SecureRandom API. Check your DRBG provider's documentation to find an appropriate implementation for the situation. The 800-90Ar1 API does have some configurable options, such as: required security strength if prediction resistance is required Personalization and Additional Input Strings 56: *
  • highest security strength -> *
  • highest security strength. 67: Do you have these 800-90A function names backwards? Calling SecureRandom.nextBytes(byte[], SecureRandomParameters) and SecureRandom.reseed(SecureRandomParameters) map to the Reseed_function and Generate_function defined in NIST SP 800-90A, separately. 62: The word {@code Instantiate} isn't obvious that it's a nested class. Suggest a full expansion. i.e. A DRBG instance is instantiated with parameters from an Instantiate object -> A DRBG instance is instantiated with parameters from an DRBGParameters.Instantiate object For this section from 62-78, it would really help the flow if you can make the wording similar for each case: A DRBG instance can be instantiated with parameters from a DRBGParameters.Instance object...maps to the Instantiate_function A DRBG instance can be reseeded with parameters from a DRBGParameters.Reseed object...maps to the Reseed_function...calling with no parameters is equivalent to... A DRBG instance generates data with additional parameters using a DRBGParameters.NextBytes...maps to the Generate_function...calling with no parameters is equivalent to... 81: contain a constructor that has a -> contain the 1-arg SecureRandomParameter constructor that takes a 141: DrbgParameters.instantiate(112, NONE, null); -> DrbgParameters.instantiate(112, NONE, null)); 152: It is guaranteed to support 256 bits of security strength with prediction resistance turned on. -> If it successfully returns an instance, that instance is guaranteed to support 256 bits of security strength with prediction resistance available. 171: I think we should leave this part out, or at least warn that it may not be supported in all distributions. A provider is free to add other DRBG implementations with specific configurations using different SecureRandom algorithm names (for example, "Hash_DRBG/SHA-512") I really think all of the Implementations Notes here should be placed in the Sun Provider document. If you want to leave the section saying "see the DRBG section of the Sun Providers", that's fine. Some additional notes about this section whereever it ends up. In java.security, you call it "3KeyTDEA", but here the string is "DESede". Which is it? Reseeding is supported, and prediction resistance can be turned on or off. -> Both reseeding and prediction resistance are supported. 226-228: When this object is used in a SecureRandom.getInstance() call, it means the requested minimum capability. When it's used in SecureRandom.getParameters(), it means the effective capability. -> When this object is passed to a SecureRandom.getInstance() call, it is the requested minimum capability. When it's returned from SecureRandom.getParameters(), it is the effective capability. 242: What would you think of renaming the variables "requested" and "effective" here and just getting rid of "(req)" and "(eff)" in the table header completely. 354/355: I've noticed this in several files. There's a lot of spaces missing in your ? operator. For example, between "null?" and "null:". Another example: (isPr?"pr_and_reseed":(supportReseed?"reseed_only":"none") Should be: return (cond ? ret1 : ret2); 472: @throws NullPointerException if {@code capacity} is {@code null}. -> @throws NullPointerException if {@code capability} is {@code null}. java/security/SecureRandomParameters.java ========================================= 31: A specific type of {@code SecureRandom} can implement this interface. Don't you mean that different types of *SecureRandomParameter* can be created and passed to SR's? I'm not crazy about the following verbiage, but something like: Some SecureRandom implementations might require additional configurational/operational parameters. Objects of classes which implement this interface can be passed to those implementations that support them. sun/security/provider/AbstractDrbg.java ======================================= 98,368,369, etc. Lines > 80. This is throughout your code. Hard to read on a laptop with narrow display. 64: Is this serialVersionUID a placeholder, or the final value? 94: A final constant string should be cap'd. DEFAULTSTRENGTH 107: In 800-90Ar1, many of the variables have specific names. They don't generally follow our conventions, but would you consider using a close derivative? For example, highestSupportedSecurityStrength and maxPersonalizationStringLength? That would make a little more clear how the DRBG variables map to the implementation. I notice you've used those names in other places, but wasn't sure if that was by design or not. 145: Should you mention that MAX_INT is actually smaller than the amount allowed by the various algorithms? Or should the implementation be long-based throughout? 235: The prediction resistance flag used by this instance. -> The entropySource used by this instance. 348: It would be nice if you could provide a mapping comment to the steps in 800-90Ar1. e.g. // 3. If requested_security_strength > the security_strength // indicated in the internal state, then return if (dp.getStrength() > strength) { throw new IllegalArgumentException("strength too high: " + dp.getStrength()); } // 4. If the length of the additional_input > max_additional... // ... byte[] ai = dp.getAdditionalInput(); if (ai != null && ai.length > maxAiLength) { It looks like you do that around line 650 with the Instantiate procedure and in other parts of the code, but not here and some other place IIRC. Also, there are several places here and in other files (DRBG.java) where you do multiple function calls where the return value won't be changing: first to check legality, then to actually capture/use the value. See lines 348/365/366. Can't these calls be combined? 355: Are you somewhere calling this DRBG.nextBytes() multiple times if the output size is too big to be handled by a single DRBG call? 460: would you want to call security "min_entropy" to match the spec? 483: Can't this be final? Netbeans is complaining about a non-final defaultES at 503. Also private? 551: What is register() used for? 605: It would be nice if you could provide a mapping to the steps in 800-90Ar1. 642: We have this problem in JSSE: in various places, you have debug strings like "instantiate", but in a multi-SR environment, you'll have no idea which one is in play. Do you want to use '"instantiate" + this'? 674: can be final. Do you want to use the ES to generate an initial value for the monotonically increasing sequence number? 692: Isn't there some preexisting code somewhere we can use? This seems like a common need, and I recall having written something similar a while ago. sun/security/provider/AbstractHashDrbg.java =========================================== 129: Can you make this into a single debug output line? Otherwise you run the risk of interspersed data. We have this problem in JSSE all the time. sun/security/provider/ByteArrayAccess.java ========================================== Ok. sun/security/provider/CtrDrbg.java ================================== By 8.3/8.5, I don't think outputting V/C is allowed, even in debug. Please recheck this. 40: Constants should be cap'd. Also, can this be private? 51: transient here? 54: Can this be private? 88: Add @overrides? 141: AES-192/256 is indeed supported, it's just that the unlimited policy files aren't installed. I would suggest a better error message here, like "algorithm not available (policy)" or something similar. 164: TODO? 355: Couldn't addBytes() here and in HashDrbg be refactored into a common routine in AbstractDrbg? 384: Isn't additional_input supposed to be 0^seedlen if AI == null? 422: What is this for? sun/security/provider/DRBG.java =============================== 60: A final constant string should be cap'd. propName -> PROPNAME 62: Is this serialVersionUID a placeholder, or the final value? I've noticed it in other places too. 93: space missing "part:" 129: I mentioned this in a private email, but will mention it here for the record. There's a bug here in the parsing code. You go right to checking strength, instead of determining whether this part is an algorithm or a strength. Note if you reverse the order of algorithm and strength: Testing hash_drbg,128,sha-512,Pr_and_Reseed with null... Result NSAE Exception in thread "main" java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: DRBG, provider: SUN, class: sun.security.provider.DRBG) ...deleted... Caused by: java.lang.IllegalArgumentException: strength cannot be provided more than once in securerandom.drbg.config Caused by: java.lang.IllegalArgumentException: strength cannot be provided more than once in securerandom.drbg.config 147: Under what conditions would you get a MoreDrbgParameters passed here? I'm guessing this is for testing? Please add a comment to indicate this. 170: To avoid a double call here, might suggest: tmp = dp.getStrength(); if (tmp != -1) { strength = tmp; } sun/security/provider/EntropySource.java ======================================== 37/43: Do you want to call this parameter "security_strength" to be consistent with 800-90A? sun/security/provider/HashDrbg.java =================================== By 8.3/8.5, I don't think outputting V/C is allowed, even in debug. Please recheck this. 59: Should this check even be here, or maybe a RuntimeException? By this point, we should have a valid value here. Otherwise, instantiateAlgorithm is going to choke later on. 136: I really don't think you should be outputing V/C here. See comment at top. 154: space style. 197: A quick comment here would be nice. sun/security/provider/HmacDrbg.java =================================== By 8.3/8.5, I don't think outputting V/C is allowed, even in debug. Please recheck this. 76: Don't you need to re-init() this again? It's supposed to be the current value of K. sun/security/provider/MoreDrbgParameters.java ============================================= 46: the {@link EntropySource} to use, set to {@code null} and a default entropy... Did you mean: the {@link EntropySource} to use. If set to null, a default... 49/51: Same comment. 48: if null, does a default get selected? sun/security/provider/SHA5.java =============================== Ok. I verified the initial values were copied correctly. sun/security/provider/SunEntries.java ===================================== OK. OID values are correct. sun/security/util/Debug.java ============================ Ok com/sun/crypto/provider/HmacCore.java ===================================== OK. com/sun/crypto/provider/SunJCE.java =================================== I wasn't able to find any HmacSHA512/* OIDs at oid-info.com. http://oid-info.com/get/1.2.840.113549.2 Just the ones for MessageDigest, which you have in SunEntries. ------------ I didn't get too much into the tests, but I didn't see much exercising of the actual DRBG's new functions. nextBytes(..., SRP), reseed(SRP), etc. There were some that exercised the interface, but not the actual new code Did I miss them? test/java/security/SecureRandom/Serialize.java ============================================== test/com/sun/crypto/provider/Mac/HmacSHA512.java ================================================ test/sun/security/provider/MessageDigest/SHA512.java ==================================================== test/sun/security/provider/SecureRandom/AbstractDrbgSpec.java ============================================================= 255: maximum strength is 192 -> Maximum strength is 128 test/sun/security/provider/SecureRandom/AutoReseed.java ======================================================= test/sun/security/provider/SecureRandom/CommonSeeder.java ========================================================= test/sun/security/provider/SecureRandom/DRBGAlg.java ==================================================== test/sun/security/provider/SecureRandom/SelfSeed.java ===================================================== test/sun/security/provider/SecureRandom/StrongSeedReader.java ============================================================= OK From weijun.wang at oracle.com Mon Apr 25 04:13:40 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 25 Apr 2016 12:13:40 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <74879272-ac24-b389-92fd-c9242ebab8a3@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <16410FF9-D4A6-4FA5-BCC6-F9AE5341F1F1@oracle.com> <74879272-ac24-b389-92fd-c9242ebab8a3@oracle.com> Message-ID: <1DA968F9-2A7B-4C77-AAA0-2280E9BB94E1@oracle.com> >> http://cr.openjdk.java.net/~weijun/8051408/webrev.11/ >> http://cr.openjdk.java.net/~weijun/8051408/webrev.11/spec >> http://cr.openjdk.java.net/~weijun/8051408/webrev.11/specdiff Thanks for the review. I copied your DRBG.txt below with my comments. Most are accepted, some I mentioned my previous thoughts. Some needs clarification or discussion (does not mean I don't accept them), tagged with *** so you can search for them. BTW, the CAVP test is on test/closed. I'll send you a private mail. > > Overall: > ======== > > IMPORTANT: By 800-90Ar1, sections 8.3/8.5, I don't think outputting the > internal state is allowed, even for debugging. Please recheck this and > let's discuss. *** Not very sure. Someone can always use reflection to look at the internal states. Well the main reason I printed out the internal state is to compare it with the CAVP text file when there is something wrong. Surely I can remove them now. > > Also by the 800-90Ar1 spec, and given that SecureRandom is supposedly > serializable, I don't think > serialization to recover the exact state is (or should be) allowed: > > The internal state for one DRBG instantiation shall not be used as > the internal state for a different instantiation. > > I'll/we'll need to think about this some more. *** Since after s11n/des11n it's *another* instance, seems we should not remember the states. A consequence is that it has to be reinitialized. > > Now that we have a standardized/supported/documented/evaluated algorithm > in the form of DRBG, I think the time has come to add our first required > SecureRandom algorithm. You'll want to add some verbiage like this to > SecureRandome. See MessageDigest for an example. Good. > > ---begin--- >

    Every implementation of the Java platform is required to support > the following standard {@code SecureRandom} algorithm: >

      >
    • {@code DRBG}
    • >
    > This algorithms are described in the "{@docRoot}/../technotes/guides/security/StandardNames.html#SecureRandom"> > SecureRandom section of the > Java Cryptography Architecture Standard Algorithm Name Documentation. > Consult the release documentation for your implementation to see if any > other algorithms are supported. > ---end--- > > I didn't see any checks for repeated input parameters. IIRC, if you get > entropy repeating, that's a failure case. *** I thought that would be health check for an entropy source. How do you expect me to check it? A cache for recent inputs? Not very practical. > > I didn't see any health tests. What is your plan for that? *** If by health test your means the CAVP known-output tests, I am going to put it into test/closed since it's reading a huge (13MB) external file and should be stored on an artifact server. That said, I'll be happy to extract a subset of it and make it a public test. > > > security/java.security > ====================== > A couple of my previous comments were not yet addressed. Please see my > previous email. > > 123-128: Ordering still the same. > NativePRNG, SHA1PRNG, and DRBG. I didn't realize your were asking me to be consistent. I only updated the first appearance. Will fix. > > 181: > mechanisms, Each > -> > mechanisms. Each Ha. I changed ", e" to ", E". Will fix. > > 186: > Applications can request for different instantiation parameters > -> > Applications can request different instantiation parameters I thought "request for" is a correct phrase. Will fix. > > 212-213: Still talks about 800-90 instead of the Sun provider document. *** How just list all names here? I already listed all mech names. > I notice the particular value of "3KeyTDEA" is mentioned later in this > file, but not the other string values. CtrDrbg.java. > > > java/security/Provider.java > =========================== > Copyright date. Already updated. You reading webrev.10? > > I'm really tempted to file a bug to clean up the really long lines added > by the lambda folks. Ugh...This make reviewing changes in frame-based > webrevs hard. There aren't many in this file. I'll break them. > > > java/security/SecureRandom.java > =============================== > 54,78,406,439,513,etc: > 80 chars. I won't list any more, but expect it > might occur in other files as well. You expect me to be 100% strict with 80 chars. Will do. > > 74: > The effective instantiate parameters used in the instantiation must match > -> > The implementation's effective instantiated parameters must match OK. > > 72: I don't know for sure about this, but I don't think you need a

    > following a

    . It gives extra vertical space in the output. > I noticed this several places in the resulting javadoc. I don't see any visual difference between the 2 styles. Turns out the extra space is a empty line in pre (try Select All and you'll see). I'll put at the end of the previous line. > > 79: Not quite sure what "must be determined at the beginning..." > Did you mean something like: > > The underlying SecureRandom impl may lazily configure itself, > but the effective parameters must be determined on the first > operation. I meant although the DRBG is only instantiated at the 1st nextBytes(), the effective instantiate parameters are determined when getInstance() returns one. Therefore whenever you call getParameters() you get the same result. Your "the first operation" is quite vague, I'll use "after it's created". Each DRBG is created with its constructor with the SRP parameter, so this is precise and correct. > > 110: > Please note that {@code reseed} is not always supported. > -> > Please note that {@code reseed} may not be supported by all SecureRandom > implementations. OK. > > 230/653: Just curious why you made this change. Seems like it just adds an > extra stack frame. I will revert the changes. Cannot remember why for 230. For 653, I wanted to express that one method is equivalent to calling another method with certain argument. > > 325: I just noticed that all of the getInstance() variants have the exact > same opening sentence, even when the provider parameters are different. > Probably not worth changing at this point. Yes, I was following the existing wording. > > 592: I've not be happy with the wording both here and in SecureRandomSpi. > The value returned here may not be the same as the one used to instantiate > it. > > I'm wondering if maybe something like this would be clearer: > > Returns the effective {@link SecureRandomParameters} > that is actually used to instantiate this {@code SecureRandom}. > -> > Returns the effective SRP for this SecureRandom instance. OK. In fact, I was deliberately trying to express the meaning that the returned value here could be different from the one passed into getInstance(). But maybe as your suggested, not mentioning instantiate at all is clearer. Anyway I think I've emphasized this many times in other places. > 660: Reading the next method, I wonder if we should we also add a > @throws NPE here for then bytes is null? It's undocumented currently. *** Wow. It was there and Xuelei suggested me removing it. The reason is that SunPKCS11's nextBytes happily accepted null (and ignore it). Although I see no benefits doing that (SunPKCS11 has not use this chance to do any instantiate work etc), maybe it's safe to not require non-null here. > > 673-677: You probably know this, but according to: > > http://www.oracle.com/technetwork/articles/java/index-137868.html > > a @param ends with a period if another sentence follows it. But > it's done throughout this file, so suggest you not change all the other > places in this push, but you may want to keep it consistent within > your new method. *** Please confirm if I understand correctly: No period if it's only a clause or an expression. So I should remove the period at the end of 674. > > 676: You mention unrecognizable/unsupported, does that include > illegal? For example, if prediction_resistance_flag was not set at > instantiate, but Prediction_reistance_request was set in this method? I'll add "illegal", although "unsupported" kinds implies it. Otherwise, what is the difference of "unrecognizable" and "unsupported"? We know this parameter defined for DRBG but we haven't yet supported it? > > XXX: what do you do bout large size requests or things that can't be > reseeded? This won't happen in our implementation so I haven't mentioned them. For large size nextBytes() it's an implementation's duty to generate again and again until all is obtained. *** I am not sure what you are asking of reseeding. UnsupportedOperationException not enough? > > 752: I don't think this addition made it into your CCC. *** The 3rd part of spec in CCC only mentions changes related to DRBG. I think this one is trivial and should not be included there. > > > java/security/SecureRandomSpi.java > ================================== > See comment in SecureRandom:592. Got it. > > > java/security/DrbgParameters.java > ================================= > The current document is 800-90Ar1 but you later mention the older 800-90A in > various places? Should probably be consistent? Will use Ar1. Sometimes I think Ar1 is just a version name, and A is still the standard. > > 47: > A DRBG implementation has a configuration, including but not limited to, > -> > A DRBG implementation has a configuration, including but not limited to: OK. > > Also in this section, you mention that a DRBG has a "configuration," > but to me that immediately implies there might be an API to configure it, > but that implication isn't denied until after the list appears. Maybe: > > The 800-90Ar1 specification allows for a variety of DRBG > implementation choices, such as: > > entropy source > DRBG mechanism > .... > > These choices are set in each implementation and are not directly > managed by the SecureRandom API. Check your DRBG provider's > documentation to find an appropriate implementation for the situation. > > The 800-90Ar1 API does have some configurable options, such as: > > required security strength > if prediction resistance is required > Personalization and Additional Input Strings OK. > > 56: > *
  • highest security strength > -> > *
  • highest security strength. OK. > > 67: Do you have these 800-90A function names backwards? > > Calling SecureRandom.nextBytes(byte[], SecureRandomParameters) and > SecureRandom.reseed(SecureRandomParameters) map to the Reseed_function > and Generate_function defined in NIST SP 800-90A, separately. Ah. > > 62: The word {@code Instantiate} isn't obvious that it's a nested class. > Suggest a full expansion. i.e. > > A DRBG instance is instantiated with parameters from an > Instantiate object > -> > A DRBG instance is instantiated with parameters from an > DRBGParameters.Instantiate object OK. > > For this section from 62-78, it would really help the flow if you can > make the wording similar for each case: > > A DRBG instance can be instantiated with parameters from a > DRBGParameters.Instance object...maps to the Instantiate_function > > A DRBG instance can be reseeded with parameters from a > DRBGParameters.Reseed object...maps to the Reseed_function...calling > with no parameters is equivalent to... > > A DRBG instance generates data with additional parameters using a > DRBGParameters.NextBytes...maps to the Generate_function...calling > with no parameters is equivalent to... OK. > > 81: > contain a constructor that has a > -> > contain the 1-arg SecureRandomParameter constructor that takes a OK. > > 141: > DrbgParameters.instantiate(112, NONE, null); > -> > DrbgParameters.instantiate(112, NONE, null)); Oops. > > 152: > It is guaranteed to support 256 bits of security strength with > prediction resistance turned on. > -> > If it successfully returns an instance, that instance is guaranteed > to support 256 bits of security strength with prediction resistance > available. OK. > > 171: I think we should leave this part out, or at least warn that it > may not be supported in all distributions. > > A provider is free to add other DRBG implementations with specific > configurations using different SecureRandom algorithm names (for > example, "Hash_DRBG/SHA-512") Leave this out. I couldn't resist making suggestions on these old names that are removed now. > > I really think all of the Implementations Notes here should be placed > in the Sun Provider document. If you want to leave the section saying > "see the DRBG section of the Sun Providers", that's fine. Some > additional notes about this section whereever it ends up. Correct. The @implSpec was written to comply with 800-90Ar1's 11.1 and will be places in the Sun Provider doc. I was planning to add a reference here after the target is complete. > > In java.security, you call it "3KeyTDEA", but here the string is > "DESede". Which is it? I'll use "3KeyTDEA (known as DEDede in JCE)". > > Reseeding is supported, and prediction resistance can be turned on or > off. > -> > Both reseeding and prediction resistance are supported. OK. > > 226-228: > When this object is used in a SecureRandom.getInstance() call, it means > the requested minimum capability. When it's used in > SecureRandom.getParameters(), it means the effective capability. > -> > When this object is passed to a SecureRandom.getInstance() call, it is > the requested minimum capability. When it's returned from > SecureRandom.getParameters(), it is the effective capability. Good. > > 242: What would you think of renaming the variables "requested" and > "effective" here and just getting rid of "(req)" and "(eff)" in the table > header completely. Sure. > > 354/355: I've noticed this in several files. There's a > lot of spaces missing in your ? operator. For example, > between "null?" and "null:". Another example: > (isPr?"pr_and_reseed":(supportReseed?"reseed_only":"none") > > Should be: > return (cond ? ret1 : ret2); OK. > > 472: > @throws NullPointerException if {@code capacity} is {@code null}. > -> > @throws NullPointerException if {@code capability} is {@code null}. Oops. > > > java/security/SecureRandomParameters.java > ========================================= > 31: > A specific type of {@code SecureRandom} can implement this interface. > > Don't you mean that different types of *SecureRandomParameter* can be > created and passed to SR's? Yes, different for DRBG and NRBG, for example. > I'm not crazy about the following verbiage, > but something like: > > Some SecureRandom implementations might require additional > configurational/operational parameters. Objects of classes which > implement this interface can be passed to those implementations that > support them. Good. > > > sun/security/provider/AbstractDrbg.java > ======================================= > 98,368,369, etc. Lines > 80. This is throughout your code. Hard to > read on a laptop with narrow display. I'll shorted the comments, but sometimes for codes I am OK with a little more than 80 chars. I can make it strict. > > 64: Is this serialVersionUID a placeholder, or the final value? *** My understanding is that serialVersionUID calculated with serialno is to be compatible with an earlier version that has no this field. In a new file with serialVersionUID, it can anything and I prefer one that is easy to understand. > > 94: A final constant string should be cap'd. DEFAULT STRENGTH Good. > > 107: In 800-90Ar1, many of the variables have specific names. They > don't generally follow our conventions, but would you consider using a > close derivative? For example, highestSupportedSecurityStrength and > maxPersonalizationStringLength? That would make a little more clear > how the DRBG variables map to the implementation. I notice you've used > those names in other places, but wasn't sure if that was by design or > not. I use the name in 800-90Ar1 in comments but prefer a more-Java-like variable name. If you like I can be more close. > > 145: Should you mention that MAX_INT is actually smaller than the > amount allowed by the various algorithms? Or should the implementation > be long-based throughout? *** Since a Java array can only holds MAX_INT of elements, we won't be able to support long. I can add an explanation. > > 235: > The prediction resistance flag used by this instance. > -> > The entropySource used by this instance. Oops. > > 348: It would be nice if you could provide a mapping comment to the steps in > 800-90Ar1. e.g. > > // 3. If requested_security_strength > the security_strength > // indicated in the internal state, then return > if (dp.getStrength() > strength) { > throw new IllegalArgumentException("strength too high: " > + dp.getStrength()); > } > > // 4. If the length of the additional_input > max_additional... > // ... > byte[] ai = dp.getAdditionalInput(); > if (ai != null && ai.length > maxAiLength) { > > It looks like you do that around line 650 with the Instantiate procedure > and in other parts of the code, but not here and some other place IIRC. Sure. > > Also, there are several places here and in other files (DRBG.java) > where you do multiple function calls where the return value won't be > changing: first to check legality, then to actually capture/use the value. > See lines 348/365/366. Can't these calls be combined? Yes I can. As you see, when the return value is a cloned array (line 359) I only call once. When it's a primitive I think an extra call is not too bad. > > 355: Are you somewhere calling this DRBG.nextBytes() multiple times if > the output size is too big to be handled by a single DRBG call? No. It should but since here maxNbLength is MAX_INT I omit the call. *** I created these maxNbLength/maxAiLength/maxPsLength variables to be more aligned with pseudo codes in 800-90Ar1, but honestly they have no real use in the impl and I sometimes ignore it. > > 460: would you want to call security "min_entropy" to match the spec? Sure, and I will change min/max there to minLength/maxLength. > > 483: Can't this be final? Netbeans is complaining about a non-final > defaultES at 503. Also private? Yes and yes. > > 551: What is register() used for? Useless. I was doing an experiment with lines in SunEntries new HashDRBG(null).register(map) and those attributes can be use by an app to detect capabilities. > > 605: It would be nice if you could provide a mapping to the steps in > 800-90Ar1. Good. > > 642: We have this problem in JSSE: in various places, you have debug > strings like "instantiate", but in a multi-SR environment, you'll have > no idea which one is in play. Do you want to use '"instantiate" + this'? *** Is "this" enough? this.toString() shows the configuration. Do you want System.identityHashCode()? I can add it right into toString(). > > 674: can be final. Do you want to use the ES to generate an initial > value for the monotonically increasing sequence number? *** I don't think it's necessary, as long as it changes with duplication. > > 692: Isn't there some preexisting code somewhere we can use? This seems > like a common need, and I recall having written something similar a > while ago. No colon/space/newline? I don't know. > > sun/security/provider/AbstractHashDrbg.java > =========================================== > 129: Can you make this into a single debug output line? Otherwise you > run the risk of interspersed data. We have this problem in JSSE all the > time. > I can. > > sun/security/provider/ByteArrayAccess.java > ========================================== > Ok. > > > sun/security/provider/CtrDrbg.java > ================================== > By 8.3/8.5, I don't think outputting V/C is allowed, even in debug. > Please recheck this. > > 40: Constants should be cap'd. Also, can this be private? Yes and yes. > > 51: transient here? *** Already transient. > > 54: Can this be private? Yes. > > 88: Add @overrides? Yes. > > 141: AES-192/256 is indeed supported, it's just that the unlimited > policy files aren't installed. I would suggest a better error message > here, like "algorithm not available (policy)" or something similar. OK. "algorithm not available (because policy)". I recently read a article about modern English do not use "because of" anymore. > > 164: TODO? *** In Table 3 of 800-90Ar1, ctrLen can be between 4 and blocklen. I was not sure if I can hard code it. > > 355: Couldn't addBytes() here and in HashDrbg be refactored into a > common routine in AbstractDrbg? I think so. I spent some time optimizing HashDrbg and has not touched CtrDrbg. > > 384: Isn't additional_input supposed to be 0^seedlen if AI == null? Yes, see 414. Maybe I didn't want to touch the input argument. But since I already changed them on 379/381 I can do it. > > 422: What is this for? SecretKeySpec for DESede use 24 bytes but k in CTR_DRBG is 21 bytes. > > > sun/security/provider/DRBG.java > =============================== > 60: A final constant string should be cap'd. propName -> PROPANE OK. > > 62: Is this serialVersionUID a placeholder, or the final value? I've > noticed it in other places too. See previous explanation. > > 93: space missing "part:" Do we need a space here? *** BTW, where is a modern coding style guide? > > 129: I mentioned this in a private email, but will mention it here > for the record. There's a bug here in the parsing code. You go right > to checking strength, instead of determining whether this part is an > algorithm or a strength. Note if you reverse the order of algorithm > and strength: > > Testing hash_drbg,128,sha-512,Pr_and_Reseed with null... > Result NSAE > Exception in thread "main" java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: DRBG, provider: SUN, class: sun.security.provider.DRBG) > ...deleted... > Caused by: java.lang.IllegalArgumentException: strength cannot be provided more than once in securerandom.drbg.config > > Caused by: java.lang.IllegalArgumentException: strength cannot be > provided more than once in securerandom.drbg.config Yes. > > 147: Under what conditions would you get a MoreDrbgParameters passed > here? I'm guessing this is for testing? Please add a comment to > indicate this. Yes. > > 170: To avoid a double call here, might suggest: > > tmp = dp.getStrength(); > if (tmp != -1) { > strength = tmp; > } Yes. I've explained why I did that in a previous comment. > > > sun/security/provider/EntropySource.java > ======================================== > 37/43: Do you want to call this parameter "security_strength" to be > consistent with 800-90A? OK. > > > sun/security/provider/HashDrbg.java > =================================== > By 8.3/8.5, I don't think outputting V/C is allowed, even in debug. > Please recheck this. > > 59: Should this check even be here, or maybe a RuntimeException? By this > point, we should have a valid value here. Otherwise, instantiateAlgorithm > is going to choke later on. Yes you are right, no need to check. Before the getInstance(alg,params) change I allow a separate configure() call, and before this method or nextBytes is called, algorithm is null. If a DRBG instance is serialized and deserialized initEngine() should not try to init an engine. This is no more true now. > > 136: I really don't think you should be outputing V/C here. See comment > at top. > > 154: space style. Sometimes I think too many spaces do not look good. I'll be strict from now on. I promise. > > 197: A quick comment here would be nice. Is it necessary? *** In fact, I am wondering if I should use long, otherwise reseedCounter could be negative. > > > sun/security/provider/HmacDrbg.java > =================================== > By 8.3/8.5, I don't think outputting V/C is allowed, even in debug. > Please recheck this. > > 76: Don't you need to re-init() this again? It's supposed to be the > current value of K. *** In Step 2, v is updated but not k. > > > sun/security/provider/MoreDrbgParameters.java > ============================================= > 46: > the {@link EntropySource} to use, set to {@code null} > and a default entropy... > > Did you mean: > > the {@link EntropySource} to use. If set to null, a default... Yes. > > 49/51: Same comment. OK. > > 48: if null, does a default get selected? Yes, the one in the security property. I should also mentioned when passed into HashDrbg/HmacDrbg/CtrDrbg it is ignored. > > > sun/security/provider/SHA5.java > =============================== > Ok. > > I verified the initial values were copied correctly. > > > sun/security/provider/SunEntries.java > ===================================== > OK. OID values are correct. > > > sun/security/util/Debug.java > ============================ > Ok > > > com/sun/crypto/provider/HmacCore.java > ===================================== > OK. > > > com/sun/crypto/provider/SunJCE.java > =================================== > I wasn't able to find any HmacSHA512/* OIDs at oid-info.com. > > http://oid-info.com/get/1.2.840.113549.2 > > Just the ones for MessageDigest, which you have in SunEntries. Neither can I find in other places. I even asked on Stack Overflow http://stackoverflow.com/questions/33605411/oids-for-hmacsha512-224-and-hmacsha512-256 > > > ------------ > > I didn't get too much into the tests, but I didn't see much exercising > of the actual DRBG's new functions. nextBytes(..., SRP), reseed(SRP), > etc. There were some that exercised the interface, but not the actual > new code Did I miss them? In test/closed. > > > test/java/security/SecureRandom/Serialize.java > ============================================== > > > test/com/sun/crypto/provider/Mac/HmacSHA512.java > ================================================ > > > test/sun/security/provider/MessageDigest/SHA512.java > ==================================================== > > > test/sun/security/provider/SecureRandom/AbstractDrbgSpec.java > ============================================================= > 255: > maximum strength is 192 > -> > Maximum strength is 128 Yes. > > > test/sun/security/provider/SecureRandom/AutoReseed.java > ======================================================= > > > test/sun/security/provider/SecureRandom/CommonSeeder.java > ========================================================= > > > test/sun/security/provider/SecureRandom/DRBGAlg.java > ==================================================== > > > test/sun/security/provider/SecureRandom/SelfSeed.java > ===================================================== > > > test/sun/security/provider/SecureRandom/StrongSeedReader.java > ============================================================= > OK > Thanks again. --Max > From claes.redestad at oracle.com Mon Apr 25 16:47:04 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 25 Apr 2016 18:47:04 +0200 Subject: RFR(XXS): 8155036: Remove sun.security.action.GetBooleanSecurityPropertyAction Message-ID: <571E4A08.3080307@oracle.com> Hi, since JEP-260 encapsulates internal APIs, we could remove unused classes like this one hg rm ./src/java.base/share/classes/sun/security/action/GetBooleanSecurityPropertyAction.java Thanks! /Claes From claes.redestad at oracle.com Mon Apr 25 17:28:21 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 25 Apr 2016 19:28:21 +0200 Subject: RFR: 8155039: Simplify code to setup SSLContextImpl and TrustManagerFactoryImpl Message-ID: <571E53B5.3060409@oracle.com> Hi, SSLContextImpl and TrustManagerFactoryImpl has some setup code that could be simplified, getting rid of a couple of anonymous classes in the process. Webrev: http://cr.openjdk.java.net/~redestad/8155039/webrev.00 Bug: https://bugs.openjdk.java.net/browse/JDK-8155039 Alternatively we could remove OpenFileInputStreamAction instead since these two uses introduced here are actually the only active uses of this old convenience class. Thanks! /Claes From mandy.chung at oracle.com Mon Apr 25 18:48:30 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 25 Apr 2016 11:48:30 -0700 Subject: RFR(XXS): 8155036: Remove sun.security.action.GetBooleanSecurityPropertyAction In-Reply-To: <571E4A08.3080307@oracle.com> References: <571E4A08.3080307@oracle.com> Message-ID: <166956B3-FF4B-4F7E-BDA7-7573AD01A1B0@oracle.com> > On Apr 25, 2016, at 9:47 AM, Claes Redestad wrote: > > Hi, > > since JEP-260 encapsulates internal APIs, we could remove unused classes like this one > > hg rm ./src/java.base/share/classes/sun/security/action/GetBooleanSecurityPropertyAction.java +1 Mandy From chris.hegarty at oracle.com Mon Apr 25 19:30:42 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 25 Apr 2016 20:30:42 +0100 Subject: RFR(XXS): 8155036: Remove sun.security.action.GetBooleanSecurityPropertyAction In-Reply-To: <571E4A08.3080307@oracle.com> References: <571E4A08.3080307@oracle.com> Message-ID: <34BC51C0-7531-4DD5-9CF8-A54E6CB03AA7@oracle.com> On 25 Apr 2016, at 17:47, Claes Redestad wrote: > Hi, > > since JEP-260 encapsulates internal APIs, we could remove unused classes like this one > > hg rm ./src/java.base/share/classes/sun/security/action/GetBooleanSecurityPropertyAction.java That should be ok. -Chris. From bradford.wetmore at oracle.com Tue Apr 26 00:48:44 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 25 Apr 2016 17:48:44 -0700 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <1DA968F9-2A7B-4C77-AAA0-2280E9BB94E1@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <16410FF9-D4A6-4FA5-BCC6-F9AE5341F1F1@oracle.com> <74879272-ac24-b389-92fd-c9242ebab8a3@oracle.com> <1DA968F9-2A7B-4C77-AAA0-2280E9BB94E1@oracle.com> Message-ID: <0c80b3b7-26dd-35ed-1fc6-c67287a9c03e@oracle.com> On 4/24/2016 9:13 PM, Wang Weijun wrote: >> I didn't see any health tests. What is your plan for that? > *** If by health test your means the CAVP known-output tests, I am going to put it into test/closed since it's reading a huge (13MB) external file and should be stored on an artifact server. > > That said, I'll be happy to extract a subset of it and make it a public test. So the running the full set of CAVP known-output tests in closed is good for build/test time algorithm correctness, but the runtime "Health Testing" I was talking about is in the diagram of Section 7, and details in section 11.3: 11.3 Health Testing A DRBG implementation shall perform self-tests to obtain assurance that the DRBG continues to operate as designed and implemented (health testing). .... All data output from the DRBG mechanism boundary (or sub-boundary) shall be inhibited while these tests are performed. ... 11.3.1 ... Known-answer tests shall be conducted on each DRBG function within a boundary or sub-boundary prior to the first use of that DRBG (e.g., during the power-on self-testing sequence). I don't see in my admittedly brief look at this part of 800-90A when or how often these tests are supposed to run after POST (power on self test): as a thread in the background, or at power on, or what have you. You're also supposed to enter a error state from which it requires the operator to recover. I didn't see that code either. I'll try to get to the other comments tomorrow. Thanks, Brad From weijun.wang at oracle.com Tue Apr 26 06:25:08 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 26 Apr 2016 14:25:08 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <0c80b3b7-26dd-35ed-1fc6-c67287a9c03e@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <16410FF9-D4A6-4FA5-BCC6-F9AE5341F1F1@oracle.com> <74879272-ac24-b389-92fd-c9242ebab8a3@oracle.com> <1DA968F9-2A7B-4C77-AAA0-2280E9BB94E1@oracle.com> <0c80b3b7-26dd-35ed-1fc6-c67287a9c03e@oracle.com> Message-ID: <28090499-14E2-4BB2-8944-A0A6EC28EC99@oracle.com> > On Apr 26, 2016, at 8:48 AM, Bradford Wetmore wrote: > > but the runtime "Health Testing" I was talking about is in the diagram of Section 7, and details in section 11.3: I haven't touched this area yet. If you think it's necessary, I would like to add the test inside the static block of AbstractDrbg$SeederHolder. The test will be on Hash_DRBG/SHA-256 and whatever mech/algorithm defined by securerandom.drbg.config (They are the same by default). The test will be in the same thread (otherwise I don't know how to report an error). If it fails, a RuntimeException will be thrown. I can extract the test from CAVP, instantiate + reseed + generate with both non-null personalization string and additional input, and PR on. It won't take long. This is purely internal and automatic, maybe a new abstract method in AbstractDrbg is needed. Can we do this after the JEP? BTW, I probably will not be able to send out a new webrev today. Tomorrow is OK. Thanks Max From ivan.gerasimov at oracle.com Tue Apr 26 10:57:59 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 26 Apr 2016 13:57:59 +0300 Subject: [jdk9] RFR: 8154947: Send empty list of authorities in CertificateRequest, if server has too many of them In-Reply-To: <571A5ACE.1010905@oracle.com> References: <571A5ACE.1010905@oracle.com> Message-ID: <571F49B7.30307@oracle.com> Here's a modified version of the fix. Instead of a boolean-type property, a string-type property is introduced. It is used to specify the strategy to use, if we encounter the overflow during filling the list of authorities. The default strategy is to throw an exception (just like the currently implemented behavior.) It can also be set to the values 'empty' or 'truncate', which will make the server to send an empty or truncated list upon overflow. Would you please help review it? http://cr.openjdk.java.net/~igerasim/8154947/01/webrev/ With kind regards, Ivan On 22.04.2016 20:09, Ivan Gerasimov wrote: > Hello everyone! > > During TLS handshake, a server may be required to send a > CertificateRequest, which contains a list of authorities. > If the list happens to be too long, the server is throwing an > exception, indicating an overflow. > > It may be convenient to be able to just drop the list altogether, and > let the client to choose a certificate randomly. > In certain situation this may be more preferable that just block > communication. > > Would you please help review a patch, which introduces an command-line > option that controls this behavior of the server? > If the approach is approved, I'll file a CCC request for that option. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8154947 > WEBREV: http://cr.openjdk.java.net/~igerasim/8154947/00/webrev/ > > With the proposed fix all the security-related regression tests, > including the modified one, passed on all supported platforms. > > With kind regards, > Ivan > > From sean.coffey at oracle.com Tue Apr 26 13:56:51 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 26 Apr 2016 14:56:51 +0100 Subject: [jdk9] RFR: 8154947: Send empty list of authorities in CertificateRequest, if server has too many of them In-Reply-To: <571F49B7.30307@oracle.com> References: <571A5ACE.1010905@oracle.com> <571F49B7.30307@oracle.com> Message-ID: <571F73A3.5060409@oracle.com> Looks like a fair approach to solving this issue Ivan. A few comments from me : typo : authoririesOverflow --> authoritiesOverflow typo : handleAuthoritesOverflow --> handleAuthoritiesOverflow typo : jdk.tls.handleCertReqAuthoritesOverflow --> jdk.tls.handleCertReqAuthoritiesOverflow + throw new RuntimeException("Value of " + prop + + " must be one of '" + HAO_NONE + "', '" + + HAO_EMPTY + "', '" + HAO_TRUNC + "'"); I think it would be good to print the value of s in above exception also. something like + ". Received: \"" + s + "\""); == s.println("Cert Authorities:" + (authoririesOverflow ? " (overflow)" : "")); I would also be good to indicate the handleAuthoritiesOverflow string value in above printing *if* authoritiesOverflow turns out to be true. We should be able to determine from the next message printed - but no harm to future proof. Maybe : s.println("Cert Authorities:" + (authoritiesOverflow ? " (overflow" + "[" + handleAuthoritiesOverflow + "])" : "")); Regards, Sean. On 26/04/2016 11:57, Ivan Gerasimov wrote: > Here's a modified version of the fix. > > Instead of a boolean-type property, a string-type property is introduced. > It is used to specify the strategy to use, if we encounter the > overflow during filling the list of authorities. > > The default strategy is to throw an exception (just like the currently > implemented behavior.) > > It can also be set to the values 'empty' or 'truncate', which will > make the server to send an empty or truncated list upon overflow. > > Would you please help review it? > > http://cr.openjdk.java.net/~igerasim/8154947/01/webrev/ > > With kind regards, > Ivan > > > On 22.04.2016 20:09, Ivan Gerasimov wrote: >> Hello everyone! >> >> During TLS handshake, a server may be required to send a >> CertificateRequest, which contains a list of authorities. >> If the list happens to be too long, the server is throwing an >> exception, indicating an overflow. >> >> It may be convenient to be able to just drop the list altogether, and >> let the client to choose a certificate randomly. >> In certain situation this may be more preferable that just block >> communication. >> >> Would you please help review a patch, which introduces an >> command-line option that controls this behavior of the server? >> If the approach is approved, I'll file a CCC request for that option. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8154947 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8154947/00/webrev/ >> >> With the proposed fix all the security-related regression tests, >> including the modified one, passed on all supported platforms. >> >> With kind regards, >> Ivan >> >> > From xuelei.fan at oracle.com Tue Apr 26 14:33:21 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 26 Apr 2016 22:33:21 +0800 Subject: [jdk9] RFR: 8154947: Send empty list of authorities in CertificateRequest, if server has too many of them In-Reply-To: <571F73A3.5060409@oracle.com> References: <571A5ACE.1010905@oracle.com> <571F49B7.30307@oracle.com> <571F73A3.5060409@oracle.com> Message-ID: <571F7C31.6010004@oracle.com> jdk.tls.handleCertReqAuthoritesOverflow is a little bit long. jdk.tls.server.overFlowAuthorites? May not need to define the "none" property value. Using enum for HAO_NONE, HAO_EMPTY and HAO_TRUNC? line 1920: Overflow should be rare, what about print only when overflow? Xuelei On 4/26/2016 9:56 PM, Se?n Coffey wrote: > Looks like a fair approach to solving this issue Ivan. A few comments > from me : > > typo : authoririesOverflow --> authoritiesOverflow > typo : handleAuthoritesOverflow --> handleAuthoritiesOverflow > typo : jdk.tls.handleCertReqAuthoritesOverflow --> > jdk.tls.handleCertReqAuthoritiesOverflow > > + throw new RuntimeException("Value of " + prop > + + " must be one of '" + HAO_NONE + "', '" > + + HAO_EMPTY + "', '" + HAO_TRUNC + "'"); > > I think it would be good to print the value of s in above exception > also. something like + ". Received: \"" + s + "\""); > == > > s.println("Cert Authorities:" + (authoririesOverflow ? " (overflow)" : > "")); > > I would also be good to indicate the handleAuthoritiesOverflow string > value in above printing *if* authoritiesOverflow turns out to be true. > We should be able to determine from the next message printed - but no > harm to future proof. > Maybe : > > s.println("Cert Authorities:" + (authoritiesOverflow ? " (overflow" + > "[" + handleAuthoritiesOverflow + "])" : "")); > > Regards, > Sean. > > On 26/04/2016 11:57, Ivan Gerasimov wrote: >> Here's a modified version of the fix. >> >> Instead of a boolean-type property, a string-type property is introduced. >> It is used to specify the strategy to use, if we encounter the >> overflow during filling the list of authorities. >> >> The default strategy is to throw an exception (just like the currently >> implemented behavior.) >> >> It can also be set to the values 'empty' or 'truncate', which will >> make the server to send an empty or truncated list upon overflow. >> >> Would you please help review it? >> >> http://cr.openjdk.java.net/~igerasim/8154947/01/webrev/ >> >> With kind regards, >> Ivan >> >> >> On 22.04.2016 20:09, Ivan Gerasimov wrote: >>> Hello everyone! >>> >>> During TLS handshake, a server may be required to send a >>> CertificateRequest, which contains a list of authorities. >>> If the list happens to be too long, the server is throwing an >>> exception, indicating an overflow. >>> >>> It may be convenient to be able to just drop the list altogether, and >>> let the client to choose a certificate randomly. >>> In certain situation this may be more preferable that just block >>> communication. >>> >>> Would you please help review a patch, which introduces an >>> command-line option that controls this behavior of the server? >>> If the approach is approved, I'll file a CCC request for that option. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8154947 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8154947/00/webrev/ >>> >>> With the proposed fix all the security-related regression tests, >>> including the modified one, passed on all supported platforms. >>> >>> With kind regards, >>> Ivan >>> >>> >> > From sean.mullan at oracle.com Tue Apr 26 16:31:07 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 26 Apr 2016 12:31:07 -0400 Subject: RFR(XXS): 8155036: Remove sun.security.action.GetBooleanSecurityPropertyAction In-Reply-To: <571E4A08.3080307@oracle.com> References: <571E4A08.3080307@oracle.com> Message-ID: <571F97CB.8050800@oracle.com> On 04/25/2016 12:47 PM, Claes Redestad wrote: > Hi, > > since JEP-260 encapsulates internal APIs, we could remove unused classes > like this one > > hg rm > ./src/java.base/share/classes/sun/security/action/GetBooleanSecurityPropertyAction.java > The removal of this class is ok with me. There also doesn't seem to be any known external uses of this class. Thanks, Sean From ivan.gerasimov at oracle.com Tue Apr 26 17:03:56 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 26 Apr 2016 20:03:56 +0300 Subject: [8u-dev] Request for Review and Approval to backport: 8133070: Hot lock on BulkCipher.isAvailable In-Reply-To: References: Message-ID: <571F9F7C.6060707@oracle.com> Thank you Jianhao Mo for contributing the patch for the backport! I see Alibaba Group Holding Limited on the OCA Signatories List: http://www.oracle.com/technetwork/community/oca-486395.html so looks like we can accept your patch. I'm sending this as a formal request for review, as the patch differs from what was integrated into jdk9. This is also a request for approval to jdk8u-dev. Bug: https://bugs.openjdk.java.net/browse/JDK-8133070 Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6338191e2e44 Jdk9 review: http://mail.openjdk.java.net/pipermail/security-dev/2015-December/013242.html Jdk8 webrev: http://cr.openjdk.java.net/~igerasim/8133070/00/webrev/ I assume the Contributed-by line in the commit header should be set to: Contributed-by: xuelei.fan at oracle.com, kungu.mjh at alibaba-inc.com Would you please help review/approve this backport? With kind regards, Ivan On 23.04.2016 13:33, ???(??) wrote: > Hi Xuelei, > > Thank you for fixing https://bugs.openjdk.java.net/browse/JDK-8133070 . > I have been waiting for the backport > https://bugs.openjdk.java.net/browse/JDK-8146057 for months. > > May be I can contribute my backport to help making this happen faster. > > Attach please my backport. > > BTW, Alibaba has signed the OCA. > > Regards, > > Jianhao Mo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradford.wetmore at oracle.com Tue Apr 26 19:27:28 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 26 Apr 2016 12:27:28 -0700 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <28090499-14E2-4BB2-8944-A0A6EC28EC99@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <16410FF9-D4A6-4FA5-BCC6-F9AE5341F1F1@oracle.com> <74879272-ac24-b389-92fd-c9242ebab8a3@oracle.com> <1DA968F9-2A7B-4C77-AAA0-2280E9BB94E1@oracle.com> <0c80b3b7-26dd-35ed-1fc6-c67287a9c03e@oracle.com> <28090499-14E2-4BB2-8944-A0A6EC28EC99@oracle.com> Message-ID: <8de58911-9627-2057-2f57-b85c7a67c6fa@oracle.com> On 4/25/2016 11:25 PM, Wang Weijun wrote: > >> On Apr 26, 2016, at 8:48 AM, Bradford Wetmore wrote: >> >> but the runtime "Health Testing" I was talking about is in the diagram of Section 7, and details in section 11.3: > > I haven't touched this area yet. > > If you think it's necessary, I would like to add the test inside the static block of AbstractDrbg$SeederHolder. The test will be on Hash_DRBG/SHA-256 and whatever mech/algorithm defined by securerandom.drbg.config (They are the same by default). The test will be in the same thread (otherwise I don't know how to report an error). If it fails, a RuntimeException will be thrown. Please read over this section, but I *THINK* you are supposed to run a known-answer test on each SecureRandom instance created, not just the single one used as a seeder during : Known-answer tests shall be conducted on each DRBG function within a boundary or sub-boundary prior to the first use of that DRBG (e.g., during the power-on self-testing sequence). Which may mean that you'll need a known-answer test for each configuration type. Unless I'm interpreting this wrong. > I can extract the test from CAVP, instantiate + reseed + generate with both non-null personalization string and additional input, and PR on. It won't take long. > > This is purely internal and automatic, maybe a new abstract method in AbstractDrbg is needed. > > Can we do this after the JEP? That's fine with me, but the answer needs to be resolved (either work completed or it will not be done) by FCS/GA. > BTW, I probably will not be able to send out a new webrev today. Tomorrow is OK. Tomorrow is fine, it will allow me to respond to your other Q's. ;) Brad From anthony.scarpino at oracle.com Tue Apr 26 20:27:02 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 26 Apr 2016 13:27:02 -0700 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <8de58911-9627-2057-2f57-b85c7a67c6fa@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <16410FF9-D4A6-4FA5-BCC6-F9AE5341F1F1@oracle.com> <74879272-ac24-b389-92fd-c9242ebab8a3@oracle.com> <1DA968F9-2A7B-4C77-AAA0-2280E9BB94E1@oracle.com> <0c80b3b7-26dd-35ed-1fc6-c67287a9c03e@oracle.com> <28090499-14E2-4BB2-8944-A0A6EC28EC99@oracle.com> <8de58911-9627-2057-2f57-b85c7a67c6fa@oracle.com> Message-ID: <571FCF16.5060007@oracle.com> On 04/26/2016 12:27 PM, Bradford Wetmore wrote: > > > On 4/25/2016 11:25 PM, Wang Weijun wrote: >> >>> On Apr 26, 2016, at 8:48 AM, Bradford Wetmore >>> wrote: >>> >>> but the runtime "Health Testing" I was talking about is in the >>> diagram of Section 7, and details in section 11.3: >> >> I haven't touched this area yet. >> >> If you think it's necessary, I would like to add the test inside the >> static block of AbstractDrbg$SeederHolder. The test will be >> on Hash_DRBG/SHA-256 and whatever mech/algorithm defined by >> securerandom.drbg.config (They are the same by default). The test will >> be in the same thread (otherwise I don't know how to report an error). >> If it fails, a RuntimeException will be thrown. > > Please read over this section, but I *THINK* you are supposed to run a > known-answer test on each SecureRandom instance created, not just the > single one used as a seeder during : > > Known-answer tests shall be conducted on each DRBG function within > a boundary or sub-boundary prior to the first use of that DRBG > (e.g., during the power-on self-testing sequence). > > Which may mean that you'll need a known-answer test for each > configuration type. Unless I'm interpreting this wrong. I have not read the spec, but this sounds like something when FIPS is enabled, not during normal operation. Are you sure a POST is required during normal usage? Tony From bradford.wetmore at oracle.com Wed Apr 27 00:05:44 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 26 Apr 2016 17:05:44 -0700 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <1DA968F9-2A7B-4C77-AAA0-2280E9BB94E1@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <16410FF9-D4A6-4FA5-BCC6-F9AE5341F1F1@oracle.com> <74879272-ac24-b389-92fd-c9242ebab8a3@oracle.com> <1DA968F9-2A7B-4C77-AAA0-2280E9BB94E1@oracle.com> Message-ID: <512f8dbc-0105-7868-3ba0-a7c16104ec09@oracle.com> Deleting the cruft that doesn't need further discussion. On 4/24/2016 9:13 PM, Wang Weijun wrote: >>> http://cr.openjdk.java.net/~weijun/8051408/webrev.11/ >>> http://cr.openjdk.java.net/~weijun/8051408/webrev.11/spec >>> http://cr.openjdk.java.net/~weijun/8051408/webrev.11/specdiff > > Thanks for the review. I copied your DRBG.txt below with my comments. > > Most are accepted, some I mentioned my previous thoughts. Sorry, I've not been as up to date on previous discussions. > Some needs clarification or discussion (does not mean I don't accept them), tagged with *** so you can search for them. > > BTW, the CAVP test is on test/closed. I'll send you a private mail. We may need to include part/all of it in the open, depending on how strict we want to be following the health testing requirement. >> Overall: >> ======== >> >> IMPORTANT: By 800-90Ar1, sections 8.3/8.5, I don't think outputting the >> internal state is allowed, even for debugging. Please recheck this and >> let's discuss. > > *** Not very sure. Someone can always use reflection to look at the internal states. > > Well the main reason I printed out the internal state is to compare it with the CAVP text file when there is something wrong. Surely I can remove them now. Hm...we should talk to the person I mentioned in my other email, he might have an opinion on this. >> Also by the 800-90Ar1 spec, and given that SecureRandom is supposedly >> serializable, I don't think >> serialization to recover the exact state is (or should be) allowed: >> >> The internal state for one DRBG instantiation shall not be used as >> the internal state for a different instantiation. >> >> I'll/we'll need to think about this some more. > > *** Since after s11n/des11n it's *another* instance, seems we should not remember the states. A consequence is that it has to be reinitialized. I think we're on the same page here. >> I didn't see any checks for repeated input parameters. IIRC, if you get >> entropy repeating, that's a failure case. > > *** I thought that would be health check for an entropy source. How do you expect me to check it? A cache for recent inputs? Not very practical. Section 6.5 of 800-90B. Or maybe we should just assume the entropy data to be valid and not worry about this? >> I didn't see any health tests. What is your plan for that? > > *** If by health test your means the CAVP known-output tests, I am going to put it into test/closed since it's reading a huge (13MB) external file and should be stored on an artifact server. > > That said, I'll be happy to extract a subset of it and make it a public test. TBD in another mail. >> 123-128: Ordering still the same. >> NativePRNG, SHA1PRNG, and DRBG. > > I didn't realize your were asking me to be consistent. I only updated the first appearance. Will fix. Yes. Thanks. >> Applications can request for different instantiation parameters >> -> >> Applications can request different instantiation parameters > > I thought "request for" is a correct phrase. Will fix. It's a little awkward. >> 212-213: Still talks about 800-90 instead of the Sun provider document. > > *** How just list all names here? I already listed all mech names. Ok. It should probably also go into the Sun provider doc, where we talk about what algorithms/modes/etc are available. >> I notice the particular value of "3KeyTDEA" is mentioned later in this >> file, but not the other string values. > > CtrDrbg.java. Not sure what you were saying here. >> >> java/security/Provider.java >> =========================== >> Copyright date. > > Already updated. You reading webrev.10? I might have started on this! Sorry! >> I'm really tempted to file a bug to clean up the really long lines added >> by the lambda folks. Ugh...This make reviewing changes in frame-based >> webrevs hard. > > There aren't many in this file. I'll break them. Thanks! >> java/security/SecureRandom.java >> =============================== >> 54,78,406,439,513,etc: > 80 chars. I won't list any more, but expect it >> might occur in other files as well. > > You expect me to be 100% strict with 80 chars. Will do. Yes please! Sorry, it's a pet peeve of mine and some others. I do hear the usual "Get a more modern terminal emulator", but that's not the issue. The problem is real estate. Even with a 24" monitor (1900x1200), doing a side-by-side webrev (i.e. frames) comparison on a 160 character line means I've got to scroll both sides. It's even worse on a laptop with less real estate. A 3 column merge is nigh impossible. And what if you need to print a hard copy? I realize some breaks are impossible, but if you're regularly indenting a large amount, you probably will want to refactor your code. >> 72: I don't know for sure about this, but I don't think you need a

    >> following a

    . It gives extra vertical space in the output. >> I noticed this several places in the resulting javadoc. > > I don't see any visual difference between the 2 styles. > > Turns out the extra space is a empty line in pre (try Select All and you'll see). I'll put at the end of the previous line. Ah yes! Thanks. >> 592: I've not be happy with the wording both here and in SecureRandomSpi. >> The value returned here may not be the same as the one used to instantiate >> it. >> >> I'm wondering if maybe something like this would be clearer: >> >> Returns the effective {@link SecureRandomParameters} >> that is actually used to instantiate this {@code SecureRandom}. >> -> >> Returns the effective SRP for this SecureRandom instance. > > OK. > > In fact, I was deliberately trying to express the meaning that the returned value here could be different from the one passed into getInstance(). But maybe as your suggested, not mentioning instantiate at all is clearer. > > Anyway I think I've emphasized this many times in other places. You have, but this seems to be contradictory to that. My point is that some people might see "used to instantiate" as the parameter that was actually passed in, rather than the derived value. >> 660: Reading the next method, I wonder if we should we also add a >> @throws NPE here for then bytes is null? It's undocumented currently. > > *** Wow. It was there and Xuelei suggested me removing it. The reason is that SunPKCS11's nextBytes happily accepted null (and ignore it). Although I see no benefits doing that (SunPKCS11 has not use this chance to do any instantiate work etc), maybe it's safe to not require non-null here. Instead we should probably file a spec bug instead and get the SunPKCS11 fixed. >> 673-677: You probably know this, but according to: >> >> http://www.oracle.com/technetwork/articles/java/index-137868.html >> >> a @param ends with a period if another sentence follows it. But >> it's done throughout this file, so suggest you not change all the other >> places in this push, but you may want to keep it consistent within >> your new method. > > *** Please confirm if I understand correctly: No period if it's only a clause or an expression. > > So I should remove the period at the end of 674. See the section starting: When writing a phrase, do not capitalize and do not end with a period: There's several rules there. >> >> 676: You mention unrecognizable/unsupported, does that include >> illegal? For example, if prediction_resistance_flag was not set at >> instantiate, but Prediction_reistance_request was set in this method? > > I'll add "illegal", although "unsupported" kinds implies it. Otherwise, what is the difference of "unrecognizable" and "unsupported"? We know this parameter defined for DRBG but we haven't yet supported it? unsupported/unrecognizable are likely the same: I would expect that to mean they sent us an object that our implementation just doesn't know what to do with. e.g. they extended and sent us a new subclass of SecureRandomParameters that isn't a NextBytes. whereas illegal is that they sent us a value that can't be allowed at runtime. e.g. pr was set in this object, but pr wasn't requsted in the initiate. >> XXX: what do you do bout large size requests or things that can't be >> reseeded? > > This won't happen in our implementation so I haven't mentioned them. > > For large size nextBytes() it's an implementation's duty to generate again and again until all is obtained. At one time, we had talked about modifying nextBytes(byte[]) internally keep regenerating until there was enough to return to avoid imposing this assumption on new code. For example, if someone had a 90K Hash_DRBG/SHA* request (64K per call), the framework would call generate twice before turning the concatenated buffer array. But this assumption is fine as well. It needs to be documented in both nextBytes(). Something along those lines. "If the underlying implementation is prohibited from supplying a full arrays worth of data, the application must repeatedly call..." > *** I am not sure what you are asking of reseeding. UnsupportedOperationException not enough? My comment was that if I specify PR here and the impl doesn't support reseeding, is that an IllegalArgument exception? >> 752: I don't think this addition made it into your CCC. > > *** The 3rd part of spec in CCC only mentions changes related to DRBG. I think this one is trivial and should not be included there. Likely needs to be a separate CCC then. >> 171: I think we should leave this part out, or at least warn that it >> may not be supported in all distributions. >> >> A provider is free to add other DRBG implementations with specific >> configurations using different SecureRandom algorithm names (for >> example, "Hash_DRBG/SHA-512") > > Leave this out. I couldn't resist making suggestions on these old names that are removed now. Ok thanks. Since we didn't have, encouraging others to add them seem strange. >> I really think all of the Implementations Notes here should be placed >> in the Sun Provider document. If you want to leave the section saying >> "see the DRBG section of the Sun Providers", that's fine. Some >> additional notes about this section whereever it ends up. > > Correct. The @implSpec was written to comply with 800-90Ar1's 11.1 and will be places in the Sun Provider doc. I was planning to add a reference here after the target is complete. Ok. >> In java.security, you call it "3KeyTDEA", but here the string is >> "DESede". Which is it? > > I'll use "3KeyTDEA (known as DEDede in JCE)". Assuming a typo? DEDede->DESede You're still leaving the DESede alias, right? >> 472: >> @throws NullPointerException if {@code capacity} is {@code null}. >> -> >> @throws NullPointerException if {@code capability} is {@code null}. > > Oops. No problem, I've done that once or twice (or...). Funny how you can look at something a million times, but you just believe what you want it to say instead of what it actually says. ;) >> java/security/SecureRandomParameters.java >> ========================================= >> 31: >> A specific type of {@code SecureRandom} can implement this interface. >> >> Don't you mean that different types of *SecureRandomParameter* can be >> created and passed to SR's? > > Yes, different for DRBG and NRBG, for example. My point is that you'll be updating SecureRandom with SecureRandomParameter here. >> sun/security/provider/AbstractDrbg.java >> ======================================= >> 98,368,369, etc. Lines > 80. This is throughout your code. Hard to >> read on a laptop with narrow display. > > I'll shorted the comments, but sometimes for codes I am OK with a little more than 80 chars. I can make it strict. There are some places that it's difficult to make clean break, but fortunately they are pretty few. >> 64: Is this serialVersionUID a placeholder, or the final value? > > *** My understanding is that serialVersionUID calculated with serialno is to be compatible with an earlier version that has no this field. In a new file with serialVersionUID, it can anything and I prefer one that is easy to understand. I wasn't sure if you were going to take the final version of the file and run it through serialver to get the actual value. >> 107: In 800-90Ar1, many of the variables have specific names. They >> don't generally follow our conventions, but would you consider using a >> close derivative? For example, highestSupportedSecurityStrength and >> maxPersonalizationStringLength? That would make a little more clear >> how the DRBG variables map to the implementation. I notice you've used >> those names in other places, but wasn't sure if that was by design or >> not. > > I use the name in 800-90Ar1 in comments but prefer a more-Java-like variable name. > If you like I can be more close. It makes it a little easier to read. >> 145: Should you mention that MAX_INT is actually smaller than the >> amount allowed by the various algorithms? Or should the implementation >> be long-based throughout? > > *** Since a Java array can only holds MAX_INT of elements, we won't be able to support long. Yes, of course! :) > I can add an explanation. Sound good. >> Also, there are several places here and in other files (DRBG.java) >> where you do multiple function calls where the return value won't be >> changing: first to check legality, then to actually capture/use the value. >> See lines 348/365/366. Can't these calls be combined? > > Yes I can. > > As you see, when the return value is a cloned array (line 359) I only call once. When it's a primitive I think an extra call is not too bad. Just seems like a simple enhancement. >> 355: Are you somewhere calling this DRBG.nextBytes() multiple times if >> the output size is too big to be handled by a single DRBG call? > > No. It should but since here maxNbLength is MAX_INT I omit the call. Ok. > *** I created these maxNbLength/maxAiLength/maxPsLength variables to be more aligned with pseudo codes in 800-90Ar1, but honestly they have no real use in the impl and I sometimes ignore it. Ah. >> 460: would you want to call security "min_entropy" to match the spec? > > Sure, and I will change min/max there to minLength/maxLength. Thanks. >> 483: Can't this be final? Netbeans is complaining about a non-final >> defaultES at 503. Also private? > > Yes and yes. > >> >> 551: What is register() used for? > > Useless. I was doing an experiment with lines in SunEntries > > new HashDRBG(null).register(map) > > and those attributes can be use by an app to detect capabilities. We usually put those into the SunEntries directly so it can be used by the JCE selection mechanism. >> 642: We have this problem in JSSE: in various places, you have debug >> strings like "instantiate", but in a multi-SR environment, you'll have >> no idea which one is in play. Do you want to use '"instantiate" + this'? > > *** Is "this" enough? this.toString() shows the configuration. Do you want System.identityHashCode()? I can add it right into toString(). Something that makes things quickly understandable which object is being used would be helpful. SeanC would be a good one to ask, as he's more involved in the supportability side. I'm just remembering trying to debug some JSSE debug output, and we had multiple thread/sockets debug output all interleaved together. It was impossible to parse. >> 674: can be final. Do you want to use the ES to generate an initial >> value for the monotonically increasing sequence number? > > *** I don't think it's necessary, as long as it changes with duplication. Ok. >> 692: Isn't there some preexisting code somewhere we can use? This seems >> like a common need, and I recall having written something similar a >> while ago. > > No colon/space/newline? I don't know. I just found an RFE, and added my comment to it: https://bugs.openjdk.java.net/browse/JDK-8143863 >> sun/security/provider/CtrDrbg.java >> ================================== >> >> 51: transient here? > > *** Already transient. Should it be transient? It's not in the other files. >> 141: AES-192/256 is indeed supported, it's just that the unlimited >> policy files aren't installed. I would suggest a better error message >> here, like "algorithm not available (policy)" or something similar. > > OK. > > "algorithm not available (because policy)". I recently read a article about modern English do not use "because of" anymore. Hm...ok. >> 422: What is this for? > > SecretKeySpec for DESede use 24 bytes but k in CTR_DRBG is 21 bytes. Ah, parity bits. >> sun/security/provider/DRBG.java >> =============================== >> 60: A final constant string should be cap'd. propName -> PROPANE > > OK. er...PROP_NAME or PROPNAME, not PROPANE! ;) >> 93: space missing "part:" > > Do we need a space here? for (String s : names) > *** BTW, where is a modern coding style guide? I don't think there is anything recent. I took this style from: 8/technotes/guides/language/foreach.html which follows from the ? operator. >> sun/security/provider/HmacDrbg.java >> =================================== >> By 8.3/8.5, I don't think outputting V/C is allowed, even in debug. >> Please recheck this. >> >> 76: Don't you need to re-init() this again? It's supposed to be the >> current value of K. > > *** In Step 2, v is updated but not k. But k was updated in step 1 of HMAC_DRBG, or are K/V only updated at the exit of the method? I'm guessing if you got it to pass, you must be right. >> sun/security/provider/MoreDrbgParameters.java >> ============================================= >> 48: if null, does a default get selected? > > Yes, the one in the security property. I should also mentioned when passed into HashDrbg/HmacDrbg/CtrDrbg it is ignored. In the others, you say "a default XXX will be used", but it's missing here. >> com/sun/crypto/provider/SunJCE.java >> =================================== >> I wasn't able to find any HmacSHA512/* OIDs at oid-info.com. >> >> http://oid-info.com/get/1.2.840.113549.2 >> >> Just the ones for MessageDigest, which you have in SunEntries. > > Neither can I find in other places. I even asked on Stack Overflow > > http://stackoverflow.com/questions/33605411/oids-for-hmacsha512-224-and-hmacsha512-256 I saw your question when I was looking, but didn't realize that was you! ;) I hope this helps some more. Brad From weijun.wang at oracle.com Wed Apr 27 00:40:33 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 27 Apr 2016 08:40:33 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <8de58911-9627-2057-2f57-b85c7a67c6fa@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <16410FF9-D4A6-4FA5-BCC6-F9AE5341F1F1@oracle.com> <74879272-ac24-b389-92fd-c9242ebab8a3@oracle.com> <1DA968F9-2A7B-4C77-AAA0-2280E9BB94E1@oracle.com> <0c80b3b7-26dd-35ed-1fc6-c67287a9c03e@oracle.com> <28090499-14E2-4BB2-8944-A0A6EC28EC99@oracle.com> <8de58911-9627-2057-2f57-b85c7a67c6fa@oracle.com> Message-ID: <9BE04D28-F895-4AD2-BE19-97D22858A712@oracle.com> > On Apr 27, 2016, at 3:27 AM, Bradford Wetmore wrote: > > > > On 4/25/2016 11:25 PM, Wang Weijun wrote: >> >>> On Apr 26, 2016, at 8:48 AM, Bradford Wetmore wrote: >>> >>> but the runtime "Health Testing" I was talking about is in the diagram of Section 7, and details in section 11.3: >> >> I haven't touched this area yet. >> >> If you think it's necessary, I would like to add the test inside the static block of AbstractDrbg$SeederHolder. The test will be on Hash_DRBG/SHA-256 and whatever mech/algorithm defined by securerandom.drbg.config (They are the same by default). The test will be in the same thread (otherwise I don't know how to report an error). If it fails, a RuntimeException will be thrown. > > Please read over this section, but I *THINK* you are supposed to run a known-answer test on each SecureRandom instance created, not just the single one used as a seeder during : Not the single one, but also the mech/alg pair defined in securerandom.drbg.config, which I think is the only configuration type that a user can create. We don't really need to test for each instance, right? Please note I won't run the test on any real instance, I'll just call the *Algorithm methods directly (more like a static method), this method will be inside each implementation class. > > Known-answer tests shall be conducted on each DRBG function within > a boundary or sub-boundary prior to the first use of that DRBG > (e.g., during the power-on self-testing sequence). > > Which may mean that you'll need a known-answer test for each configuration type. Unless I'm interpreting this wrong. OK, you also say "each configuration". Thanks Max From xuelei.fan at oracle.com Wed Apr 27 15:09:02 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 27 Apr 2016 23:09:02 +0800 Subject: [8u-dev] Request for Review and Approval to backport: 8133070: Hot lock on BulkCipher.isAvailable In-Reply-To: <571F9F7C.6060707@oracle.com> References: <571F9F7C.6060707@oracle.com> Message-ID: <5720D60E.6010703@oracle.com> The update looks to to me. Thanks, Xuelei On 4/27/2016 1:03 AM, Ivan Gerasimov wrote: > Thank you Jianhao Mo for contributing the patch for the backport! > > I see Alibaba Group Holding Limited on the OCA Signatories List: > http://www.oracle.com/technetwork/community/oca-486395.html > so looks like we can accept your patch. > > I'm sending this as a formal request for review, as the patch differs > from what was integrated into jdk9. > This is also a request for approval to jdk8u-dev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8133070 > Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6338191e2e44 > Jdk9 review: > http://mail.openjdk.java.net/pipermail/security-dev/2015-December/013242.html > Jdk8 webrev: http://cr.openjdk.java.net/~igerasim/8133070/00/webrev/ > > I assume the Contributed-by line in the commit header should be set to: > Contributed-by: xuelei.fan at oracle.com, kungu.mjh at alibaba-inc.com > > Would you please help review/approve this backport? > > With kind regards, > Ivan > > > On 23.04.2016 13:33, ???(??) wrote: >> Hi Xuelei, >> >> Thank you for fixing https://bugs.openjdk.java.net/browse/JDK-8133070 . >> I have been waiting for the backport >> https://bugs.openjdk.java.net/browse/JDK-8146057 for months. >> >> May be I can contribute my backport to help making this happen faster. >> >> Attach please my backport. >> >> BTW, Alibaba has signed the OCA. >> >> Regards, >> >> Jianhao Mo >> > From sean.coffey at oracle.com Wed Apr 27 15:28:15 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 27 Apr 2016 16:28:15 +0100 Subject: [8u-dev] Request for Review and Approval to backport: 8133070: Hot lock on BulkCipher.isAvailable In-Reply-To: <5720D60E.6010703@oracle.com> References: <571F9F7C.6060707@oracle.com> <5720D60E.6010703@oracle.com> Message-ID: <5720DA8F.2050800@oracle.com> Approved for jdk8u-dev. Regards, Sean. On 27/04/16 16:09, Xuelei Fan wrote: > The update looks to to me. > > Thanks, > Xuelei > > On 4/27/2016 1:03 AM, Ivan Gerasimov wrote: >> Thank you Jianhao Mo for contributing the patch for the backport! >> >> I see Alibaba Group Holding Limited on the OCA Signatories List: >> http://www.oracle.com/technetwork/community/oca-486395.html >> so looks like we can accept your patch. >> >> I'm sending this as a formal request for review, as the patch differs >> from what was integrated into jdk9. >> This is also a request for approval to jdk8u-dev. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8133070 >> Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6338191e2e44 >> Jdk9 review: >> http://mail.openjdk.java.net/pipermail/security-dev/2015-December/013242.html >> Jdk8 webrev: http://cr.openjdk.java.net/~igerasim/8133070/00/webrev/ >> >> I assume the Contributed-by line in the commit header should be set to: >> Contributed-by: xuelei.fan at oracle.com, kungu.mjh at alibaba-inc.com >> >> Would you please help review/approve this backport? >> >> With kind regards, >> Ivan >> >> >> On 23.04.2016 13:33, ???(??) wrote: >>> Hi Xuelei, >>> >>> Thank you for fixing https://bugs.openjdk.java.net/browse/JDK-8133070 . >>> I have been waiting for the backport >>> https://bugs.openjdk.java.net/browse/JDK-8146057 for months. >>> >>> May be I can contribute my backport to help making this happen faster. >>> >>> Attach please my backport. >>> >>> BTW, Alibaba has signed the OCA. >>> >>> Regards, >>> >>> Jianhao Mo >>> From weijun.wang at oracle.com Wed Apr 27 17:20:04 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 28 Apr 2016 01:20:04 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <512f8dbc-0105-7868-3ba0-a7c16104ec09@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <16410FF9-D4A6-4FA5-BCC6-F9AE5341F1F1@oracle.com> <74879272-ac24-b389-92fd-c9242ebab8a3@oracle.com> <1DA968F9-2A7B-4C77-AAA0-2280E9BB94E1@oracle.com> <512f8dbc-0105-7868-3ba0-a7c16104ec09@oracle.com> Message-ID: Webrev updated: http://cr.openjdk.java.net/~weijun/8051408/webrev.12 http://cr.openjdk.java.net/~weijun/8051408/webrev.12/spec http://cr.openjdk.java.net/~weijun/8051408/webrev.12/specdiff 1am now and I will reread the changes tomorrow. This is the result of 3 days' intense work and I hope I cover every comment from you. Big changes: 1. DrbgCavp moved to open as a manual test (because the test vector is huge), and created a closed one to launch it automatically. 2. healthTest() stub added. 3. debug() shows type/identity 4. Rename of variables to be more 800-90Ar1 style, step-by-step comments added 5. status() not called anymore, no internal state shown 6. Internal state not serialized. Some words in DrbgParameters on this. 7. s/Instantiate/Instantiation/g. Still no NPE for SecureRandom#nextBytes(null). Another bug. Some comments below: >>> I didn't see any checks for repeated input parameters. IIRC, if you get >>> entropy repeating, that's a failure case. >> >> *** I thought that would be health check for an entropy source. How do you expect me to check it? A cache for recent inputs? Not very practical. > > Section 6.5 of 800-90B. Or maybe we should just assume the entropy data to be valid and not worry about this? 800-90B? That's out of this JEP. We just assume the data is perfect. > >>> >>> java/security/Provider.java >>> =========================== > >>> I'm really tempted to file a bug to clean up the really long lines added >>> by the lambda folks. Ugh...This make reviewing changes in frame-based >>> webrevs hard. Oh sorry, I'm having difficulties breaking them because the type name is already too long (For example, "BiFunction") and I am not sure where to break it. How about I only break it partially? Say public synchronized Object merge(Object key, Object value, BiFunction remappingFunction) { -> public synchronized Object merge(Object key, Object value, BiFunction remappingFunction) { The 2nd line is still longer than 80 chars. Or I do not touch it at all and file another bug? > >>> java/security/SecureRandom.java >>> =============================== > >>> 660: Reading the next method, I wonder if we should we also add a >>> @throws NPE here for then bytes is null? It's undocumented currently. >> >> *** Wow. It was there and Xuelei suggested me removing it. The reason is that SunPKCS11's nextBytes happily accepted null (and ignore it). Although I see no benefits doing that (SunPKCS11 has not use this chance to do any instantiate work etc), maybe it's safe to not require non-null here. > > Instead we should probably file a spec bug instead and get the SunPKCS11 fixed. https://bugs.openjdk.java.net/browse/JDK-8155191 filed. > > >>> XXX: what do you do bout large size requests or things that can't be >>> reseeded? >> >> This won't happen in our implementation so I haven't mentioned them. >> >> For large size nextBytes() it's an implementation's duty to generate again and again until all is obtained. > > At one time, we had talked about modifying nextBytes(byte[]) internally keep regenerating until there was enough to return to avoid imposing this assumption on new code. For example, if someone had a 90K Hash_DRBG/SHA* request (64K per call), the framework would call generate twice before turning the concatenated buffer array. > > But this assumption is fine as well. It needs to be documented in both nextBytes(). Something along those lines. "If the underlying implementation is prohibited from supplying a full arrays worth of data, the application must repeatedly call..." * If the underlying implementation is prohibited from supplying a * full arrays worth of data, the application must repeatedly call * its generation algorithm until all elements in {@code bytes} are * filled with random data. >> *** I am not sure what you are asking of reseeding. UnsupportedOperationException not enough? > > My comment was that if I specify PR here and the impl doesn't support reseeding, is that an IllegalArgument exception? It will be UnsupportedOperationException. I add a line saying the method must not be implemented. > >>> 752: I don't think this addition made it into your CCC. >> >> *** The 3rd part of spec in CCC only mentions changes related to DRBG. I think this one is trivial and should not be included there. > > Likely needs to be a separate CCC then. I included this as another part of the spec. >> >> I'll use "3KeyTDEA (known as DEDede in JCE)". > > Assuming a typo? DEDede->DESede Maybe auto-corrected by mail client? > > You're still leaving the DESede alias, right? It is still there. >>> 64: Is this serialVersionUID a placeholder, or the final value? >> >> *** My understanding is that serialVersionUID calculated with serialno is to be compatible with an earlier version that has no this field. In a new file with serialVersionUID, it can anything and I prefer one that is easy to understand. > > I wasn't sure if you were going to take the final version of the file and run it through serialver to get the actual value. Is that a must? > I just found an RFE, and added my comment to it: > > https://bugs.openjdk.java.net/browse/JDK-8143863 Not sure if it's a good idea. Do we need HEX string for int[] and long[]? Also, for byte[], we have multiple formats. HexDumpEncoder is already good enough for human eyes, here we need something for a problem. > >>> sun/security/provider/CtrDrbg.java >>> ================================== >>> >>> 51: transient here? >> >> *** Already transient. > > Should it be transient? It's not in the other files. MessageDigest in HashDrbg and Mac in HmacDrbg are all transient, because we don't want to serialize it. Is there anything wrong? That said, many more becomes transient since we don't want to serialize the internal state. Thanks Max From bradford.wetmore at oracle.com Thu Apr 28 00:50:41 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 27 Apr 2016 17:50:41 -0700 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <16410FF9-D4A6-4FA5-BCC6-F9AE5341F1F1@oracle.com> <74879272-ac24-b389-92fd-c9242ebab8a3@oracle.com> <1DA968F9-2A7B-4C77-AAA0-2280E9BB94E1@oracle.com> <512f8dbc-0105-7868-3ba0-a7c16104ec09@oracle.com> Message-ID: I won't have the cycles to do another full review, but just looked over things I mentioned in my previous review, and things are looking good! I have to jump back to my other projects. Thanks for your careful review of our comments. A few minor points. On 4/27/2016 10:20 AM, Wang Weijun wrote: > Webrev updated: > > http://cr.openjdk.java.net/~weijun/8051408/webrev.12 > http://cr.openjdk.java.net/~weijun/8051408/webrev.12/spec > http://cr.openjdk.java.net/~weijun/8051408/webrev.12/specdiff > 212-213: Still talks about 800-90 instead of the Sun provider > document. Looks good. Thanks. > 238 # securerandom.drbg.config= > CTR_DRBG,AES-256,256,pr_and_reseed,use_df You could change the second "256" to "192", just to show that the requested strength doesn't have to be the max the AES strength. Thanks for taking care of the long lines! Very much appreciated. DrbgParameters.java =================== You might want to add a "(800-90Ar1)" here, like you would after defining an acronym. Did you want to add an implNote that the "java.security" file or the Security Property configures the choice entropy/mechanism/etc? AbstractDrbg.java ================= Thanks for the rename and the step# comments. Much easier to follow! > 1am now and I will reread the changes tomorrow. This is the result of 3 days' intense work and I hope I cover every comment from you. > > Big changes: > > 1. DrbgCavp moved to open as a manual test (because the test vector is huge), and created a closed one to launch it automatically. > > 2. healthTest() stub added. > > 3. debug() shows type/identity > > 4. Rename of variables to be more 800-90Ar1 style, step-by-step comments added > > 5. status() not called anymore, no internal state shown > > 6. Internal state not serialized. Some words in DrbgParameters on this. > > 7. s/Instantiate/Instantiation/g. > > Still no NPE for SecureRandom#nextBytes(null). Another bug. > > Some comments below: > >>>> I didn't see any checks for repeated input parameters. IIRC, if you get >>>> entropy repeating, that's a failure case. >>> >>> *** I thought that would be health check for an entropy source. How do you expect me to check it? A cache for recent inputs? Not very practical. >> >> Section 6.5 of 800-90B. Or maybe we should just assume the entropy data to be valid and not worry about this? > > 800-90B? That's out of this JEP. We just assume the data is perfect. Ok. >>>> java/security/Provider.java >>>> =========================== >> >>>> I'm really tempted to file a bug to clean up the really long lines added >>>> by the lambda folks. Ugh...This make reviewing changes in frame-based >>>> webrevs hard. > > > Oh sorry, I'm having difficulties breaking them because the type name is already too long (For example, "BiFunction") and I am not sure where to break it. How about I only break it partially? Say > > public synchronized Object merge(Object key, Object value, BiFunction remappingFunction) { > -> > public synchronized Object merge(Object key, Object value, > BiFunction remappingFunction) { > > The 2nd line is still longer than 80 chars. > > Or I do not touch it at all and file another bug? I would say file another bug, but I would break it: public synchronized Object merge(Object key, Object value, BiFunction remappingFunction) { or public synchronized Object merge(Object key, Object value, BiFunction remappingFunction) { >>>> java/security/SecureRandom.java >>>> =============================== >> >>>> 660: Reading the next method, I wonder if we should we also add a >>>> @throws NPE here for then bytes is null? It's undocumented currently. >>> >>> *** Wow. It was there and Xuelei suggested me removing it. The reason is that SunPKCS11's nextBytes happily accepted null (and ignore it). Although I see no benefits doing that (SunPKCS11 has not use this chance to do any instantiate work etc), maybe it's safe to not require non-null here. >> >> Instead we should probably file a spec bug instead and get the SunPKCS11 fixed. > > https://bugs.openjdk.java.net/browse/JDK-8155191 filed. Thanks. Are you going to handle as a separate putback, or part of this one? The timing is probably better (an additional CCC) if you do later, but it does add overhead because it would require a separate putback. >>>> XXX: what do you do bout large size requests or things that can't be >>>> reseeded? >>> >>> This won't happen in our implementation so I haven't mentioned them. >>> >>> For large size nextBytes() it's an implementation's duty to generate again and again until all is obtained. >> >> At one time, we had talked about modifying nextBytes(byte[]) internally keep regenerating until there was enough to return to avoid imposing this assumption on new code. For example, if someone had a 90K Hash_DRBG/SHA* request (64K per call), the framework would call generate twice before turning the concatenated buffer array. >> >> But this assumption is fine as well. It needs to be documented in both nextBytes(). Something along those lines. "If the underlying implementation is prohibited from supplying a full arrays worth of data, the application must repeatedly call..." > > * If the underlying implementation is prohibited from supplying a > * full arrays worth of data, the application must repeatedly call > * its generation algorithm until all elements in {@code bytes} are > * filled with random data. This wording is a little awkward, given the currently available APIs. Since we don't have a pos/offset nextBytes() variant, so maybe something like: * If the underlying implementation (for example: DRBG) is prohibited * from supplying the requested amount of data in a single call, the * application should retry by breaking the request into multiple * smaller requests. >>> *** I am not sure what you are asking of reseeding. UnsupportedOperationException not enough? >> >> My comment was that if I specify PR here and the impl doesn't support reseeding, is that an IllegalArgument exception? > > It will be UnsupportedOperationException. I add a line saying the method must not be implemented. I wonder, would you ever have a situation where reseed() might be overridden, but still illegal in some case. If so, maybe... If not, never mind. @throws UnsupportedOperationException if the underlying provider implementation has not overridden this method. -> @throws UnsupportedOperationException if the underlying provider implementation has not overridden this method or does not support this operation. >>>> 64: Is this serialVersionUID a placeholder, or the final value? >>> >>> *** My understanding is that serialVersionUID calculated with serialno is to be compatible with an earlier version that has no this field. In a new file with serialVersionUID, it can anything and I prefer one that is easy to understand. >> >> I wasn't sure if you were going to take the final version of the file and run it through serialver to get the actual value. > > Is that a must? Joe Darcy says: "Is it a new class? You can either just pick a number, or use serialver." So take your pick. >> I just found an RFE, and added my comment to it: >> >> https://bugs.openjdk.java.net/browse/JDK-8143863 > > Not sure if it's a good idea. Do we need HEX string for int[] and long[]? > > Also, for byte[], we have multiple formats. HexDumpEncoder is already good enough for human eyes, here we need something for a problem. Yeah, hard to say. I just hate seeing the same code in multiple places. >>>> sun/security/provider/CtrDrbg.java >>>> ================================== >>>> >>>> 51: transient here? >>> >>> *** Already transient. >> >> Should it be transient? It's not in the other files. > > MessageDigest in HashDrbg and Mac in HmacDrbg are all transient, because we don't want to serialize it. Is there anything wrong? > > That said, many more becomes transient since we don't want to serialize the internal state. I missed it. Thanks, Brad From weijun.wang at oracle.com Thu Apr 28 02:16:02 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 28 Apr 2016 10:16:02 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <16410FF9-D4A6-4FA5-BCC6-F9AE5341F1F1@oracle.com> <74879272-ac24-b389-92fd-c9242ebab8a3@oracle.com> <1DA968F9-2A7B-4C77-AAA0-2280E9BB94E1@oracle.com> <512f8dbc-0105-7868-3ba0-a7c16104ec09@oracle.com> Message-ID: <50FC89C3-C2E1-4DB3-BE40-BC118AF3945F@oracle.com> > On Apr 28, 2016, at 8:50 AM, Bradford Wetmore wrote: > > I won't have the cycles to do another full review, but just looked over things I mentioned in my previous review, and things are looking good! I have to jump back to my other projects. Thanks, there are still several thing to discuss. The one important is about nextBytes. Read below. > DrbgParameters.java > =================== > > Did you want to add an implNote that the "java.security" file or the Security Property configures the choice entropy/mechanism/etc? The @implNote already has * The mechanism name and DRBG algorithm name are determined by the * {@linkplain Security#getProperty(String) security property} * {@code securerandom.drbg.config}. The default choice is Hash_DRBG * with SHA-256. and * This implementation reads fresh entropy from the system default entropy * source determined by the security property {@code securerandom.source}. Do I need to mention "java.security"? > >>>>> java/security/Provider.java >>>>> =========================== >>> >>>>> I'm really tempted to file a bug to clean up the really long lines added >>>>> by the lambda folks. Ugh...This make reviewing changes in frame-based >>>>> webrevs hard. > I would say file another bug https://bugs.openjdk.java.net/browse/JDK-8155575 filed. I added you as a watcher. >>>>> >>>>> java/security/SecureRandom.java >>>>> =============================== >>> >>>>> >> >> https://bugs.openjdk.java.net/browse/JDK-8155191 filed. > > Thanks. Are you going to handle as a separate putback, or part of this one? The timing is probably better (an additional CCC) if you do later, but it does add overhead because it would require a separate outback. A separate push. > >>>>> XXX: what do you do bout large size requests or things that can't be >>>>> reseeded? >>>> > > This wording is a little awkward, given the currently available APIs. Since we don't have a pos/offset nextBytes() variant, so maybe something like: > > * If the underlying implementation (for example: DRBG) is prohibited > * from supplying the requested amount of data in a single call, the > * application should retry by breaking the request into multiple > * smaller requests. I think there is a problem here. We should not ask an application to call it multiple times because it does not know what the max size is. Instead, the implementation should always fill in all bytes. I'd like to add some words in SecureRandomSpi#engineNextBytes: Some random number generators can only generate a limit amount of random bytes per invocation. If the size of {@code bytes} is greater than this limit, the implementation should invoke the process multiple times to generate enough random bytes in a single {@code engineNextBytes} call. > >>>> *** I am not sure what you are asking of reseeding. UnsupportedOperationException not enough? >>> >>> My comment was that if I specify PR here and the impl doesn't support reseeding, is that an IllegalArgument exception? >> >> It will be UnsupportedOperationException. I add a line saying the method must not be implemented. > > I wonder, would you ever have a situation where reseed() might be overridden, but still illegal in some case. If so, maybe... If not, never mind. > > @throws UnsupportedOperationException if the underlying provider > implementation has not overridden this method. > -> > @throws UnsupportedOperationException if the underlying provider > implementation has not overridden this method or does not > support this operation. I added in SecureRandomSpi#engineReseed: * Do not override this method if the implementation does not * support reseeding. Thanks Max From weijun.wang at oracle.com Thu Apr 28 03:55:32 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 28 Apr 2016 11:55:32 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <16410FF9-D4A6-4FA5-BCC6-F9AE5341F1F1@oracle.com> <74879272-ac24-b389-92fd-c9242ebab8a3@oracle.com> <1DA968F9-2A7B-4C77-AAA0-2280E9BB94E1@oracle.com> <512f8dbc-0105-7868-3ba0-a7c16104ec09@oracle.com> Message-ID: <5360E465-6007-46F5-A108-84CD3926C36E@oracle.com> http://cr.openjdk.java.net/~weijun/8051408/webrev.13 http://cr.openjdk.java.net/~weijun/8051408/webrev.13/spec http://cr.openjdk.java.net/~weijun/8051408/webrev.13/specdiff Another update. 1. Comment out health test for the moment. 2. Remove the following words in SecureRandom#nextBytes: - * If the underlying implementation is prohibited from supplying a - * full arrays worth of data, the application must repeatedly call - * its generation algorithm until all elements in {@code bytes} are - * filled with random data. Instead, add these into SecureRandomSpi#engineNextBytes: + * Some random number generators can only generate a limit amount + * of random bytes per invocation. If the size of {@code bytes} + * is greater than this limit, the implementation should invoke + * the generation process multiple times to generate enough random bytes + * in a single {@code engineNextBytes} call. Thanks Max From thomas.stuefe at gmail.com Thu Apr 28 12:40:46 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 28 Apr 2016 14:40:46 +0200 Subject: RFR(xs): 8155211: Ucrypto Library leaks native memory Message-ID: Hi all, could you please review this small fix? Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8155211-ucrypto-lib-mem-leak/webrev.00/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8155211 Basically, during benchmarks our Solaris VMs went out-of-native-memory; when we investigated, we saw ~31million small lost allocations from nativeCrypto.c:663. Looking at the source shows that the output buffer is not deallocated if outLen is 0. outLen can be 0 if the java output buffer was len 0 to begin with, or if the outOfs equals output array len, or if CipherFinal returns 0. In the first two cases we will call calloc(0), which on Solaris is implemented as a real calloc (returns a unique pointer which needs to be freed). I changed the coding to always free the internal buffers. I also removed the (bufOut != NULL) condition from SetByteArrayRegion, because that should be always true at this point. Kind Regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Thu Apr 28 16:12:01 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 28 Apr 2016 19:12:01 +0300 Subject: RFR(xs): 8155211: Ucrypto Library leaks native memory In-Reply-To: References: Message-ID: Hi Thomas! Wouldn't it make sense to declare unsigned char bufOut[1]; and avoid allocation/deallocation of this buffer altogether? With kind regards, Ivan On 28.04.2016 15:40, Thomas St?fe wrote: > Hi all, > > could you please review this small fix? > > Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8155211-ucrypto-lib-mem-leak/webrev.00/webrev/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8155211 > > Basically, during benchmarks our Solaris VMs went > out-of-native-memory; when we investigated, we saw ~31million small > lost allocations from nativeCrypto.c:663. Looking at the source shows > that the output buffer is not deallocated if outLen is 0. > > outLen can be 0 if the java output buffer was len 0 to begin with, or > if the outOfs equals output array len, or if CipherFinal returns 0. In > the first two cases we will call calloc(0), which on Solaris is > implemented as a real calloc (returns a unique pointer which needs to > be freed). > > I changed the coding to always free the internal buffers. I also > removed the (bufOut != NULL) condition from SetByteArrayRegion, > because that should be always true at this point. > > Kind Regards, Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svetlana.nikandrova at oracle.com Thu Apr 28 17:35:39 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Thu, 28 Apr 2016 20:35:39 +0300 Subject: [8u-dev] Request for Review + Request for Approval for Backport 8049171: Additional tests for jarsigner's warnings Message-ID: <572249EB.8090808@oracle.com> Hello, please review and approve the backport of tests enhancement: Original tests from https://bugs.openjdk.java.net/browse/JDK-8049171 jdk 9 review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-January/031006.html jdk 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5c61ccd9c162 Originally reviewed by Max Wang Webrev: http://cr.openjdk.java.net/~snikandrova/8049171/webrev.00/ List of changes between original patch and current webrev: 1) No ProcessTools.java changes as they have been backported earlier. 2) JarUtils.java : private method transferToOutputStream instead ofInputStream's transferTo method (present since 9). 3) TimestampCheck.java - changes applied by hand to omit System.getProperty("test.tool.vm.opts") that is not used in jdk 8 testing 4) Used System.getProperty("test.jdk") instead of System.getProperty("java.home") Tested with JPRT. Thank you, Svetlana From bradford.wetmore at oracle.com Thu Apr 28 18:46:32 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 28 Apr 2016 11:46:32 -0700 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <50FC89C3-C2E1-4DB3-BE40-BC118AF3945F@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <16410FF9-D4A6-4FA5-BCC6-F9AE5341F1F1@oracle.com> <74879272-ac24-b389-92fd-c9242ebab8a3@oracle.com> <1DA968F9-2A7B-4C77-AAA0-2280E9BB94E1@oracle.com> <512f8dbc-0105-7868-3ba0-a7c16104ec09@oracle.com> <50FC89C3-C2E1-4DB3-BE40-BC118AF3945F@oracle.com> Message-ID: <89757dba-98b1-9208-df00-7647a880e9ea@oracle.com> On 4/27/2016 7:16 PM, Wang Weijun wrote: > >> On Apr 28, 2016, at 8:50 AM, Bradford Wetmore wrote: >> >> I won't have the cycles to do another full review, but just looked over things I mentioned in my previous review, and things are looking good! I have to jump back to my other projects. > > Thanks, there are still several thing to discuss. The one important is about nextBytes. Read below. > >> DrbgParameters.java >> =================== >> >> Did you want to add an implNote that the "java.security" file or the Security Property configures the choice entropy/mechanism/etc? > > The @implNote already has > > * The mechanism name and DRBG algorithm name are determined by the > * {@linkplain Security#getProperty(String) security property} > * {@code securerandom.drbg.config}. The default choice is Hash_DRBG > * with SHA-256. > > and > > * This implementation reads fresh entropy from the system default entropy > * source determined by the security property {@code securerandom.source}. > > Do I need to mention "java.security"? I don't know what I was thinking, maybe in another file? Obviously it is there. Please ignore this comment. :( >>>>>> java/security/Provider.java >>>>>> =========================== >>>> >>>>>> I'm really tempted to file a bug to clean up the really long lines added >>>>>> by the lambda folks. Ugh...This make reviewing changes in frame-based >>>>>> webrevs hard. > >> I would say file another bug > > https://bugs.openjdk.java.net/browse/JDK-8155575 filed. I added you as a watcher. Great, thanks. >>>>>> java/security/SecureRandom.java >>>>>> =============================== >>>> >>>>>> >>> >>> https://bugs.openjdk.java.net/browse/JDK-8155191 filed. >> >> Thanks. Are you going to handle as a separate putback, or part of this one? The timing is probably better (an additional CCC) if you do later, but it does add overhead because it would require a separate outback. > > A separate push. Ok. >>>>>> XXX: what do you do bout large size requests or things that can't be >>>>>> reseeded? >>>>> >> >> This wording is a little awkward, given the currently available APIs. Since we don't have a pos/offset nextBytes() variant, so maybe something like: >> >> * If the underlying implementation (for example: DRBG) is prohibited >> * from supplying the requested amount of data in a single call, the >> * application should retry by breaking the request into multiple >> * smaller requests. > > I think there is a problem here. > > We should not ask an application to call it multiple times because it does not know what the max size is. Instead, the implementation should always fill in all bytes. I'd like to add some words in SecureRandomSpi#engineNextBytes: > > Some random number generators can only generate a limit amount > of random bytes per invocation. If the size of {@code bytes} > is greater than this limit, the implementation should invoke > the process multiple times to generate enough random bytes > in a single {@code engineNextBytes} call. We were on the same page after all. I completely misunderstood your point in a previous email. What you have is fine (change limit->limited), or a minor suggestion below (take it or leave it): Some random number generators can only generate a limit amount of random bytes per invocation. If the size of {@code bytes} is greater than this limit, the implementation should invoke the process multiple times to generate enough random bytes in a single {@code engineNextBytes} call. -> Some random number generators can only generate a limited amount of random bytes per invocation. If the size of {@code bytes} is greater than this limit, the implementation should invoke its generation process multiple times to completely fill the buffer before returning from this method. >>>>> *** I am not sure what you are asking of reseeding. UnsupportedOperationException not enough? >>>> >>>> My comment was that if I specify PR here and the impl doesn't support reseeding, is that an IllegalArgument exception? >>> >>> It will be UnsupportedOperationException. I add a line saying the method must not be implemented. >> >> I wonder, would you ever have a situation where reseed() might be overridden, but still illegal in some case. If so, maybe... If not, never mind. >> >> @throws UnsupportedOperationException if the underlying provider >> implementation has not overridden this method. >> -> >> @throws UnsupportedOperationException if the underlying provider >> implementation has not overridden this method or does not >> support this operation. > > I added in SecureRandomSpi#engineReseed: > > * Do not override this method if the implementation does not > * support reseeding. Ok. Brad From valerie.peng at oracle.com Thu Apr 28 19:58:28 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 28 Apr 2016 12:58:28 -0700 Subject: RFR(xs): 8155211: Ucrypto Library leaks native memory In-Reply-To: References: Message-ID: <57226B64.2030002@oracle.com> Interesting... That's a very good catch. The webrev looks fine to me. Valerie On 4/28/2016 5:40 AM, Thomas St?fe wrote: > Hi all, > > could you please review this small fix? > > Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8155211-ucrypto-lib-mem-leak/webrev.00/webrev/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8155211 > > Basically, during benchmarks our Solaris VMs went > out-of-native-memory; when we investigated, we saw ~31million small > lost allocations from nativeCrypto.c:663. Looking at the source shows > that the output buffer is not deallocated if outLen is 0. > > outLen can be 0 if the java output buffer was len 0 to begin with, or > if the outOfs equals output array len, or if CipherFinal returns 0. In > the first two cases we will call calloc(0), which on Solaris is > implemented as a real calloc (returns a unique pointer which needs to > be freed). > > I changed the coding to always free the internal buffers. I also > removed the (bufOut != NULL) condition from SetByteArrayRegion, > because that should be always true at this point. > > Kind Regards, Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Thu Apr 28 20:51:15 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 28 Apr 2016 23:51:15 +0300 Subject: RFR(xs): 8155211: Ucrypto Library leaks native memory In-Reply-To: References: Message-ID: <77129f48-91b6-f8f8-9143-9151dab48c2d@oracle.com> Ah, please ignore my previous message, I read the code wrongly. Your fix looks good. With kind regards, Ivan On 28.04.2016 19:12, Ivan Gerasimov wrote: > > Hi Thomas! > > Wouldn't it make sense to declare > > unsigned char bufOut[1]; > > and avoid allocation/deallocation of this buffer altogether? > > > With kind regards, > > Ivan > > > On 28.04.2016 15:40, Thomas St?fe wrote: >> Hi all, >> >> could you please review this small fix? >> >> Webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8155211-ucrypto-lib-mem-leak/webrev.00/webrev/ >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8155211 >> >> Basically, during benchmarks our Solaris VMs went >> out-of-native-memory; when we investigated, we saw ~31million small >> lost allocations from nativeCrypto.c:663. Looking at the source shows >> that the output buffer is not deallocated if outLen is 0. >> >> outLen can be 0 if the java output buffer was len 0 to begin with, or >> if the outOfs equals output array len, or if CipherFinal returns 0. >> In the first two cases we will call calloc(0), which on Solaris is >> implemented as a real calloc (returns a unique pointer which needs to >> be freed). >> >> I changed the coding to always free the internal buffers. I also >> removed the (bufOut != NULL) condition from SetByteArrayRegion, >> because that should be always true at this point. >> >> Kind Regards, Thomas >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Apr 28 23:45:44 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 29 Apr 2016 07:45:44 +0800 Subject: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <89757dba-98b1-9208-df00-7647a880e9ea@oracle.com> References: <7534310A-A5EA-449C-8FE3-98001379A59A@oracle.com> <56FD7955.7060202@oracle.com> <5D9115D0-C59E-410F-8AEB-1A67997E8EAA@oracle.com> <81FE0819-F747-4119-9CDA-7B6F42F93CAE@oracle.com> <534ECC0A-7B9B-4487-B4FB-D384573BA077@oracle.com> <57162E25.4090805@oracle.com> <16410FF9-D4A6-4FA5-BCC6-F9AE5341F1F1@oracle.com> <74879272-ac24-b389-92fd-c9242ebab8a3@oracle.com> <1DA968F9-2A7B-4C77-AAA0-2280E9BB94E1@oracle.com> <512f8dbc-0105-7868-3ba0-a7c16104ec09@oracle.com> <50FC89C3-C2E1-4DB3-BE40-BC118AF3945F@oracle.com> <89757dba-98b1-9208-df00-7647a880e9ea@oracle.com> Message-ID: <7C38A4D6-F2B7-4DDA-8B50-45DAB9A31DF2@oracle.com> > On Apr 29, 2016, at 2:46 AM, Bradford Wetmore wrote: > > to completely fill the > buffer before returning from this method. This is more clear. I'll update but will not send out a new webrev. Thanks Max From thomas.stuefe at gmail.com Fri Apr 29 04:30:17 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 29 Apr 2016 06:30:17 +0200 Subject: RFR(xs): 8155211: Ucrypto Library leaks native memory In-Reply-To: <57226B64.2030002@oracle.com> References: <57226B64.2030002@oracle.com> Message-ID: Thank you, Valerie! On Thu, Apr 28, 2016 at 9:58 PM, Valerie Peng wrote: > > Interesting... That's a very good catch. > The webrev looks fine to me. > Valerie > > > > On 4/28/2016 5:40 AM, Thomas St?fe wrote: > > Hi all, > > could you please review this small fix? > > Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8155211-ucrypto-lib-mem-leak/webrev.00/webrev/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8155211 > > Basically, during benchmarks our Solaris VMs went out-of-native-memory; > when we investigated, we saw ~31million small lost allocations from > nativeCrypto.c:663. Looking at the source shows that the output buffer is > not deallocated if outLen is 0. > > outLen can be 0 if the java output buffer was len 0 to begin with, or if > the outOfs equals output array len, or if CipherFinal returns 0. In the > first two cases we will call calloc(0), which on Solaris is implemented as > a real calloc (returns a unique pointer which needs to be freed). > > I changed the coding to always free the internal buffers. I also removed > the (bufOut != NULL) condition from SetByteArrayRegion, because that should > be always true at this point. > > Kind Regards, Thomas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Fri Apr 29 04:30:28 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 29 Apr 2016 06:30:28 +0200 Subject: RFR(xs): 8155211: Ucrypto Library leaks native memory In-Reply-To: <77129f48-91b6-f8f8-9143-9151dab48c2d@oracle.com> References: <77129f48-91b6-f8f8-9143-9151dab48c2d@oracle.com> Message-ID: Thanks Ivan! On Thu, Apr 28, 2016 at 10:51 PM, Ivan Gerasimov wrote: > Ah, please ignore my previous message, I read the code wrongly. > > Your fix looks good. > > With kind regards, > > Ivan > > On 28.04.2016 19:12, Ivan Gerasimov wrote: > > Hi Thomas! > > Wouldn't it make sense to declare > > unsigned char bufOut[1]; > > and avoid allocation/deallocation of this buffer altogether? > > > With kind regards, > > Ivan > > > On 28.04.2016 15:40, Thomas St?fe wrote: > > Hi all, > > could you please review this small fix? > > Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8155211-ucrypto-lib-mem-leak/webrev.00/webrev/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8155211 > > Basically, during benchmarks our Solaris VMs went out-of-native-memory; > when we investigated, we saw ~31million small lost allocations from > nativeCrypto.c:663. Looking at the source shows that the output buffer is > not deallocated if outLen is 0. > > outLen can be 0 if the java output buffer was len 0 to begin with, or if > the outOfs equals output array len, or if CipherFinal returns 0. In the > first two cases we will call calloc(0), which on Solaris is implemented as > a real calloc (returns a unique pointer which needs to be freed). > > I changed the coding to always free the internal buffers. I also removed > the (bufOut != NULL) condition from SetByteArrayRegion, because that should > be always true at this point. > > Kind Regards, Thomas > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Apr 29 14:40:54 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 29 Apr 2016 10:40:54 -0400 Subject: CFV: New Security Group Member: Jamil Nimeh Message-ID: <57237276.9040606@oracle.com> I hereby nominate Jamil Nimeh to Membership in the Security Group. Jamil is a member of the Java Security Libraries team at Oracle and has been an active contributor to the OpenJDK Security Group for approximately two years. Jamil was voted in as a JDK 9 committer in April, 2015, and has continued to play an active role working on the security components of the JDK. Jamil has integrated many significant bug fixes and enhancements especially in the PKI and TLS areas. He is also the owner of JEP 249 ("OCSP Stapling for TLS"), which has successfully reached Completed status for JDK 9. Votes are due by May 13, 2016, 3:00 PM UTC. Only current Members of the Security Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Sean Mullan [1] http://openjdk.java.net/census#security [2] http://openjdk.java.net/groups/#member-vote From sean.mullan at oracle.com Fri Apr 29 14:43:08 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 29 Apr 2016 10:43:08 -0400 Subject: CFV: New Security Group Member: Jamil Nimeh In-Reply-To: <57237276.9040606@oracle.com> References: <57237276.9040606@oracle.com> Message-ID: <572372FC.7060607@oracle.com> Vote: yes On 04/29/2016 10:40 AM, Sean Mullan wrote: > I hereby nominate Jamil Nimeh to Membership in the Security Group. > > Jamil is a member of the Java Security Libraries team at Oracle and has > been an active contributor to the OpenJDK Security Group for > approximately two years. Jamil was voted in as a JDK 9 committer in > April, 2015, and has continued to play an active role working on the > security components of the JDK. Jamil has integrated many significant > bug fixes and enhancements especially in the PKI and TLS areas. He is > also the owner of JEP 249 ("OCSP Stapling for TLS"), which has > successfully reached Completed status for JDK 9. > > Votes are due by May 13, 2016, 3:00 PM UTC. > > Only current Members of the Security Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Sean Mullan > > [1] http://openjdk.java.net/census#security > [2] http://openjdk.java.net/groups/#member-vote > From anthony.scarpino at oracle.com Fri Apr 29 14:45:16 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 29 Apr 2016 07:45:16 -0700 Subject: CFV: New Security Group Member: Jamil Nimeh In-Reply-To: <572372FC.7060607@oracle.com> References: <57237276.9040606@oracle.com> <572372FC.7060607@oracle.com> Message-ID: <742ECBBC-B9DF-49C6-8853-00E914EF80CA@oracle.com> Vote: Yes > On Apr 29, 2016, at 7:43 AM, Sean Mullan wrote: > > Vote: yes > >> On 04/29/2016 10:40 AM, Sean Mullan wrote: >> I hereby nominate Jamil Nimeh to Membership in the Security Group. >> >> Jamil is a member of the Java Security Libraries team at Oracle and has >> been an active contributor to the OpenJDK Security Group for >> approximately two years. Jamil was voted in as a JDK 9 committer in >> April, 2015, and has continued to play an active role working on the >> security components of the JDK. Jamil has integrated many significant >> bug fixes and enhancements especially in the PKI and TLS areas. He is >> also the owner of JEP 249 ("OCSP Stapling for TLS"), which has >> successfully reached Completed status for JDK 9. >> >> Votes are due by May 13, 2016, 3:00 PM UTC. >> >> Only current Members of the Security Group [1] are eligible to vote on >> this nomination. Votes must be cast in the open by replying to this >> mailing list. >> >> For Lazy Consensus voting instructions, see [2]. >> >> Sean Mullan >> >> [1] http://openjdk.java.net/census#security >> [2] http://openjdk.java.net/groups/#member-vote >> From vincent.x.ryan at oracle.com Fri Apr 29 14:42:05 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 29 Apr 2016 15:42:05 +0100 Subject: CFV: New Security Group Member: Jamil Nimeh In-Reply-To: <57237276.9040606@oracle.com> References: <57237276.9040606@oracle.com> Message-ID: <7E5023F9-56E0-4B9D-BFA2-A1E60E6870D1@oracle.com> Vote: yes > On 29 Apr 2016, at 15:40, Sean Mullan wrote: > > I hereby nominate Jamil Nimeh to Membership in the Security Group. > > Jamil is a member of the Java Security Libraries team at Oracle and has been an active contributor to the OpenJDK Security Group for approximately two years. Jamil was voted in as a JDK 9 committer in April, 2015, and has continued to play an active role working on the security components of the JDK. Jamil has integrated many significant bug fixes and enhancements especially in the PKI and TLS areas. He is also the owner of JEP 249 ("OCSP Stapling for TLS"), which has successfully reached Completed status for JDK 9. > > Votes are due by May 13, 2016, 3:00 PM UTC. > > Only current Members of the Security Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Sean Mullan > > [1] http://openjdk.java.net/census#security > [2] http://openjdk.java.net/groups/#member-vote > From weijun.wang at oracle.com Fri Apr 29 15:13:47 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 29 Apr 2016 23:13:47 +0800 Subject: CFV: New Security Group Member: Jamil Nimeh In-Reply-To: <57237276.9040606@oracle.com> References: <57237276.9040606@oracle.com> Message-ID: <0F1A8F0C-3DB8-4504-9D4A-C164CFCCA8A4@oracle.com> Vote: Yes. --Weijun > On Apr 29, 2016, at 10:40 PM, Sean Mullan wrote: > > I hereby nominate Jamil Nimeh to Membership in the Security Group. From xuelei.fan at oracle.com Fri Apr 29 16:24:56 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 30 Apr 2016 00:24:56 +0800 Subject: CFV: New Security Group Member: Jamil Nimeh In-Reply-To: <57237276.9040606@oracle.com> References: <57237276.9040606@oracle.com> Message-ID: <947a9b50-3aad-0f22-0c80-d19f68e743ba@oracle.com> Vote: Yes. Xuelei On 4/29/2016 10:40 PM, Sean Mullan wrote: > I hereby nominate Jamil Nimeh to Membership in the Security Group. > > Jamil is a member of the Java Security Libraries team at Oracle and has > been an active contributor to the OpenJDK Security Group for > approximately two years. Jamil was voted in as a JDK 9 committer in > April, 2015, and has continued to play an active role working on the > security components of the JDK. Jamil has integrated many significant > bug fixes and enhancements especially in the PKI and TLS areas. He is > also the owner of JEP 249 ("OCSP Stapling for TLS"), which has > successfully reached Completed status for JDK 9. > > Votes are due by May 13, 2016, 3:00 PM UTC. > > Only current Members of the Security Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Sean Mullan > > [1] http://openjdk.java.net/census#security > [2] http://openjdk.java.net/groups/#member-vote > From bradford.wetmore at oracle.com Fri Apr 29 17:38:59 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 29 Apr 2016 10:38:59 -0700 Subject: CFV: New Security Group Member: Jamil Nimeh In-Reply-To: <947a9b50-3aad-0f22-0c80-d19f68e743ba@oracle.com> References: <57237276.9040606@oracle.com> <947a9b50-3aad-0f22-0c80-d19f68e743ba@oracle.com> Message-ID: <820bba1e-c067-6e34-8d38-f72ca2b92a64@oracle.com> Vote: yes Brad On 4/29/2016 9:24 AM, Xuelei Fan wrote: > Vote: Yes. > > Xuelei > > On 4/29/2016 10:40 PM, Sean Mullan wrote: >> I hereby nominate Jamil Nimeh to Membership in the Security Group. >> >> Jamil is a member of the Java Security Libraries team at Oracle and has >> been an active contributor to the OpenJDK Security Group for >> approximately two years. Jamil was voted in as a JDK 9 committer in >> April, 2015, and has continued to play an active role working on the >> security components of the JDK. Jamil has integrated many significant >> bug fixes and enhancements especially in the PKI and TLS areas. He is >> also the owner of JEP 249 ("OCSP Stapling for TLS"), which has >> successfully reached Completed status for JDK 9. >> >> Votes are due by May 13, 2016, 3:00 PM UTC. >> >> Only current Members of the Security Group [1] are eligible to vote on >> this nomination. Votes must be cast in the open by replying to this >> mailing list. >> >> For Lazy Consensus voting instructions, see [2]. >> >> Sean Mullan >> >> [1] http://openjdk.java.net/census#security >> [2] http://openjdk.java.net/groups/#member-vote >> > From valerie.peng at oracle.com Fri Apr 29 20:32:41 2016 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 29 Apr 2016 13:32:41 -0700 Subject: CFV: New Security Group Member: Jamil Nimeh In-Reply-To: <820bba1e-c067-6e34-8d38-f72ca2b92a64@oracle.com> References: <57237276.9040606@oracle.com> <947a9b50-3aad-0f22-0c80-d19f68e743ba@oracle.com> <820bba1e-c067-6e34-8d38-f72ca2b92a64@oracle.com> Message-ID: <5723C4E9.3080803@oracle.com> Vote: yes Valerie On 4/29/2016 10:38 AM, Bradford Wetmore wrote: > Vote: yes > > Brad > > > > On 4/29/2016 9:24 AM, Xuelei Fan wrote: >> Vote: Yes. >> >> Xuelei >> >> On 4/29/2016 10:40 PM, Sean Mullan wrote: >>> I hereby nominate Jamil Nimeh to Membership in the Security Group. >>> >>> Jamil is a member of the Java Security Libraries team at Oracle and >>> has >>> been an active contributor to the OpenJDK Security Group for >>> approximately two years. Jamil was voted in as a JDK 9 committer in >>> April, 2015, and has continued to play an active role working on the >>> security components of the JDK. Jamil has integrated many significant >>> bug fixes and enhancements especially in the PKI and TLS areas. He is >>> also the owner of JEP 249 ("OCSP Stapling for TLS"), which has >>> successfully reached Completed status for JDK 9. >>> >>> Votes are due by May 13, 2016, 3:00 PM UTC. >>> >>> Only current Members of the Security Group [1] are eligible to vote on >>> this nomination. Votes must be cast in the open by replying to this >>> mailing list. >>> >>> For Lazy Consensus voting instructions, see [2]. >>> >>> Sean Mullan >>> >>> [1] http://openjdk.java.net/census#security >>> [2] http://openjdk.java.net/groups/#member-vote >>> >>