From sean.mullan at oracle.com Tue Jan 2 19:40:31 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 2 Jan 2018 14:40:31 -0500 Subject: [11] CSR RFR 8193916: Remove deprecated javax.security.auth.Policy API In-Reply-To: References: Message-ID: On 12/20/17 8:29 PM, Weijun Wang wrote: > Please take a review at > > https://bugs.openjdk.java.net/browse/JDK-8193916 Looks good to me. > I'm thinking about file an issue https://github.com/javaee/glassfish/issues requesting for the removal of javax.security.auth.Policy-related code. Is that good? Sure, it sounds ok to me. You should point to this issue and note that it will be removed in JDK 11. --Sean From ivan.gerasimov at oracle.com Wed Jan 3 01:16:55 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 2 Jan 2018 17:16:55 -0800 Subject: [8u-dev] Request to Review and for Approval to Backport 8192987 : keytool should remember real storetype if it is not provided Message-ID: <44aec628-91f5-0a3a-5db0-72f17f971a5f@oracle.com> Hello! I'd like to backport this fix to JDK 8u-dev. The patch did NOT apply cleanly, thus a Review request. Patched JDK builds fine on all platforms, the tests pass well. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8192987 WEBREV: http://cr.openjdk.java.net/~igerasim/8192987/00/webrev/ JDK 10 Change: http://hg.openjdk.java.net/jdk/jdk/rev/e3b6cb90d7ce JDK 10 Review: http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016613.html Thanks in advance! -- With kind regards, Ivan Gerasimov From weijun.wang at oracle.com Wed Jan 3 02:44:47 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 3 Jan 2018 10:44:47 +0800 Subject: [8u-dev] Request to Review and for Approval to Backport 8192987 : keytool should remember real storetype if it is not provided In-Reply-To: <44aec628-91f5-0a3a-5db0-72f17f971a5f@oracle.com> References: <44aec628-91f5-0a3a-5db0-72f17f971a5f@oracle.com> Message-ID: <00ECEE2F-0184-4FF7-9873-E0DE39E29DB0@oracle.com> The code change looks fine to me. Thanks Max > On Jan 3, 2018, at 9:16 AM, Ivan Gerasimov wrote: > > Hello! > > I'd like to backport this fix to JDK 8u-dev. > > The patch did NOT apply cleanly, thus a Review request. > > Patched JDK builds fine on all platforms, the tests pass well. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8192987 > WEBREV: http://cr.openjdk.java.net/~igerasim/8192987/00/webrev/ > JDK 10 Change: http://hg.openjdk.java.net/jdk/jdk/rev/e3b6cb90d7ce > JDK 10 Review: http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016613.html > > Thanks in advance! > > -- > With kind regards, > Ivan Gerasimov > From sean.coffey at oracle.com Wed Jan 3 08:33:06 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 3 Jan 2018 08:33:06 +0000 Subject: [8u-dev] Request to Review and for Approval to Backport 8192987 : keytool should remember real storetype if it is not provided In-Reply-To: <00ECEE2F-0184-4FF7-9873-E0DE39E29DB0@oracle.com> References: <44aec628-91f5-0a3a-5db0-72f17f971a5f@oracle.com> <00ECEE2F-0184-4FF7-9873-E0DE39E29DB0@oracle.com> Message-ID: Looks fine. Approved for jdk8u-dev. regards, Sean. On 03/01/2018 02:44, Weijun Wang wrote: > The code change looks fine to me. > > Thanks > Max > >> On Jan 3, 2018, at 9:16 AM, Ivan Gerasimov wrote: >> >> Hello! >> >> I'd like to backport this fix to JDK 8u-dev. >> >> The patch did NOT apply cleanly, thus a Review request. >> >> Patched JDK builds fine on all platforms, the tests pass well. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8192987 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8192987/00/webrev/ >> JDK 10 Change: http://hg.openjdk.java.net/jdk/jdk/rev/e3b6cb90d7ce >> JDK 10 Review: http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016613.html >> >> Thanks in advance! >> >> -- >> With kind regards, >> Ivan Gerasimov >> From adam.petcher at oracle.com Wed Jan 3 16:26:18 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 3 Jan 2018 11:26:18 -0500 Subject: API review for X25519/X448 Message-ID: <9425dc17-1099-9544-d314-95ab9d56bc47@oracle.com> Now that the JEP[1] for X25519/X448 key agreement is a candidate, we can proceed with the API and specification review. Please review the proposed API spec[2] and provide comments by the end of Saturday,? January 13, anywhere on earth. At that point, I will combine your feedback with the initial feedback from the CSR group[3] and submit the API for final review by the CSR. The only significant change to the API since our last discussion[4] is that I changed the names of the key specs and interfaces from "XDH..." to "XEC..." This makes them more general and reusable in things like XEdDSA[5] and other non-Diffie-Hellman cryptosystems based on the representations/operations defined in RFC 7748[6]. [1] http://openjdk.java.net/jeps/324 [2] https://bugs.openjdk.java.net/browse/JDK-8189806 [3] https://wiki.openjdk.java.net/display/csr/Main [4] http://mail.openjdk.java.net/pipermail/security-dev/2017-September/016325.html [5] https://signal.org/docs/specifications/xeddsa/ [6] https://tools.ietf.org/html/rfc7748 From anders.rundgren.net at gmail.com Wed Jan 3 16:53:15 2018 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Wed, 3 Jan 2018 17:53:15 +0100 Subject: API review for X25519/X448 In-Reply-To: <9425dc17-1099-9544-d314-95ab9d56bc47@oracle.com> References: <9425dc17-1099-9544-d314-95ab9d56bc47@oracle.com> Message-ID: On 2018-01-03 17:26, Adam Petcher wrote: Since this is quite similar to what I proposed some 6 month ago https://github.com/cyberphone/java-cfrg-spec I can only give it a +100 :-) Cheers, Anders now looking forward to the signature support. > Now that the JEP[1] for X25519/X448 key agreement is a candidate, we can > proceed with the API and specification review. Please review the > proposed API spec[2] and provide comments by the end of Saturday, > January 13, anywhere on earth. At that point, I will combine your > feedback with the initial feedback from the CSR group[3] and submit the > API for final review by the CSR. > > The only significant change to the API since our last discussion[4] is > that I changed the names of the key specs and interfaces from "XDH..." > to "XEC..." This makes them more general and reusable in things like > XEdDSA[5] and other non-Diffie-Hellman cryptosystems based on the > representations/operations defined in RFC 7748[6]. > > [1] http://openjdk.java.net/jeps/324 > [2] https://bugs.openjdk.java.net/browse/JDK-8189806 > [3] https://wiki.openjdk.java.net/display/csr/Main > [4] > http://mail.openjdk.java.net/pipermail/security-dev/2017-September/016325.html > [5] https://signal.org/docs/specifications/xeddsa/ > [6] https://tools.ietf.org/html/rfc7748 > From adam.petcher at oracle.com Wed Jan 3 19:36:20 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 3 Jan 2018 14:36:20 -0500 Subject: API review for X25519/X448 In-Reply-To: <9425dc17-1099-9544-d314-95ab9d56bc47@oracle.com> References: <9425dc17-1099-9544-d314-95ab9d56bc47@oracle.com> Message-ID: <9a46a28b-1fbe-13a2-8b81-507e9438667d@oracle.com> +core-libs-dev (to get some additional API guidance) On 1/3/2018 11:26 AM, Adam Petcher wrote: > Now that the JEP[1] for X25519/X448 key agreement is a candidate, we > can proceed with the API and specification review. Please review the > proposed API spec[2] and provide comments by the end of Saturday,? > January 13, anywhere on earth. At that point, I will combine your > feedback with the initial feedback from the CSR group[3] and submit > the API for final review by the CSR. > > The only significant change to the API since our last discussion[4] is > that I changed the names of the key specs and interfaces from "XDH..." > to "XEC..." This makes them more general and reusable in things like > XEdDSA[5] and other non-Diffie-Hellman cryptosystems based on the > representations/operations defined in RFC 7748[6]. > > [1] http://openjdk.java.net/jeps/324 > [2] https://bugs.openjdk.java.net/browse/JDK-8189806 > [3] https://wiki.openjdk.java.net/display/csr/Main > [4] > http://mail.openjdk.java.net/pipermail/security-dev/2017-September/016325.html > [5] https://signal.org/docs/specifications/xeddsa/ > [6] https://tools.ietf.org/html/rfc7748 > From jamil.j.nimeh at oracle.com Thu Jan 4 00:04:43 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 3 Jan 2018 16:04:43 -0800 Subject: Code Review Request, JDK-8185576 : New handshake implementation In-Reply-To: References: Message-ID: Hi Xuelei, I'm only part way through this but I wanted to give you what I had so far. I'm working on the new files now so hopefully I'll have the rest of them done tomorrow. * CipherBox.java o 146: Were you intending to leave that commented protocol version line in there in the short term? If not then maybe remove it. * DTLSInputRecord.java o 130: Remove @Override comment, doesn't look like you need it. * DTLSOutpuTRecord.java o 58: Remove comment line for this.protocolVersion * HandshakeHash.java o 44: Nit: trhe -> the o 83-87: Do you need to do Arrays.copyOf() on holder? It seems like you could just add holder directly to the reserves list rather than duplicate it. o 509 and others: Nit: ClonableHash -> CloneableHash o 537 and others: Nit: NoneClonableHash -> NonCloneableHash * JsseJce.java o 55-61: Does the static initializer for the ClientKeyExchangeService still need to be there? It's commented out right now. * MAC.java o 190: Typo in comment "the the" * ProtocolVersion o 167: I don't think you need to mask with "& 0xFF" since you're doing a primitive narrowing conversion to byte from int. That already lops off the upper 24 bits. But it's fine if you wish to keep it, too. o 254: In order to be consistent with the unmodifiable empty list return on 257 consider doing "return Collections.unmodifiableList(pvs)" here. If you're expecting to make changes to the list if it is non-empty, then disregard this comment. o 267: Nit: "pv .id" (note the extra space). Not sure if that's webrev rendering or you really have that extra space in there. o 267: For the first clause in the ternary expression (DTLS) shouldn't the comparison be <= instead of >=? * SSLAlgorithmDecomposer.java o 132-138: Do you still want to hang onto this commented-out block of code? * SSLContextImpl.java o 889 & 896: Will these commented-out lines be temporary and be uncommented once the 1.3 handshake is done? * SSLEngineInputRecord.java o 287: Would this be a good place to use Record.getInt24()? o 319: This is just a nit, you don't need to do it, but it would look a bit cleaner to do ByteBuffer.allocate(handshakeBuffer.remaining() + fragment.remaining()). You'll still have a backing array according to the docs. o 338: Another spot for Record.getInt24() maybe. * SSLSessionImpl.java o 435 & 440, 492 & 497, and others: There are multiple places where ClientKeyExchangeService.find() calls are commented out. Similar to the other places where there are commented blocks, are these needed for future integration with the 1.3 handshake code? * SSLSocketInputRecord.java o Similar to the comment on SSLEngineInputRecord.java:319: you could do ByteBuffer.allocate() and bypass the explicit byte[] constructor call. o 333: Another spot you could use Record.getInt24(). * SignatureAlgorithmsExtension.java o 276: The hashAlgorithms array appears to be missing "sha384" at index 5. * SupportedGroupsExtension.java o 309: Cut-n-paste bug: x448's ID should be 0x001E and the fourth field should be "x448" --Jamil On 12/15/2017 08:20 PM, Xuelei Fan wrote: > Hi, > > Please review the change: > http://cr.openjdk.java.net/~xuelei/8185576/webrev.00/ > > This fix is trying to re-org the TLS handshaking implementation in the > SunJSSE provider. > > The handshaking process in TLS 1.3 is lot different from that of TLS > 1.2. For TLS 1.3 implementation, it is not straightforward any more > to use the existing state machines for TLS 1.2. For example, in TLS > specification, the handshake message must be delivered in strict > order. The handshake message order in TLS 1.3 protocol is re-designed > and significant different from that of TLS 1.2. If we re-use the > state machine for TLS 1.3 and 1.2 and previous versions, the state > machine becomes very complicated and hard to maintain. > > We are consider to simplify the handshake implementation by: > 1. Use difference handshake handler for different TLS versions. > 2. Improved message driven handler for different handshake messages. > > The basic ideas for the simplification look like: > 1. message/even driving handshake processing model. > An actor is a stateless service that is used to consume an input > message, or produce output message, or both. > message A message B > --------------> Actor A ------------> Actor B > > 2. immutable actor and centralized states. > Handshake states are represent in context objects (ConnectionContext), > and the context object is passed to each actor. An actor can update > the state in the context object accordingly. At the same time, an > actor's behavior may be different for different states. > message A message B > --------------> Actor A --------------------------> Actor B > Context Context [Actor A updated] > > 3. dynamical actor hierarchical structure > The actor hierarchical structure is flexible and can be dynamically > updated if needed. > > message A message B > --------------> Actor A ----------------------------> ... > (Context) | (Context [Actor A updated]) ^ > | | > | Add Actor C between A and B | > | [Optional] | > +----------------------------------+ > > > ... Message C > [ Actor C --------------------------> ] Actor B > (Context [Actor B updated] > > 4. consumer and producer > The consumer/producer pattern is used to consume input messages, and > produce output messages. > > message A message B > ------------> Consumer A Producer B -------------------> > (Context) | ^ (Context [Consumer A updated]) > | | > | Add Producer B | > +------------------+ > > > message A > Producer A -----------------------> Consumer A --------------------> > | (Context) ^ (Context [Producer A updated]) > | | > | Add consumer B | > +-------------------------------+ > > In this implementation, I removed: > 1. the extended master secret extension > I will add it back soon. > > 2. the KRB5 cipher suite implementation. > I'm not very sure KRB5 cipher suites are still used in practice. > Please let me know if you still using KRB5 cipher suite. I may not > add these cipher suite back unless it is necessary. > > 3. OCSP stapling > This feature will be added back later. > > As this re-org is for TLS 1.3, so it contains a few draft skeleton for > TLS 1.3. I will file these parts when doing the TLS 1.3 implementation. > > Please don't be hesitate if you have any questions. > > Regards, > Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Jan 4 00:48:11 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 4 Jan 2018 08:48:11 +0800 Subject: RFR 8191438: jarsigner should print when a timestamp will expire Message-ID: <64196240-CBBA-4A85-9A1C-BE60B2BB38B1@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8191438/webrev.04/ Major changes: 1. Warnings on TSA cert chain: expired or expiring 2. No more check on trusted certs 3. More output at signing when -verbose is on 4. Fine tune messages when TSA cert expires earlier than signer cert 5. New test cases 6. Existing tests modification so signer is not trusted Thanks Max From sha.jiang at oracle.com Thu Jan 4 07:44:28 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Thu, 4 Jan 2018 15:44:28 +0800 Subject: RFR JDK-8189760: sun/security/ssl/CertPathRestrictions/TLSRestrictions.java failed with unexpected Exception intermittently Message-ID: Hi, The server side exception is used to determine the test result status for some cases, but because of concurrency issue, the exception possibly is not available. This patch is expected to fix this issue. Webrev: http://cr.openjdk.java.net/~jjiang/8189760/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8189760 Best regards, John Jiang From tobias.wagner at n-design.de Thu Jan 4 12:42:52 2018 From: tobias.wagner at n-design.de (=?utf-8?Q?Tobias_Wagner?=) Date: Thu, 4 Jan 2018 13:42:52 +0100 Subject: [PATCH]: Support for brainpool curves from CurveDB in SunEC Message-ID: Hi and a happy new year, I did some further work reagarding the brainpool curves. For the points about the removal of the small curves and the challenges with that, please see below. Regarding the test vectors for the brainpool curves, I'm planning to add a new jtreg test to sun.security.ec which is simliar to the sun.security.pkcs11.ec.TestECDH test, but uses the testdata from RFC 7027. Adding these data to the latter test seems not to be right, as it is designed to work with arbitrary providers and would possibly fail with them. A further point about the jtreg tests is, that I have trouble executing sun.security.ec.TestEC. Regardless of whether I run it with a patched or unpatched JVM. It has two @run tags: * @run main/othervm -Djdk.tls.namedGroups="secp256r1,sect193r1" TestEC * @run main/othervm/java.security.policy=TestEC.policy -Djdk.tls.namedGroups="secp256r1,sect193r1" TestEC While the first run finishes with all tests passed, the second one fails immediately as no "SunEC" provider is available. The second tag looks somewhat malformed to me. It looks a little bit that way, as it is meant to run the tests under an explicit security policy. If so, I would expect it to look like that: * @run main/othervm -Djava.security.policy=TestEC.policy -Djdk.tls.namedGroups="secp256r1,sect193r1" TestEC Changing it that way, all tests are executed and pass in the second run. Regards Tobias > >> Von:Adam Petcher > >> Gesendet: Fre 15 Dezember 2017 20:57 > >> An: security-dev at openjdk.java.net > >> Betreff: Re: [PATCH]: Support for brainpool curves from CurveDB in SunEC > >> 4) How important are the 224-bit and smaller curves? We can't use them > >> in TLS, and I don't think we should add curves that are already obsolete > > > > If they should not be added, I see two options: > > > > * remove them from CurveDB as well, so they can't be addressed anymore. > > > > or > > > > * There should be a more explicit check than the length of the oid's DER encoding to decide wether the curve is supported or not. > > > > I am not sure, what option should be taken in that case. As far as I understand, the first one might affect other providers, which could not > > support these curves anymore as well. > > Right. Removing them from CurveDB isn't a good option because of the > compatibility impact. Also note that CurveDB is allowed to vary > independently of the native implementation. So we always have to handle > the case that curves exist in CurveDB, but are not supported in the > native code. For example, someone could add the twisted Brainpool curves > to CurveDB in the future. > > I think the explicit check that you need is already there in the code > you added to SECOID_FindOID. You just need to replace the elements in > SECOidData BRAINPOOL_oids that you don't want to support with the > "Unknown OID" block element that you are using for the twisted curves. > Of course, there are probably other ways to do this check, but this > seems to be the pattern that exists in the code already. > > I'm not completely opposed to adding these small curves, but I don't > think we should do it unless there is a compelling reason. So if anyone > in the community has a need for these curves (or other thoughts on this > issue), please let us know. > I found out that the "Unknow OID" blocks are the troublemakers in that case: This structure contains a SECItem with a field "unsigned char *data" set to NULL. In the last step of determining whether the requested OID matches the found structure, memcmp from string.h is used to check equality. Unfortunately, memcmp is not meant to be used with null-pointers and therefore the JVM dies in an infamous Segmentation Fault. To cope with that, I introduced a "oideql" function: BOOL oideql(unsigned char *reqoid, unsigned char *foundoid, size_t len) { ??? if(!reqoid || !foundoid) { ??????? return FALSE; ??? } ??? return memcmp(reqoid, foundoid, len) == 0; } In my patch, this function is used in SECOID_FindOID instead of using the direct call of memcmp. The patch it self is not yet attached, as it is a bit clumsy from trying different ways and figuring out solutions - and of course the testvectors are still missing. From jkalina at redhat.com Thu Jan 4 12:51:06 2018 From: jkalina at redhat.com (Jan Kalina) Date: Thu, 4 Jan 2018 13:51:06 +0100 Subject: Bug in SunNativeProvider In-Reply-To: References: Message-ID: Described issues was accepted into Oracle JDK issues: 1) SunNativeProvider.INSTANCE initialization: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8194073 2) Uninitialized cb->initiator_address: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8194630 (fixing patches are included in reports too) On Fri, Dec 22, 2017 at 5:44 PM, Jan Kalina wrote: > Hi, I was just able to prepare usable reproducer (attaching in ZIP file) > and fixing patch of JDK (attaching too). > Before I was able to make my usecase working, I has found second issue too > - I has included it too. > > Issues and their reproducing: > > 1) already described problem of wrong initialized > SunNativeProvider.INSTANCE > > This can be reproduced by recreating GSSManager before createGSSContext - > ProviderList.factories > will be initialized as part of initSecContext/acceptSecContext which will > cause using wrong initialized > SunNativeProvider.INSTANCE and described exception. > > 2) when channel binding is used SIGSEGV occure > > This can be reproduced by setting channel binding without > initAddr/acceptAddr. > This is caused by sending uninitialized (with random length) > cb->initiator_address from JDK to the kerberos. > (It is used by krb library for messages checksum calculation even when > addrtype is GSS_C_AF_NULLADDR.) > > Attached reproducer-gss.zip reproduces both issues and attached patch > fixes both. > > I would welcome merging into OpenJDK. (I am covered by OCA of Red Hat) > > This issue affect both tested JDKs, JKD8u121 and upstream JDK9 from > mercurial master. > > Thanks, > Jan > > On Wed, Dec 20, 2017 at 1:42 AM, Valerie Peng > wrote: > >> >> I will take a look. Do you happen to have a test case that I can >> reproduce the issue? >> Thanks, >> Valerie >> >> >> On 12/14/2017 9:20 AM, Jan Kalina wrote: >> >> Attaching patch, which fixes described issue for me. >> >> On Thu, Dec 14, 2017 at 4:03 PM, Jan Kalina wrote: >> >>> I has found bug in SunNativeProvider: >>> >>> When debug messages are enabled, JDK confirms GSS library was loaded >>> with mechs: >>> >>> [GSSLibStub_init] libName=/usr/lib64/libgssapi_krb5.so.2.2 >>> SunNativeGSS: Loaded GSS library: /usr/lib64/libgssapi_krb5.so.2.2 >>> SunNativeGSS: Native MF for 1.2.840.113554.1.2.2 >>> SunNativeGSS: Native MF for 1.3.6.1.5.2.5 >>> SunNativeGSS: Native MF for 1.3.6.1.5.5.2 >>> >>> But when I try to use it, it claims mechanism with given OID are not >>> supported: >>> >>> GSSException: Provider SunNativeGSS does not support mechanism >>> 1.2.840.113554.1.2.2 >>> at java.security.jgss/sun.security.jgss.ProviderList.getMechFac >>> tory(ProviderList.java:253) >>> at java.security.jgss/sun.security.jgss.ProviderList.getMechFac >>> tory(ProviderList.java:209) >>> at java.security.jgss/sun.security.jgss.GSSManagerImpl.getMecha >>> nismContext(GSSManagerImpl.java:234) >>> at java.security.jgss/sun.security.jgss.GSSContextImpl.acceptSe >>> cContext(GSSContextImpl.java:337) >>> at java.security.jgss/sun.security.jgss.GSSContextImpl.acceptSe >>> cContext(GSSContextImpl.java:302) >>> >>> *When I has try to debug it, I has found the SunNativeProvider is >>> created in two instances:* >>> >>> First instance is created on initialization of >>> SunNativeProvider.INSTANCE, but it is BEFORE >>> the mechs are passed into SunNativeProvider.MECH_MAP. The second >>> instance is created >>> correctly in ProviderList constructor. >>> >>> The problem is, in some situations is used the too soon created >>> SunNativeProvider.INSTANCE, >>> so the to call throws exception above. >>> >>> *I think sufficient fix would be to move SunNativeProvider.INSTANCE >>> declaration after* >>> *the static constructor (filling the **MECH_MAP) in SunNativeProvider >>> file.* >>> >>> Would be possible to fix this? >>> Should I send a patch? >>> >>> Thanks >>> Jan Kalina >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Thu Jan 4 15:48:10 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 4 Jan 2018 07:48:10 -0800 Subject: RFR JDK-8189760: sun/security/ssl/CertPathRestrictions/TLSRestrictions.java failed with unexpected Exception intermittently In-Reply-To: References: Message-ID: <0c92f93c-e043-bd86-c827-82e07c1fe4ed@oracle.com> Looks fine to me. Thanks, Xuelei On 1/3/2018 11:44 PM, sha.jiang at oracle.com wrote: > Hi, > The server side exception is used to determine the test result status > for some cases, > but because of concurrency issue, the exception possibly is not available. > This patch is expected to fix this issue. > > Webrev: http://cr.openjdk.java.net/~jjiang/8189760/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8189760 > > Best regards, > John Jiang > From adam.petcher at oracle.com Thu Jan 4 17:12:38 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 4 Jan 2018 12:12:38 -0500 Subject: [PATCH]: Support for brainpool curves from CurveDB in SunEC In-Reply-To: References: Message-ID: On 1/4/2018 7:42 AM, Tobias Wagner wrote: > Hi and a happy new year, > > I did some further work reagarding the brainpool curves. > > For the points about the removal of the small curves and the challenges with that, please see below. > > Regarding the test vectors for the brainpool curves, I'm planning to add a new jtreg test to > sun.security.ec which is simliar to the sun.security.pkcs11.ec.TestECDH test, but uses the testdata > from RFC 7027. Adding these data to the latter test seems not to be right, as it is designed to > work with arbitrary providers and would possibly fail with them. Making a separate test for brainpool vectors is probably good idea, but I suggest that this new test should loop through all the providers and simply skip the test when the curve is not supported and the provider is not "SunEC". You could also modify the existing TestECDH to skip tests in this way, but making a separate test is probably simple and cleaner. > > A further point about the jtreg tests is, that I have trouble executing sun.security.ec.TestEC. > Regardless of whether I run it with a patched or unpatched JVM. It has two @run tags: > > * @run main/othervm -Djdk.tls.namedGroups="secp256r1,sect193r1" TestEC > * @run main/othervm/java.security.policy=TestEC.policy -Djdk.tls.namedGroups="secp256r1,sect193r1" TestEC > > While the first run finishes with all tests passed, the second one fails immediately as no "SunEC" provider is available. > The second tag looks somewhat malformed to me. It looks a little bit that way, as it is meant to run the tests under an > explicit security policy. If so, I would expect it to look like that: > > * @run main/othervm -Djava.security.policy=TestEC.policy -Djdk.tls.namedGroups="secp256r1,sect193r1" TestEC > > Changing it that way, all tests are executed and pass in the second run. This has to do with the way jtreg handles paths, and the solution is to run jtreg on an images build. To create an images build, simply "make images". Then, when you run jtreg, you do "jtreg -jdk:build//images/jdk ". > I found out that the "Unknow OID" blocks are the troublemakers in that case: This structure > contains a SECItem with a field "unsigned char *data" set to NULL. In the last step of > determining whether the requested OID matches the found structure, memcmp from string.h is used to check > equality. Unfortunately, memcmp is not meant to be used with null-pointers and therefore the JVM dies in > an infamous Segmentation Fault. > > To cope with that, I introduced a "oideql" function: > > BOOL oideql(unsigned char *reqoid, unsigned char *foundoid, size_t len) { > ??? if(!reqoid || !foundoid) { > ??????? return FALSE; > ??? } > ??? return memcmp(reqoid, foundoid, len) == 0; } > > In my patch, this function is used in SECOID_FindOID instead of using the direct call of memcmp. Now I'm wondering why the same problem hasn't come up in the existing curves. It's likely that the execution doesn't get this far (e.g. the curves that are not in the array in oid.c are also not in CurveDB). Regardless, making this function more robust is a good idea, so you should consider replacing the other memcmp calls in this function with the oideql function. While you are at it, you can solve the other problem with using memcmp here, which is that it can read out of bounds. To fix this problem, you can (for example) have oideql take both lengths and return false when they are not equal. > The patch it self is not yet attached, as it is a bit clumsy from trying different ways and figuring out solutions > - and of course the testvectors are still missing. From xuelei.fan at oracle.com Thu Jan 4 20:03:49 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 4 Jan 2018 12:03:49 -0800 Subject: Code Review Request, JDK-8185576 : New handshake implementation In-Reply-To: References: Message-ID: Nice catches! The updated will present in the next webrev. For the comment out ClientKeyExchangeService blocks, they're placeholder for KRB5 cipher suites. If no objections to remove KRB5 cipher suites, I will clear up these blocks in a future webrev. Thanks, Xuelei On 1/3/2018 4:04 PM, Jamil Nimeh wrote: > Hi Xuelei, I'm only part way through this but I wanted to give you what > I had so far.? I'm working on the new files now so hopefully I'll have > the rest of them done tomorrow. > > > * CipherBox.java > o 146: Were you intending to leave that commented protocol version > line in there in the short term?? If not then maybe remove it. > * DTLSInputRecord.java > o 130: Remove @Override comment, doesn't look like you need it. > * DTLSOutpuTRecord.java > o 58: Remove comment line for this.protocolVersion > * HandshakeHash.java > o 44: Nit: trhe -> the > o 83-87: Do you need to do Arrays.copyOf() on holder?? It seems > like you could just add holder directly to the reserves list > rather than duplicate it. > o 509 and others: Nit: ClonableHash -> CloneableHash > o 537 and others: Nit: NoneClonableHash -> NonCloneableHash > * JsseJce.java > o 55-61: Does the static initializer for the > ClientKeyExchangeService still need to be there?? It's commented > out right now. > * MAC.java > o 190: Typo in comment "the the" > * ProtocolVersion > o 167: I don't think you need to mask with "& 0xFF" since you're > doing a primitive narrowing conversion to byte from int.? That > already lops off the upper 24 bits.? But it's fine if you wish > to keep it, too. > o 254: In order to be consistent with the unmodifiable empty list > return on 257 consider doing "return > Collections.unmodifiableList(pvs)" here.? If you're expecting to > make changes to the list if it is non-empty, then disregard this > comment. > o 267: Nit: "pv .id" (note the extra space).? Not sure if that's > webrev rendering or you really have that extra space in there. > o 267: For the first clause in the ternary expression (DTLS) > shouldn't the comparison be <= instead of >=? > * SSLAlgorithmDecomposer.java > o 132-138: Do you still want to hang onto this commented-out block > of code? > * SSLContextImpl.java > o 889 & 896: Will these commented-out lines be temporary and be > uncommented once the 1.3 handshake is done? > * SSLEngineInputRecord.java > o 287: Would this be a good place to use Record.getInt24()? > o 319: This is just a nit, you don't need to do it, but it would > look a bit cleaner to do > ByteBuffer.allocate(handshakeBuffer.remaining() + > fragment.remaining()).? You'll still have a backing array > according to the docs. > o 338: Another spot for Record.getInt24() maybe. > * SSLSessionImpl.java > o 435 & 440, 492 & 497, and others: There are multiple places > where ClientKeyExchangeService.find() calls are commented out. > Similar to the other places where there are commented blocks, > are these needed for future integration with the 1.3 handshake code? > * SSLSocketInputRecord.java > o Similar to the comment on SSLEngineInputRecord.java:319: you > could do ByteBuffer.allocate() and bypass the explicit byte[] > constructor call. > o 333: Another spot you could use Record.getInt24(). > * SignatureAlgorithmsExtension.java > o 276: The hashAlgorithms array appears to be missing "sha384" at > index 5. > * SupportedGroupsExtension.java > o 309: Cut-n-paste bug: x448's ID should be 0x001E and the fourth > field should be "x448" > > --Jamil > > > On 12/15/2017 08:20 PM, Xuelei Fan wrote: >> Hi, >> >> Please review the change: >> http://cr.openjdk.java.net/~xuelei/8185576/webrev.00/ >> >> This fix is trying to re-org the TLS handshaking implementation in the >> SunJSSE provider. >> >> The handshaking process in TLS 1.3 is lot different from that of TLS >> 1.2.? For TLS 1.3 implementation, it is not straightforward any more >> to use the existing state machines for TLS 1.2.?? For example, in TLS >> specification, the handshake message must be delivered in strict >> order. The handshake message order in TLS 1.3 protocol is re-designed >> and significant different from that of TLS 1.2.? If we re-use the >> state machine for TLS 1.3 and 1.2 and previous versions, the state >> machine becomes very complicated and hard to maintain. >> >> We are consider to simplify the handshake implementation by: >> 1. Use difference handshake handler for different TLS versions. >> 2. Improved message driven handler for different handshake messages. >> >> The basic ideas for the simplification look like: >> 1. message/even driving handshake processing model. >> An actor is a stateless service that is used to consume an input >> message, or produce output message, or both. >> ?????? message A???????????? message B >> ???? --------------> Actor A ------------> Actor B >> >> 2. immutable actor and centralized states. >> Handshake states are represent in context objects (ConnectionContext), >> and the context object is passed to each actor.? An actor can update >> the state in the context object accordingly.? At the same time, an >> actor's behavior may be different for different states. >> ????? message A????????????????? message B >> ?? --------------> Actor A --------------------------> Actor B >> ????? Context?????????????? Context [Actor A updated] >> >> 3. dynamical actor hierarchical structure >> The actor hierarchical structure is flexible and can be dynamically >> updated if needed. >> >> ???? message A?????????????????? message B >> ?? --------------> Actor A ----------------------------> ... >> ?? (Context)?????? |??? (Context [Actor A updated])?? ^ >> ?????????????????? |????????????????????????????????? | >> ?????????????????? | Add Actor C between A and B????? | >> ?????????????????? | [Optional]?????????????????????? | >> ?????????????????? +----------------------------------+ >> >> ??? >> ??? ... ??????? Message C >> ??? [ Actor C --------------------------> ] Actor B >> ????????????? (Context [Actor B updated] >> >> 4. consumer and producer >> The consumer/producer pattern is used to consume input messages, and >> produce output messages. >> >> ??? message A??????????????????????????????? message B >> ? ------------> Consumer A??? Producer B -------------------> >> ?? (Context)??? |????????????????? ^? (Context [Consumer A updated]) >> ??????????????? |????????????????? | >> ??????????????? | Add Producer B?? | >> ??????????????? +------------------+ >> >> >> ????????????????? message A >> ? Producer A -----------------------> Consumer A --------------------> >> ????? |???????? (Context)???????????? ^? (Context [Producer A updated]) >> ????? |?????????????????????????????? | >> ????? | Add consumer B??????????????? | >> ????? +-------------------------------+ >> >> In this implementation, I removed: >> 1. the extended master secret extension >> I will add it back soon. >> >> 2. the KRB5 cipher suite implementation. >> I'm not very sure KRB5 cipher suites are still used in practice. >> Please let me know if you still using KRB5 cipher suite.? I may not >> add these cipher suite back unless it is necessary. >> >> 3. OCSP stapling >> This feature will be added back later. >> >> As this re-org is for TLS 1.3, so it contains a few draft skeleton for >> TLS 1.3.? I will file these parts when doing the TLS 1.3 implementation. >> >> Please don't be hesitate if you have any questions. >> >> Regards, >> Xuelei > From valerie.peng at oracle.com Thu Jan 4 23:07:50 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 4 Jan 2018 15:07:50 -0800 Subject: Bug in SunNativeProvider In-Reply-To: References: Message-ID: Great, thanks! Valerie On 1/4/2018 4:51 AM, Jan Kalina wrote: > Described issues was accepted into Oracle JDK issues: > > 1) SunNativeProvider.INSTANCE initialization: > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8194073 > 2) Uninitialized cb->initiator_address: > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8194630 > > (fixing patches are included in reports too) > > > On Fri, Dec 22, 2017 at 5:44 PM, Jan Kalina > wrote: > > Hi, I was just able to prepare usable reproducer (attaching in ZIP > file) and fixing patch of JDK (attaching too). > Before I was able to make my usecase working, I has found second > issue too - I has included it too. > > Issues and their reproducing: > > 1) already described problem of wrong initialized > SunNativeProvider.INSTANCE > > This can be reproduced by recreating GSSManager before > createGSSContext - ProviderList.factories > will be initialized as part of initSecContext/acceptSecContext > which will cause using wrong initialized > SunNativeProvider.INSTANCE and described exception. > > 2) when channel binding is used SIGSEGV occure > > This can be reproduced by setting channel binding without > initAddr/acceptAddr. > This is caused by sending uninitialized (with random length) > cb->initiator_address from JDK to the kerberos. > (It is used by krb library for messages checksum calculation even > when addrtype is GSS_C_AF_NULLADDR.) > > Attached reproducer-gss.zip reproduces both issues and attached > patch fixes both. > > I would welcome merging into OpenJDK. (I am covered by OCA of Red Hat) > > This issue affect both tested JDKs, JKD8u121 and upstream JDK9 > from mercurial master. > > Thanks, > Jan > > On Wed, Dec 20, 2017 at 1:42 AM, Valerie Peng > > wrote: > > > I will take a look. Do you happen to have a test case that I > can reproduce the issue? > Thanks, > Valerie > > > On 12/14/2017 9:20 AM, Jan Kalina wrote: >> Attaching patch, which fixes described issue for me. >> >> On Thu, Dec 14, 2017 at 4:03 PM, Jan Kalina >> > wrote: >> >> I has found bug in SunNativeProvider: >> >> When debug messages are enabled, JDK confirms GSS library >> was loaded with mechs: >> >> [GSSLibStub_init] libName=/usr/lib64/libgssapi_krb5.so.2.2 >> SunNativeGSS: Loaded GSS library: >> /usr/lib64/libgssapi_krb5.so.2.2 >> SunNativeGSS: Native MF for 1.2.840.113554.1.2.2 >> SunNativeGSS: Native MF for 1.3.6.1.5.2.5 >> SunNativeGSS: Native MF for 1.3.6.1.5.5.2 >> >> But when I try to use it, it claims mechanism with given >> OID are not supported: >> >> GSSException: Provider SunNativeGSS does not support >> mechanism 1.2.840.113554.1.2.2 >> ??? at >> java.security.jgss/sun.security.jgss.ProviderList.getMechFactory(ProviderList.java:253) >> ??? at >> java.security.jgss/sun.security.jgss.ProviderList.getMechFactory(ProviderList.java:209) >> ??? at >> java.security.jgss/sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:234) >> ??? at >> java.security.jgss/sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:337) >> ??? at >> java.security.jgss/sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:302) >> >> *When I has try to debug it, I has found the >> SunNativeProvider is created in two instances:* >> >> First instance is created on initialization of >> SunNativeProvider.INSTANCE, but it is BEFORE >> the mechs are passed into SunNativeProvider.MECH_MAP. The >> second instance is created >> correctly in ProviderList constructor. >> >> The problem is, in some situations is used the too soon >> created SunNativeProvider.INSTANCE, >> so the to call throws exception above. >> >> *I think sufficient fix would be to move >> SunNativeProvider.INSTANCE declaration after* >> *the static constructor (filling the **MECH_MAP) in >> SunNativeProvider file.* >> >> Would be possible to fix this? >> Should I send a patch? >> >> Thanks >> Jan Kalina >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy.lu at oracle.com Fri Jan 5 03:55:52 2018 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 5 Jan 2018 11:55:52 +0800 Subject: [10] RFR 8194666: ProblemList update for bugid associated with PreferredKey.java, ConcurrentHashMapTest and SSLSocketParametersTest.sh Message-ID: <1c6a6aa2-e632-1749-ffb3-c2bc1bd5d98d@oracle.com> Please review this minor cleanup for test/jdk/ProblemList.txt on bugid that associated with tests. bug: https://bugs.openjdk.java.net/browse/JDK-8194666 webrev: http://cr.openjdk.java.net/~amlu/8194666/webrev.00/ Thanks, Amy --- old/test/jdk/ProblemList.txt 2018-01-05 11:41:00.000000000 +0800 +++ new/test/jdk/ProblemList.txt 2018-01-05 11:41:00.000000000 +0800 @@ -264,7 +264,7 @@ sun/security/krb5/auto/UnboundSSL.java 8180265 windows-all sun/security/provider/KeyStore/DKSTest.sh 8180266 windows-all -sun/security/ssl/X509KeyManager/PreferredKey.java 8176354 generic-all +sun/security/ssl/X509KeyManager/PreferredKey.java 8190333 generic-all ############################################################################ @@ -363,12 +363,12 @@ com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8169942 linux-i586,macosx-all,windows-x64 -javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java 8169737 generic-all +javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java 8194663 generic-all -org/omg/CORBA/OrbPropertiesTest.java 8175177 generic-all +org/omg/CORBA/OrbPropertiesTest.java 8194663 generic-all -javax/rmi/PortableRemoteObject/ConcurrentHashMapTest.java 8080643 generic-all +javax/rmi/PortableRemoteObject/ConcurrentHashMapTest.java 8194663 generic-all -javax/rmi/ssl/SSLSocketParametersTest.sh 8162906 generic-all +javax/rmi/ssl/SSLSocketParametersTest.sh 8194663 generic-all ############################################################################ -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Fri Jan 5 04:20:36 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 4 Jan 2018 20:20:36 -0800 Subject: [10] RFR 8194666: ProblemList update for bugid associated with PreferredKey.java, ConcurrentHashMapTest and SSLSocketParametersTest.sh In-Reply-To: <1c6a6aa2-e632-1749-ffb3-c2bc1bd5d98d@oracle.com> References: <1c6a6aa2-e632-1749-ffb3-c2bc1bd5d98d@oracle.com> Message-ID: I'm not very sure of the fix problems of JDK-8176354. But this changeset Looks fine to me. Thanks, Xuelei On 1/4/2018 7:55 PM, Amy Lu wrote: > Please review this minor cleanup for test/jdk/ProblemList.txt on bugid > that associated with tests. > > bug: https://bugs.openjdk.java.net/browse/JDK-8194666 > webrev: http://cr.openjdk.java.net/~amlu/8194666/webrev.00/ > > Thanks, > Amy > > --- old/test/jdk/ProblemList.txt 2018-01-05 11:41:00.000000000 +0800 > +++ new/test/jdk/ProblemList.txt 2018-01-05 11:41:00.000000000 +0800 > @@ -264,7 +264,7 @@ > > sun/security/krb5/auto/UnboundSSL.java 8180265 windows-all > sun/security/provider/KeyStore/DKSTest.sh 8180266 windows-all > -sun/security/ssl/X509KeyManager/PreferredKey.java 8176354 generic-all > +sun/security/ssl/X509KeyManager/PreferredKey.java 8190333 generic-all > > ############################################################################ > > @@ -363,12 +363,12 @@ > > com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8169942 linux-i586,macosx-all,windows-x64 > > -javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java 8169737 generic-all > +javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java 8194663 generic-all > > -org/omg/CORBA/OrbPropertiesTest.java 8175177 generic-all > +org/omg/CORBA/OrbPropertiesTest.java 8194663 generic-all > > -javax/rmi/PortableRemoteObject/ConcurrentHashMapTest.java 8080643 generic-all > +javax/rmi/PortableRemoteObject/ConcurrentHashMapTest.java 8194663 generic-all > > -javax/rmi/ssl/SSLSocketParametersTest.sh 8162906 generic-all > +javax/rmi/ssl/SSLSocketParametersTest.sh 8194663 generic-all > > ############################################################################ > From devnexen at gmail.com Mon Jan 8 15:13:29 2018 From: devnexen at gmail.com (David CARLIER) Date: Mon, 8 Jan 2018 15:13:29 +0000 Subject: [PATCH] Crypto EC - avoids possible memset compiler optimisation Message-ID: Hi, Here a little patch proposal which is usually relevant in cryptographics matters. Usually memset/bzero/... is used to clear private structures but the compiler can possibly optimize those calls but with this change we can unsure sensitive data is properly zero'ed using if possible native calls or memory fence. Kind regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- diff --git a/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c b/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c --- a/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c +++ b/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c @@ -59,11 +59,7 @@ #ifdef _KERNEL #define PORT_ZFree(p, l) bzero((p), (l)); kmem_free((p), (l)) #else -#ifndef _WIN32 -#define PORT_ZFree(p, l) bzero((p), (l)); free((p)) -#else -#define PORT_ZFree(p, l) memset((p), 0, (l)); free((p)) -#endif /* _WIN32 */ +#define PORT_ZFree(p, l) mp_safe_memzero((p), (l)); free((p)) #endif /* @@ -323,7 +319,7 @@ if (privKeyLen >= len) { memcpy(key->privateValue.data, privKeyBytes, len); } else { - memset(key->privateValue.data, 0, (len - privKeyLen)); + mp_safe_memzero(key->privateValue.data, (len - privKeyLen)); memcpy(key->privateValue.data + (len - privKeyLen), privKeyBytes, privKeyLen); } @@ -415,7 +411,7 @@ CHECK_MPI_OK( mp_mod(&privKeyVal, &order_1, &privKeyVal) ); CHECK_MPI_OK( mp_add(&privKeyVal, &one, &privKeyVal) ); CHECK_MPI_OK( mp_to_fixlen_octets(&privKeyVal, privKeyBytes, len) ); - memset(privKeyBytes+len, 0, len); + mp_safe_memzero(privKeyBytes+len, len); cleanup: mp_clear(&privKeyVal); mp_clear(&order_1); @@ -592,7 +588,7 @@ return SECFailure; } - memset(derivedSecret, 0, sizeof *derivedSecret); + mp_safe_memzero(derivedSecret, sizeof *derivedSecret); len = (ecParams->fieldID.size + 7) >> 3; pointQ.len = 2*len + 1; if ((pointQ.data = PORT_Alloc(2*len + 1, kmflag)) == NULL) goto cleanup; diff --git a/src/jdk.crypto.ec/share/native/libsunec/impl/mpi.c b/src/jdk.crypto.ec/share/native/libsunec/impl/mpi.c --- a/src/jdk.crypto.ec/share/native/libsunec/impl/mpi.c +++ b/src/jdk.crypto.ec/share/native/libsunec/impl/mpi.c @@ -2077,6 +2077,20 @@ return n; } +void mp_safe_memzero(void *a, mp_size len) +{ +#if defined(_WIN32) + SecureZeroMemory(a, len); +#elif defined(__FreeBSD__) || defined(__OpenBSD__) + explicit_bzero(a, len); +#elif defined(__NetBSD__) + explicit_memset(a, 0, len); +#else + memset(a, 0, len); + __asm__ volatile("" :: "r"(a) : "memory"); +#endif +} + /* Given a and prime p, computes c and k such that a*c == 2**k (mod p). ** Returns k (positive) or error (negative). ** This technique from the paper "Fast Modular Reciprocals" (unpublished) diff --git a/src/jdk.crypto.ec/share/native/libsunec/impl/mpi.h b/src/jdk.crypto.ec/share/native/libsunec/impl/mpi.h --- a/src/jdk.crypto.ec/share/native/libsunec/impl/mpi.h +++ b/src/jdk.crypto.ec/share/native/libsunec/impl/mpi.h @@ -351,6 +351,7 @@ /* Miscellaneous */ mp_size mp_trailing_zeros(const mp_int *mp); +void mp_safe_memzero(void *, mp_size); #define MP_CHECKOK(x) if (MP_OKAY > (res = (x))) goto CLEANUP #define MP_CHECKERR(x) if (MP_OKAY > (res = (x))) goto CLEANUP From adam.petcher at oracle.com Mon Jan 8 16:30:31 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 8 Jan 2018 11:30:31 -0500 Subject: [PATCH] Crypto EC - avoids possible memset compiler optimisation In-Reply-To: References: Message-ID: <09e008d7-a38b-bd29-19af-1ca7f5d516b7@oracle.com> On 1/8/2018 10:13 AM, David CARLIER wrote: > Hi, > > Here a little patch proposal which is usually relevant in > cryptographics matters. Usually memset/bzero/... is used to clear > private structures but the compiler can possibly optimize those calls > but with this change we can unsure sensitive data is properly zero'ed > using if possible native calls or memory fence. SunEC doesn't really make an effort to zeroize sensitive data, and all of the memset operations except for one (line 418) operate on memory that is not sensitive. While the patch is a relatively simple change that probably doesn't hurt anything, it doesn't seem to me like this improvement is particularly valuable. Perhaps it would be more valuable along with a larger improvement to make SunEC zeroize all intermediate values. Though this would be a much larger undertaking, and it still may not be useful on its own because the Java code in the provider also holds some sensitive values. > > Kind regards. From sha.jiang at oracle.com Tue Jan 9 03:02:27 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Tue, 9 Jan 2018 11:02:27 +0800 Subject: RFR JDK-8194257: javax/net/ssl/compatibility/Compatibility.java should be updated for JDK 6 after JDK-8174748 Message-ID: <1bee5fd7-efee-62c4-05a2-8345ebc99bf1@oracle.com> Hi, After JDK-8174748, the AES_256 cipher suites are enabled by default for JDK 6, so this test has to mark those cipher suites are supported by JDK 6. In addition, some AES_128 cipher suites also should be marked as JDK 6 supported. For more details, please look through the comments for JDK-8194257. Webrev: http://cr.openjdk.java.net/~jjiang/8194257/webrev.01/ Issue: https://bugs.openjdk.java.net/browse/JDK-8194257 Best regards, John Jiang From xuelei.fan at oracle.com Tue Jan 9 12:58:31 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 9 Jan 2018 04:58:31 -0800 Subject: RFR JDK-8194257: javax/net/ssl/compatibility/Compatibility.java should be updated for JDK 6 after JDK-8174748 In-Reply-To: <1bee5fd7-efee-62c4-05a2-8345ebc99bf1@oracle.com> References: <1bee5fd7-efee-62c4-05a2-8345ebc99bf1@oracle.com> Message-ID: Looks fine to me. Thanks, Xuelei On 1/8/2018 7:02 PM, sha.jiang at oracle.com wrote: > Hi, > After JDK-8174748, the AES_256 cipher suites are enabled by default for > JDK 6, so this test has to mark those cipher suites are supported by JDK 6. > In addition, some AES_128 cipher suites also should be marked as JDK 6 > supported. > For more details, please look through the comments for JDK-8194257. > > Webrev: http://cr.openjdk.java.net/~jjiang/8194257/webrev.01/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8194257 > > Best regards, > John Jiang > From sean.mullan at oracle.com Tue Jan 9 16:22:18 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 9 Jan 2018 11:22:18 -0500 Subject: RFR 8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5 In-Reply-To: References: <598A4449-E91D-4B13-A4F0-B2313BE36A8B@oracle.com> <226355E4-F0B1-45CB-95C5-E86E93BCC112@oracle.com> <99efce43-6df7-41e9-1de6-9f71a6d5c4da@oracle.com> <80B2118E-D9F3-47B6-B3E8-19AAD3EE5289@oracle.com> Message-ID: On 12/19/17 8:39 PM, Weijun Wang wrote: > > >> On Dec 20, 2017, at 5:02 AM, Sean Mullan wrote: >> >> On 12/19/17 10:52 AM, Weijun Wang wrote: >>>> * AesSha2DkCrypto.java >>>> >>>> - why does stringToKey(char[] password, String salt, byte[] s2kparams) swallow exceptions but stringToKey(char[] secret, byte[] salt, byte[] params) does not? >>> I simply copy the behavior of the same methods for other etypes. Looks like the later is always private and called by the former. The former is called by EncryptionKey::acquireSecretKey and this method was designed to accept a null value instead of handle an exception. >> >> Ok, I suggest logging the exception if debug is enabled. > > The debug flag inside AesDkCrypto and AesSha2DkCrypto are hardcoded to false and not customizable by any system property (and turning it on shows a lot of sensitive things). I can reuse the Krb5.DEBUG flag (controlled by -Dsun.security.krb5.debug=true) but it has never been used inside this level. > > Also, the only reason for exception I can see is that a user managed to pack a non-positive iteration count into the s2kparams. This should be quite rare. Is that a programming error or something that could be from data sent over the network? If only the former, I would say that those exceptions should not be suppressed. The code can also throw GeneralSecurityException but those are also always suppressed because of the catch block. Is that the right behavior? --Sean From weijun.wang at oracle.com Wed Jan 10 01:40:18 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 10 Jan 2018 09:40:18 +0800 Subject: RFR 8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5 In-Reply-To: References: <598A4449-E91D-4B13-A4F0-B2313BE36A8B@oracle.com> <226355E4-F0B1-45CB-95C5-E86E93BCC112@oracle.com> <99efce43-6df7-41e9-1de6-9f71a6d5c4da@oracle.com> <80B2118E-D9F3-47B6-B3E8-19AAD3EE5289@oracle.com> Message-ID: <1EDCCE6B-6A53-4893-BADB-1B725BACC75E@oracle.com> > On Jan 10, 2018, at 12:22 AM, Sean Mullan wrote: > > On 12/19/17 8:39 PM, Weijun Wang wrote: >>> On Dec 20, 2017, at 5:02 AM, Sean Mullan wrote: >>> >>> On 12/19/17 10:52 AM, Weijun Wang wrote: >>>>> * AesSha2DkCrypto.java >>>>> >>>>> - why does stringToKey(char[] password, String salt, byte[] s2kparams) swallow exceptions but stringToKey(char[] secret, byte[] salt, byte[] params) does not? >>>> I simply copy the behavior of the same methods for other etypes. Looks like the later is always private and called by the former. The former is called by EncryptionKey::acquireSecretKey and this method was designed to accept a null value instead of handle an exception. >>> >>> Ok, I suggest logging the exception if debug is enabled. >> The debug flag inside AesDkCrypto and AesSha2DkCrypto are hardcoded to false and not customizable by any system property (and turning it on shows a lot of sensitive things). I can reuse the Krb5.DEBUG flag (controlled by -Dsun.security.krb5.debug=true) but it has never been used inside this level. >> Also, the only reason for exception I can see is that a user managed to pack a non-positive iteration count into the s2kparams. This should be quite rare. > > Is that a programming error or something that could be from data sent over the network? If only the former, I would say that those exceptions should not be suppressed. It could be from data sent over the network, this method is called by the client when user uses a username/password pair to login to a KDC. The KDC's response contains the s2kparams value (https://tools.ietf.org/html/rfc4120#section-5.2.7.5) to instruct the user how to generate a key from its password. > > The code can also throw GeneralSecurityException but those are also always suppressed because of the catch block. Is that the right behavior? > Not a right behavior but should be harmless here. In my understanding, in the case of PBE, as long the passphrase, salt, iteration count etc are legal, there will be no further problem in generating a key, choosing a cipher, and do the encryption work, unless there is a programming error. I think the original designer (of other etypes) meant to let stringToKey(char,String,byte[]) returning a null when there is an error, and all callers of this method will deal with null instead of an exception. If not programmed carefully, this might turn a GeneralSecurityException to a NullPointerException. --Max > --Sean From sha.jiang at oracle.com Wed Jan 10 08:28:11 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 10 Jan 2018 16:28:11 +0800 Subject: RFR JDK-8194864: Outputs more details for PKCS11 tests if the NSS lib version cannot be determined Message-ID: <237b5f00-2ece-834b-390f-91f6d66ae360@oracle.com> Hi, JDK-8186098 is raised due to the NSS lib version cannot be determined from the lib content. When this issue occurs, it would be better to output the parsed content for further investigation. Webrev: http://cr.openjdk.java.net/~jjiang/8194864/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8194864 Best regards, John Jiang From sibabrata.sahoo at oracle.com Wed Jan 10 12:58:33 2018 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Wed, 10 Jan 2018 04:58:33 -0800 (PST) Subject: [11] RFR: 8194486: Several krb5 tests failed in Mac. Message-ID: Hi, Please review the change for the following patch, JBS: https://bugs.openjdk.java.net/browse/JDK-8194486 Webrev: http://cr.openjdk.java.net/~ssahoo/8194486/webrev.00/ Description: There are several failure occurred recently because the name service used by these Tests were not determinable. This patch fixes those issues. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Jan 10 15:37:09 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 10 Jan 2018 23:37:09 +0800 Subject: [11] RFR: 8194486: Several krb5 tests failed in Mac. In-Reply-To: References: Message-ID: <1C6FF3C7-7B21-4EC1-AAA1-90735498DB68@oracle.com> Code change looks fine. I think you can safely remove the lines commented out. If you meant to keep the history, the Mercurial repo already had it. Thanks Max > On Jan 10, 2018, at 8:58 PM, Sibabrata Sahoo wrote: > > Hi, > > Please review the change for the following patch, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8194486 > Webrev: http://cr.openjdk.java.net/~ssahoo/8194486/webrev.00/ > > Description: > There are several failure occurred recently because the name service used by these Tests were not determinable. This patch fixes those issues. > > > Thanks, > Siba From jamil.j.nimeh at oracle.com Wed Jan 10 17:13:52 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 10 Jan 2018 09:13:52 -0800 Subject: Code Review Request, JDK-8185576 : New handshake implementation In-Reply-To: References: Message-ID: Hello Xuelei, Here are a few more comments from some of the new files, maybe one or two existing ones that I missed the first time around.? I still need to do the final two big ones (SSLSocketImpl and SSLEngineImpl), but I think I've gone through every other file in the webrev at this point.? Like before, it's mostly small stuff. * Utilities.java o 143 & 147: Is the name of the method supposed to be "intent" or "indent"?? If the latter then maybe correct the method name?? If not, it seems like an odd name to give to a method that breaks up multi-line strings and adds a prefix to each line after the first.? Also you'll have both a class variable and method named "indent" so maybe one of them changes?? But that's only if the method is really "indent". * CertStatusExtension.java o 765: For the empty status_request_v2, I would suggest a two-entry extension_data containing both OCSP_MULTI and OCSP types.? That's what the current code does at least.? The extData would be { 0x00, 0x0e, 0x02, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00 }. o 907 onward: I think the StatusResponseManager class in the CertStatusExtension.java file should have its own file as it was originally.? The SRM is really a functional unit of its own.? It is instantiated and managed by SSLContext and the output it provides is more for the CertificateStatus message or the Certificate message in TLS 1.3.? While it is related to the status_request[_v2] extensions, it doesn't have a direct hand in encoding and decoding them. * ClientHandshakeContext.java o 89: Similar to the explanation for the reserved server cert chain, should there be a comment explaining deferred certs? If you think it prudent, I would suggest, "Hang onto the peer certificate chain until after the CertificateStatus message is received and processed." * ClientHello.java o 1155-1158: Masking with 0xFF is not necessary for these primitive narrowing conversions. * ContentType.java o 40: After APPLICATION_DATA should we add an entry for HEARTBEAT (24), just for completeness?? We don't support heartbeat, but it might allow us to log the record type by name if we were to receive one rather than call it "unknown". * KeyUpdate.java o I know this doesn't cover the guts of the 1.3 handshake yet, just a note that you'll probably want an enum for KeyUpdateRequest, similar to what you've done for other constant/enumerated values elsewhere in the code. * RSAServerKeyExchange.java o 301: Comment nit: Should be RSA public key, not EC. * SSLExtension.java o 284, and others, including other files (e.g. SSLExtensions.java): Spelling nit, Change "onLoadConcumer" to "onLoadConsumer" o Is this intended to be a registry of all known extensions? There are gaps in this list that are in the IANA extensions registry, but they're all extension types we don't support yet or have no plans to support.? Since it's an enum, should this list be as complete as possible given the registered IDs that are out there? * SSLExtensions.java o 59: Should there be a check to make sure there is sufficient remaining space in the buffer after the extensions length is retrieved?? You do something similar to that down on line 62 after you get each individual extension length, perhaps a top-level one would be good too. * SSLHandshake.java o 128, possibly used in other files: Spelling nit, CERTIFICARE_REQUEST --> CERTIFICATE_REQUEST o 253: Maybe add a known-but-not-supported entry for MESSAGE_HASH ((byte)0xFE, "message_hash"); * TransportContext.java o 288 & 343: On 288 you comment about shutting down the transport, but the transport object doesn't really get used until way down at 343, and there's only logging up around 288.? Maybe this comment should get moved down there? o 448: This is more curiosity on my part, I see isBroken checked in a few different places throughout the code, but nowhere in the webrev do I see a place where isBroken is ever set to true.? Is this something you expect to set when more of the handshake framework is implemented?? What is the criteria for setting isBroken to true? Thanks, --Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Jan 11 04:44:42 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 11 Jan 2018 12:44:42 +0800 Subject: About signature algorithm and provider name in SignedObject spec Message-ID: The class spec of SignedObject.java [1] contains: * 
{@code
* Signature signingEngine = Signature.getInstance(algorithm,
*                                                 provider);
* SignedObject so = new SignedObject(myobject, signingKey,
*                                    signingEngine);
* }
... *

The signature algorithm can be, among others, the NIST standard * DSA, using DSA and SHA-256. The algorithm is specified using the * same convention as that for signatures. The DSA algorithm using the * SHA-256 message digest algorithm can be specified, for example, as * "SHA256withDSA". In the case of * RSA or EC the signing algorithm could be specified as, for example, * "SHA256withRSA" or "SHA256withECDSA". The algorithm name must be * specified, as there is no default. * *

The name of the Cryptography Package Provider is designated * also by the Signature parameter to the constructor and the * {@code verify} method. If the provider is not * specified, the default provider is used. Each installation can * be configured to use a particular provider as default. While the signature algorithm and provider name can be interpreted as those used in the example, I think there is no need to describe them in so much detail in the class spec. The class contains no API that needs the signature algorithm or a provider name. All is needed is just a Signature object. getAlgorithm() returns the algorithm but it's not input. I suggest removing the last 2 paragraphs above, and IMO no CSR is needed. Thanks Max [1] https://docs.oracle.com/javase/9/docs/api/java/security/SignedObject.html From sibabrata.sahoo at oracle.com Thu Jan 11 05:30:42 2018 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Wed, 10 Jan 2018 21:30:42 -0800 (PST) Subject: [11] RFR: 8194486: Several krb5 tests failed in Mac. In-Reply-To: <1C6FF3C7-7B21-4EC1-AAA1-90735498DB68@oracle.com> References: <1C6FF3C7-7B21-4EC1-AAA1-90735498DB68@oracle.com> Message-ID: I will remove the commented lines. I think, it should be fine, if I do not submit the webrev again. Thanks, Siba -----Original Message----- From: Weijun Wang Sent: Wednesday, January 10, 2018 9:07 PM To: Sibabrata Sahoo Cc: security-dev at openjdk.java.net Subject: Re: [11] RFR: 8194486: Several krb5 tests failed in Mac. Code change looks fine. I think you can safely remove the lines commented out. If you meant to keep the history, the Mercurial repo already had it. Thanks Max > On Jan 10, 2018, at 8:58 PM, Sibabrata Sahoo wrote: > > Hi, > > Please review the change for the following patch, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8194486 > Webrev: http://cr.openjdk.java.net/~ssahoo/8194486/webrev.00/ > > Description: > There are several failure occurred recently because the name service used by these Tests were not determinable. This patch fixes those issues. > > > Thanks, > Siba From weijun.wang at oracle.com Thu Jan 11 06:03:25 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 11 Jan 2018 14:03:25 +0800 Subject: [11] RFR: 8194486: Several krb5 tests failed in Mac. In-Reply-To: References: <1C6FF3C7-7B21-4EC1-AAA1-90735498DB68@oracle.com> Message-ID: <15E00DFA-947C-484F-8DC4-CDDBBF9F703E@oracle.com> > On Jan 11, 2018, at 1:30 PM, Sibabrata Sahoo wrote: > > I will remove the commented lines. I think, it should be fine, if I do not submit the webrev again. Not necessary at all. --Max > > Thanks, > Siba > > -----Original Message----- > From: Weijun Wang > Sent: Wednesday, January 10, 2018 9:07 PM > To: Sibabrata Sahoo > Cc: security-dev at openjdk.java.net > Subject: Re: [11] RFR: 8194486: Several krb5 tests failed in Mac. > > Code change looks fine. I think you can safely remove the lines commented out. If you meant to keep the history, the Mercurial repo already had it. > > Thanks > Max > >> On Jan 10, 2018, at 8:58 PM, Sibabrata Sahoo wrote: >> >> Hi, >> >> Please review the change for the following patch, >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8194486 >> Webrev: http://cr.openjdk.java.net/~ssahoo/8194486/webrev.00/ >> >> Description: >> There are several failure occurred recently because the name service used by these Tests were not determinable. This patch fixes those issues. >> >> >> Thanks, >> Siba > From sean.mullan at oracle.com Thu Jan 11 14:07:34 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 11 Jan 2018 09:07:34 -0500 Subject: About signature algorithm and provider name in SignedObject spec In-Reply-To: References: Message-ID: On 1/10/18 11:44 PM, Weijun Wang wrote: > The class spec of SignedObject.java [1] contains: > > * 

{@code
> * Signature signingEngine = Signature.getInstance(algorithm,
> *                                                 provider);
> * SignedObject so = new SignedObject(myobject, signingKey,
> *                                    signingEngine);
> * }
> ... > *

The signature algorithm can be, among others, the NIST standard > * DSA, using DSA and SHA-256. The algorithm is specified using the > * same convention as that for signatures. The DSA algorithm using the > * SHA-256 message digest algorithm can be specified, for example, as > * "SHA256withDSA". In the case of > * RSA or EC the signing algorithm could be specified as, for example, > * "SHA256withRSA" or "SHA256withECDSA". The algorithm name must be > * specified, as there is no default. > * > *

The name of the Cryptography Package Provider is designated > * also by the Signature parameter to the constructor and the > * {@code verify} method. If the provider is not > * specified, the default provider is used. Each installation can > * be configured to use a particular provider as default. > > While the signature algorithm and provider name can be interpreted as those used in the example, I think there is no need to describe them in so much detail in the class spec. The class contains no API that needs the signature algorithm or a provider name. All is needed is just a Signature object. > > getAlgorithm() returns the algorithm but it's not input. > > I suggest removing the last 2 paragraphs above, and IMO no CSR is needed. Sounds good. I agree no CSR is needed. --Sean From martinrb at google.com Fri Jan 12 04:29:45 2018 From: martinrb at google.com (Martin Buchholz) Date: Thu, 11 Jan 2018 20:29:45 -0800 Subject: RFR: 8194960: Add a test for trust manager and cacerts keystore sanity Message-ID: https://bugs.openjdk.java.net/browse/JDK-8194960 http://cr.openjdk.java.net/~martin/webrevs/jdk/CacertsExplorer/ I have no idea what I'm doing, so review this carefully. Is this really the recommended way to list all the cacerts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy.lu at oracle.com Fri Jan 12 04:51:53 2018 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 12 Jan 2018 12:51:53 +0800 Subject: [10] RFR 8194959: Correct test tag to move bugid from @test to @bug Message-ID: Please review this minor test-tag-only change to move bugid from @test to @bug bug: https://bugs.openjdk.java.net/browse/JDK-8194959 webrev: http://cr.openjdk.java.net/~amlu/8194959/webrev.00/ Thanks, Amy From sundararajan.athijegannathan at oracle.com Fri Jan 12 05:08:55 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 12 Jan 2018 10:38:55 +0530 Subject: [10] RFR 8194959: Correct test tag to move bugid from @test to @bug In-Reply-To: References: Message-ID: <5A5842E7.4050804@oracle.com> +1 -Sundar On 12/01/18, 10:21 AM, Amy Lu wrote: > Please review this minor test-tag-only change to move bugid from @test > to @bug > > bug: https://bugs.openjdk.java.net/browse/JDK-8194959 > webrev: http://cr.openjdk.java.net/~amlu/8194959/webrev.00/ > > Thanks, > Amy From Alan.Bateman at oracle.com Fri Jan 12 08:51:06 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 12 Jan 2018 08:51:06 +0000 Subject: [10] RFR 8194959: Correct test tag to move bugid from @test to @bug In-Reply-To: References: Message-ID: On 12/01/2018 04:51, Amy Lu wrote: > Please review this minor test-tag-only change to move bugid from @test > to @bug > > bug: https://bugs.openjdk.java.net/browse/JDK-8194959 > webrev: http://cr.openjdk.java.net/~amlu/8194959/webrev.00/ Looks good. From amy.lu at oracle.com Fri Jan 12 08:56:10 2018 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 12 Jan 2018 16:56:10 +0800 Subject: [10] RFR 8194959: Correct test tag to move bugid from @test to @bug In-Reply-To: References: Message-ID: <17bf235e-88c1-76fe-89f4-99ea7303ec06@oracle.com> Thank you Alan and Sundar for your quick review. Changes pushed. Thanks, Amy On 12/01/2018 4:51 PM, Alan Bateman wrote: > > > On 12/01/2018 04:51, Amy Lu wrote: >> Please review this minor test-tag-only change to move bugid from >> @test to @bug >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8194959 >> webrev: http://cr.openjdk.java.net/~amlu/8194959/webrev.00/ > Looks good. From tobias.wagner at n-design.de Fri Jan 12 14:12:17 2018 From: tobias.wagner at n-design.de (=?utf-8?Q?Tobias_Wagner?=) Date: Fri, 12 Jan 2018 15:12:17 +0100 Subject: [PATCH]: Support for brainpool curves from CurveDB in SunEC Message-ID: Hi, here is the next patch for brainpool curve support in SunEC. Differences from the first patch: * Brainpool curves with less than 256 bits are removed. Subsequently, the curve oid check is made more robust to avoid null pointer caused Segmentation Faults in memcmp calls. * Bug JDK-8189594 is fixed. * Known answer tests for each new curve are added to sun.security.pkcs11.ec.TestECDH. The tests are only executed, if the tested provider's name is "SunEC" and the tested provider claims to support the respective curve. For SunEC, these tests are executed during sun.security.ec.TestEC. I decided to add these test vectors to TestECDH to avoid code duplications, as TestECDH is describes exactly the test for that kind of test vectors. The superclass to TestECDH, TestPKCS11, is also adapted to provide a method to check, whether one particular curve is supported. While the test vectors for the 256, 384 and 512 bit curve are taken from [1], the test vector for brainpoolP320r1 comes from [2]. The latter one is a draft version of RFC 6954. Regards, Tobias [1] https://tools.ietf.org/html/rfc7027#appendix-A [2] https://tools.ietf.org/html/draft-merkle-ikev2-ke-brainpool-00#appendix-A.5 -- phone: +49 221 222896 17 fax: +49 221 222896 11 n - d e s i g n G m b H www.n-design.de Alpenerstr. 16 D-50825 K?ln Amtsgericht K?ln HRB 33766 B Gesch?ftsf?hrer Andy Kohl -------------- next part -------------- A non-text attachment was scrubbed... Name: jdk9_jdk_patch_17287f.diff Type: application/octet-stream Size: 23972 bytes Desc: not available URL: From sean.mullan at oracle.com Fri Jan 12 19:52:55 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 12 Jan 2018 14:52:55 -0500 Subject: RFR 8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5 In-Reply-To: <1EDCCE6B-6A53-4893-BADB-1B725BACC75E@oracle.com> References: <598A4449-E91D-4B13-A4F0-B2313BE36A8B@oracle.com> <226355E4-F0B1-45CB-95C5-E86E93BCC112@oracle.com> <99efce43-6df7-41e9-1de6-9f71a6d5c4da@oracle.com> <80B2118E-D9F3-47B6-B3E8-19AAD3EE5289@oracle.com> <1EDCCE6B-6A53-4893-BADB-1B725BACC75E@oracle.com> Message-ID: <4a4eb7b3-19be-ca8a-8407-828c138f7cad@oracle.com> On 1/9/18 8:40 PM, Weijun Wang wrote: >> The code can also throw GeneralSecurityException but those are also always suppressed because of the catch block. Is that the right behavior? >> > Not a right behavior but should be harmless here. In my understanding, in the case of PBE, as long the passphrase, salt, iteration count etc are legal, there will be no further problem in generating a key, choosing a cipher, and do the encryption work, unless there is a programming error. > > I think the original designer (of other etypes) meant to let stringToKey(char,String,byte[]) returning a null when there is an error, and all callers of this method will deal with null instead of an exception. If not programmed carefully, this might turn a GeneralSecurityException to a NullPointerException. Ok, I think this is bad practice, but since it has worked that way since the beginning, I'm ok with leaving it alone. --Sean From chris at christopherschultz.net Fri Jan 12 23:00:40 2018 From: chris at christopherschultz.net (Christopher Schultz) Date: Fri, 12 Jan 2018 18:00:40 -0500 Subject: [PATCH] Crypto EC - avoids possible memset compiler optimisation In-Reply-To: <09e008d7-a38b-bd29-19af-1ca7f5d516b7@oracle.com> References: <09e008d7-a38b-bd29-19af-1ca7f5d516b7@oracle.com> Message-ID: <56841f92-8abd-78c0-9740-8aabd7d08531@christopherschultz.net> Adam and David, On 1/8/18 11:30 AM, Adam Petcher wrote: > On 1/8/2018 10:13 AM, David CARLIER wrote: > >> Hi, >> >> Here a little patch proposal which is usually relevant in >> cryptographics matters. Usually memset/bzero/... is used to clear >> private structures but the compiler can possibly optimize those calls >> but with this change we can unsure sensitive data is properly zero'ed >> using if possible native calls or memory fence. > > SunEC doesn't really make an effort to zeroize sensitive data, and all > of the memset operations except for one (line 418) operate on memory > that is not sensitive. While the patch is a relatively simple change > that probably doesn't hurt anything, it doesn't seem to me like this > improvement is particularly valuable. Perhaps it would be more valuable > along with a larger improvement to make SunEC zeroize all intermediate > values. Though this would be a much larger undertaking, and it still may > not be useful on its own because the Java code in the provider also > holds some sensitive values. Also, if you want to "sanitize" memory, you ought to: 1. use explicit_bzero instead of bzero, as bzip may be optimized-away by the compiler[1] 2. use memset instead of bzero, as memset is POSIX[2] and bzero is not[3] 3. use memset_s instead of memset, since memset_s is guaranteed not to be optimized-away by the compiler[4]. Its presence is not guaranteed, so use compiler macros to ensure you have a backup plan if it is not available (e.g. use memset or manual memory-scrubbing). 4. On Windows, use SecureZeroMemory[5], for reasons similar to the above -chris [1] https://www.freebsd.org/cgi/man.cgi?query=explicit_bzero [2] https://linux.die.net/man/3/memset [3] https://linux.die.net/man/3/bzero [4] http://en.cppreference.com/w/c/string/byte/memset [5] https://msdn.microsoft.com/en-us/library/windows/desktop/aa366877.aspx -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 979 bytes Desc: OpenPGP digital signature URL: From chris at christopherschultz.net Fri Jan 12 23:02:18 2018 From: chris at christopherschultz.net (Christopher Schultz) Date: Fri, 12 Jan 2018 18:02:18 -0500 Subject: [PATCH] Crypto EC - avoids possible memset compiler optimisation In-Reply-To: <56841f92-8abd-78c0-9740-8aabd7d08531@christopherschultz.net> References: <09e008d7-a38b-bd29-19af-1ca7f5d516b7@oracle.com> <56841f92-8abd-78c0-9740-8aabd7d08531@christopherschultz.net> Message-ID: <06cdc64e-6f02-90fd-6851-88c7ee4c7f54@christopherschultz.net> All, Apologies... I had only read the top of the patch before replying. All my comments had already been addressed in the actual patch. Sorry for the noise. -chris On 1/12/18 6:00 PM, Christopher Schultz wrote: > Adam and David, > > On 1/8/18 11:30 AM, Adam Petcher wrote: >> On 1/8/2018 10:13 AM, David CARLIER wrote: >> >>> Hi, >>> >>> Here a little patch proposal which is usually relevant in >>> cryptographics matters. Usually memset/bzero/... is used to clear >>> private structures but the compiler can possibly optimize those calls >>> but with this change we can unsure sensitive data is properly zero'ed >>> using if possible native calls or memory fence. >> >> SunEC doesn't really make an effort to zeroize sensitive data, and all >> of the memset operations except for one (line 418) operate on memory >> that is not sensitive. While the patch is a relatively simple change >> that probably doesn't hurt anything, it doesn't seem to me like this >> improvement is particularly valuable. Perhaps it would be more valuable >> along with a larger improvement to make SunEC zeroize all intermediate >> values. Though this would be a much larger undertaking, and it still may >> not be useful on its own because the Java code in the provider also >> holds some sensitive values. > > Also, if you want to "sanitize" memory, you ought to: > > 1. use explicit_bzero instead of bzero, as bzip may be optimized-away by > the compiler[1] > > 2. use memset instead of bzero, as memset is POSIX[2] and bzero is not[3] > > 3. use memset_s instead of memset, since memset_s is guaranteed not to > be optimized-away by the compiler[4]. Its presence is not guaranteed, so > use compiler macros to ensure you have a backup plan if it is not > available (e.g. use memset or manual memory-scrubbing). > > 4. On Windows, use SecureZeroMemory[5], for reasons similar to the above > > -chris > > [1] https://www.freebsd.org/cgi/man.cgi?query=explicit_bzero > [2] https://linux.die.net/man/3/memset > [3] https://linux.die.net/man/3/bzero > [4] http://en.cppreference.com/w/c/string/byte/memset > [5] https://msdn.microsoft.com/en-us/library/windows/desktop/aa366877.aspx > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 979 bytes Desc: OpenPGP digital signature URL: From weijun.wang at oracle.com Mon Jan 15 02:12:50 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 15 Jan 2018 10:12:50 +0800 Subject: RFR 8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5 In-Reply-To: <4a4eb7b3-19be-ca8a-8407-828c138f7cad@oracle.com> References: <598A4449-E91D-4B13-A4F0-B2313BE36A8B@oracle.com> <226355E4-F0B1-45CB-95C5-E86E93BCC112@oracle.com> <99efce43-6df7-41e9-1de6-9f71a6d5c4da@oracle.com> <80B2118E-D9F3-47B6-B3E8-19AAD3EE5289@oracle.com> <1EDCCE6B-6A53-4893-BADB-1B725BACC75E@oracle.com> <4a4eb7b3-19be-ca8a-8407-828c138f7cad@oracle.com> Message-ID: Hi Sean Do you have other comments on the webrev [1]? I've also updated the CSR [2]. Thanks Max [1] http://cr.openjdk.java.net/~weijun/8014628/webrev.00/ [2] https://bugs.openjdk.java.net/browse/JDK-8193851 > On Jan 13, 2018, at 3:52 AM, Sean Mullan wrote: > > On 1/9/18 8:40 PM, Weijun Wang wrote: >>> The code can also throw GeneralSecurityException but those are also always suppressed because of the catch block. Is that the right behavior? >>> >> Not a right behavior but should be harmless here. In my understanding, in the case of PBE, as long the passphrase, salt, iteration count etc are legal, there will be no further problem in generating a key, choosing a cipher, and do the encryption work, unless there is a programming error. >> I think the original designer (of other etypes) meant to let stringToKey(char,String,byte[]) returning a null when there is an error, and all callers of this method will deal with null instead of an exception. If not programmed carefully, this might turn a GeneralSecurityException to a NullPointerException. > > Ok, I think this is bad practice, but since it has worked that way since the beginning, I'm ok with leaving it alone. > > --Sean From weijun.wang at oracle.com Tue Jan 16 01:57:01 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 16 Jan 2018 09:57:01 +0800 Subject: RFR 8195119: Fine-tune output text in keytool Message-ID: <01EDE777-7A4B-45F2-B1E7-4458A5202533@oracle.com> The translation team suggested a small text change: diff --git a/src/java.base/share/classes/sun/security/tools/keytool/Resources.java b/src/java.base/share/classes/sun/security/tools/keytool/Resources.java --- a/src/java.base/share/classes/sun/security/tools/keytool/Resources.java +++ b/src/java.base/share/classes/sun/security/tools/keytool/Resources.java @@ -462,7 +462,7 @@ {"with.weak", "%s (weak)"}, {"key.bit", "%1$d-bit %2$s key"}, {"key.bit.weak", "%1$d-bit %2$s key (weak)"}, - {"unknown.size.1", "unknown size %s key"}, + {"unknown.size.1", "%s key of unknown size"}, {".PATTERN.printX509Cert.with.weak", "Owner: {0}\nIssuer: {1}\nSerial number: {2}\nValid from: {3} until: {4}\nCertificate fingerprints:\n\t SHA1: {5}\n\t SHA256: {6}\nSignature algorithm name: {7}\nSubject Public Key Algorithm: {8}\nVersion: {9}"}, {"PKCS.10.with.weak", Please take a review. Noreg-trivial. Thanks Max From weijun.wang at oracle.com Tue Jan 16 03:47:55 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 16 Jan 2018 11:47:55 +0800 Subject: RFR: 8194960: Add a test for trust manager and cacerts keystore sanity In-Reply-To: References: Message-ID: <498B11D1-713B-4327-ACC4-82C536A5C5A1@oracle.com> Hi Martin This is fine as a test. I don't know which is the recommended call, but "keytool -list -cacerts" also does it. BTW, usually we add braces even if there is only one statement in an if block. Thanks Max > On Jan 12, 2018, at 12:29 PM, Martin Buchholz wrote: > > https://bugs.openjdk.java.net/browse/JDK-8194960 > http://cr.openjdk.java.net/~martin/webrevs/jdk/CacertsExplorer/ > > I have no idea what I'm doing, so review this carefully. > Is this really the recommended way to list all the cacerts? From sean.mullan at oracle.com Tue Jan 16 12:38:50 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 16 Jan 2018 07:38:50 -0500 Subject: RFR 8195119: Fine-tune output text in keytool In-Reply-To: <01EDE777-7A4B-45F2-B1E7-4458A5202533@oracle.com> References: <01EDE777-7A4B-45F2-B1E7-4458A5202533@oracle.com> Message-ID: <3b81fb3f-1f27-f6b7-f866-bcdf3ff2eccd@oracle.com> Looks good. --Sean On 1/15/18 8:57 PM, Weijun Wang wrote: > The translation team suggested a small text change: > > diff --git a/src/java.base/share/classes/sun/security/tools/keytool/Resources.java b/src/java.base/share/classes/sun/security/tools/keytool/Resources.java > --- a/src/java.base/share/classes/sun/security/tools/keytool/Resources.java > +++ b/src/java.base/share/classes/sun/security/tools/keytool/Resources.java > @@ -462,7 +462,7 @@ > {"with.weak", "%s (weak)"}, > {"key.bit", "%1$d-bit %2$s key"}, > {"key.bit.weak", "%1$d-bit %2$s key (weak)"}, > - {"unknown.size.1", "unknown size %s key"}, > + {"unknown.size.1", "%s key of unknown size"}, > {".PATTERN.printX509Cert.with.weak", > "Owner: {0}\nIssuer: {1}\nSerial number: {2}\nValid from: {3} until: {4}\nCertificate fingerprints:\n\t SHA1: {5}\n\t SHA256: {6}\nSignature algorithm name: {7}\nSubject Public Key Algorithm: {8}\nVersion: {9}"}, > {"PKCS.10.with.weak", > > Please take a review. > > Noreg-trivial. > > Thanks > Max > From sean.mullan at oracle.com Tue Jan 16 16:35:10 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 16 Jan 2018 11:35:10 -0500 Subject: RFR 8014628: Support AES Encryption with HMAC-SHA2 for Kerberos 5 In-Reply-To: References: <598A4449-E91D-4B13-A4F0-B2313BE36A8B@oracle.com> <226355E4-F0B1-45CB-95C5-E86E93BCC112@oracle.com> <99efce43-6df7-41e9-1de6-9f71a6d5c4da@oracle.com> <80B2118E-D9F3-47B6-B3E8-19AAD3EE5289@oracle.com> <1EDCCE6B-6A53-4893-BADB-1B725BACC75E@oracle.com> <4a4eb7b3-19be-ca8a-8407-828c138f7cad@oracle.com> Message-ID: On 1/14/18 9:12 PM, Weijun Wang wrote: > Hi Sean > > Do you have other comments on the webrev [1]? No. > > I've also updated the CSR [2]. Ok, thanks. --Sean > > Thanks > Max > > [1] http://cr.openjdk.java.net/~weijun/8014628/webrev.00/ > [2] https://bugs.openjdk.java.net/browse/JDK-8193851 > >> On Jan 13, 2018, at 3:52 AM, Sean Mullan wrote: >> >> On 1/9/18 8:40 PM, Weijun Wang wrote: >>>> The code can also throw GeneralSecurityException but those are also always suppressed because of the catch block. Is that the right behavior? >>>> >>> Not a right behavior but should be harmless here. In my understanding, in the case of PBE, as long the passphrase, salt, iteration count etc are legal, there will be no further problem in generating a key, choosing a cipher, and do the encryption work, unless there is a programming error. >>> I think the original designer (of other etypes) meant to let stringToKey(char,String,byte[]) returning a null when there is an error, and all callers of this method will deal with null instead of an exception. If not programmed carefully, this might turn a GeneralSecurityException to a NullPointerException. >> >> Ok, I think this is bad practice, but since it has worked that way since the beginning, I'm ok with leaving it alone. >> >> --Sean > From adam.petcher at oracle.com Tue Jan 16 17:36:46 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 16 Jan 2018 12:36:46 -0500 Subject: [PATCH]: Support for brainpool curves from CurveDB in SunEC In-Reply-To: References: Message-ID: <46d44858-4a0c-cb61-7bc6-13a84f5acd79@oracle.com> Great! I took a look at the patch, and I have some comments, the first of which probably needs to be addressed before I can test the change: 1) Is this patch against the http://hg.openjdk.java.net/jdk/jdk repository? I suspect it isn't because some of the paths are different than what I expect. We have made a lot of changes to the repositories in the last few months. If this patch is against an older repo, please send a patch against http://hg.openjdk.java.net/jdk/jdk . 2) TestECDH.java: It's probably better to remove the provider name check on line 116 and test on any providers that support the curve. 3) oid.c: I think you can remove the comments that say "XXX bounds check" (e.g. line 362). If I am interpreting these comments correctly, they are saying that memcmp may read out of bounds, but you fixed that problem by using oideql. 4) Is there an existing test that exercises ECDSA with the new curves? Maybe there is something in the PKCS11 tests that does this already, but I didn't find it. I think we should have an ECDSA test to make sure that we didn't forget anything. ECDSA test vectors probably aren't necessary---a simple test that signs and verifies using the new curves should be sufficient. On 1/12/2018 9:12 AM, Tobias Wagner wrote: > Hi, > > here is the next patch for brainpool curve support in SunEC. > > Differences from the first patch: > > * Brainpool curves with less than 256 bits are removed. Subsequently, the curve oid check is made more robust to avoid null > pointer caused Segmentation Faults in memcmp calls. > > * Bug JDK-8189594 is fixed. > > * Known answer tests for each new curve are added to sun.security.pkcs11.ec.TestECDH. The tests are only executed, if the > tested provider's name is "SunEC" and the tested provider claims to support the respective curve. For SunEC, these tests are > executed during sun.security.ec.TestEC. > > I decided to add these test vectors to TestECDH to avoid code duplications, as TestECDH is describes exactly the test > for that kind of test vectors. > The superclass to TestECDH, TestPKCS11, is also adapted to provide a method to check, whether one particular curve is > supported. > > While the test vectors for the 256, 384 and 512 bit curve are taken from [1], the test vector for brainpoolP320r1 comes from [2]. > The latter one is a draft version of RFC 6954. > > Regards, > Tobias > > [1] https://tools.ietf.org/html/rfc7027#appendix-A > [2] https://tools.ietf.org/html/draft-merkle-ikev2-ke-brainpool-00#appendix-A.5 > > From leo at ssl.com Wed Jan 17 02:03:41 2018 From: leo at ssl.com (Leo Grove) Date: Wed, 17 Jan 2018 02:03:41 +0000 Subject: contribute to the OpenJDK security group Message-ID: <0100016101db8f7d-19737975-67eb-4dab-ba94-c68d46746ab9-000000@email.amazonses.com> Hello Everyone, I'd like to introduce myself. I'm Leo Grove, founder of SSL.com and also Java Certified Programmer ('98). Although I'm not so much into coding these days, I'm always looking for ways to contribute to internet security and the public WebPKI. We do have some very sharp java developers that specialize in PKI and certs, so if there is something you need a hand with (or a pair of eyeballs on), please let me know, thanks. -- Leo Grove President SSL.com w: https://www.ssl.com PKI ? EV SSL/TLS ? S/MIME ? EV Code Signing From martinrb at google.com Wed Jan 17 04:08:59 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 16 Jan 2018 20:08:59 -0800 Subject: RFR: 8194960: Add a test for trust manager and cacerts keystore sanity In-Reply-To: <498B11D1-713B-4327-ACC4-82C536A5C5A1@oracle.com> References: <498B11D1-713B-4327-ACC4-82C536A5C5A1@oracle.com> Message-ID: On Mon, Jan 15, 2018 at 7:47 PM, Weijun Wang wrote: > Hi Martin > > This is fine as a test. I don't know which is the recommended call, but > "keytool -list -cacerts" also does it. > > The test uses an API that adds a layer of abstraction, not exposing the presence of a cacerts file. > BTW, usually we add braces even if there is only one statement in an if > block. > Braces added as you prefer, and pushed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brendan.Mckenna at mdscem.com Wed Jan 17 12:26:04 2018 From: Brendan.Mckenna at mdscem.com (Brendan McKenna) Date: Wed, 17 Jan 2018 12:26:04 +0000 Subject: JCEKS Keystore problem Message-ID: Hi, My apologies if this isn't the correct place to send this email. We're using OpenJDK and a part of our application makes use of JCEKS keystores. When moving from Java 1.8.0_141 to Java 1.8.0_151, however, we are no longer able to open keystores written using earlier versions of the JVM. We now get a SecurityException with the message "Invalid secret key format", which appears to be coming from the com.sun.crypto.provider.JceKeyStore class, line 856, in response to receiving an InvalidClassException. The keystores are still usable, so long as we avoid moving to _151, however. Although I'm not certain, it appears that the DeserializationChecker that was added in _151 is triggering this issue. My question though is, is there a work-around for this, or do we have to re-create our keystores using _151? Thanks, Brendan Brendan McKenna | Product Technology Manager MDS m +353 (0) 61 207423 | e brendan.mckenna at mdscem.com w mdscem.com | follow us on Twitter @MDSglobal ******************************************************* MDS is a leading provider of convergent real-time charging, billing and customer management solutions for digital service providers. Our solutions support millions of subscribers, with customers including BT, Dixons Carphone, eir, TalkTalk and Telef?nica UK. This email has been sent from Martin Dawes Systems Limited trading as MDS, a registered company incorporated in England and Wales with registered number 02263085 . The registered office is The Point, 410 Birchwood Boulevard, Warrington, Cheshire WA3 7WD. MDS may monitor email traffic data and also the content of email for the purposes of security, ensure compliance with company policies and staff training. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Jan 17 13:53:19 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 17 Jan 2018 08:53:19 -0500 Subject: contribute to the OpenJDK security group In-Reply-To: <0100016101db8f7d-19737975-67eb-4dab-ba94-c68d46746ab9-000000@email.amazonses.com> References: <0100016101db8f7d-19737975-67eb-4dab-ba94-c68d46746ab9-000000@email.amazonses.com> Message-ID: Hi Leo, Thanks for the offer to help and contribute! I would suggest you start by reading the OpenJDK contribution page (if you have not done so already): http://openjdk.java.net/contribute/ which has some tips and other helpful advice. You will also need to sign an OCA (Oracle Contributor Agreement) before we can accept any contributions. Thanks, Sean On 1/16/18 9:03 PM, Leo Grove wrote: > Hello Everyone, > > I'd like to introduce myself. I'm Leo Grove, founder of SSL.com and also > Java Certified Programmer ('98). Although I'm not so much into coding > these days, I'm always looking for ways to contribute to internet > security and the public WebPKI. We do have some very sharp java > developers that specialize in PKI and certs, so if there is something > you need a hand with (or a pair of eyeballs on), please let me know, > thanks. From weijun.wang at oracle.com Wed Jan 17 14:17:09 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 17 Jan 2018 22:17:09 +0800 Subject: JCEKS Keystore problem In-Reply-To: References: Message-ID: Hi Brendan If you print out the keystore, can you see the java.lang.Object string inside? If so, we are aware of this issue and it will be fixed in the Apr 2018 update releases. At the moment, you can convert the keystore to a new format using keytool from _141, like this: keytool -importkeystore -srckeystore oldname -destkeystore newname -srcstoretype jceks -deststoretype jceks -srcstorepass password -deststorepass password Of course, you can also re-create the keystores using _151. Hope this helps --Max > On Jan 17, 2018, at 8:26 PM, Brendan McKenna wrote: > > Hi, > > My apologies if this isn?t the correct place to send this email. > > We?re using OpenJDK and a part of our application makes use of JCEKS keystores. When moving from Java 1.8.0_141 to Java 1.8.0_151, however, we are no longer able to open keystores written using earlier versions of the JVM. We now get a SecurityException with the message ?Invalid secret key format?, which appears to be coming from the com.sun.crypto.provider.JceKeyStore class, line 856, in response to receiving an InvalidClassException. The keystores are still usable, so long as we avoid moving to _151, however. Although I?m not certain, it appears that the DeserializationChecker that was added in _151 is triggering this issue. > > My question though is, is there a work-around for this, or do we have to re-create our keystores using _151? > > > Thanks, > > Brendan > > > Brendan McKenna | Product Technology Manager MDS > m +353 (0) 61 207423 | e brendan.mckenna at mdscem.com w mdscem.com | follow us on Twitter @MDSglobal > > ******************************************************* > MDS is a leading provider of convergent real-time charging, billing and customer management solutions for digital service providers. Our solutions support millions of subscribers, with customers including BT, Dixons Carphone, eir, TalkTalk and Telef?nica UK. > > This email has been sent from Martin Dawes Systems Limited trading as MDS, a registered company incorporated in England and Wales with registered number 02263085 . The registered office is The Point, 410 Birchwood Boulevard, Warrington, Cheshire WA3 7WD. MDS may monitor email traffic data and also the content of email for the purposes of security, ensure compliance with company policies and staff training. From sibabrata.sahoo at oracle.com Wed Jan 17 14:20:47 2018 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Wed, 17 Jan 2018 06:20:47 -0800 (PST) Subject: [11] RFR: 8194486: Several krb5 tests failed in Mac. In-Reply-To: <15E00DFA-947C-484F-8DC4-CDDBBF9F703E@oracle.com> References: <1C6FF3C7-7B21-4EC1-AAA1-90735498DB68@oracle.com> <15E00DFA-947C-484F-8DC4-CDDBBF9F703E@oracle.com> Message-ID: Hi Max, Here is an updated patch: http://cr.openjdk.java.net/~ssahoo/8194486/webrev.01/ I found there are few more Test files which need the similar change as applicable to all other Test files in "sun/security/krb5/auto" folder. The change is applied to all Test files except the following 2 Test files inside the same folder. ReplayCacheExpunge.java ReplayCachePrecise.java Thanks, Siba -----Original Message----- From: Weijun Wang Sent: Thursday, January 11, 2018 11:33 AM To: Sibabrata Sahoo Cc: security-dev at openjdk.java.net Subject: Re: [11] RFR: 8194486: Several krb5 tests failed in Mac. > On Jan 11, 2018, at 1:30 PM, Sibabrata Sahoo wrote: > > I will remove the commented lines. I think, it should be fine, if I do not submit the webrev again. Not necessary at all. --Max > > Thanks, > Siba > > -----Original Message----- > From: Weijun Wang > Sent: Wednesday, January 10, 2018 9:07 PM > To: Sibabrata Sahoo > Cc: security-dev at openjdk.java.net > Subject: Re: [11] RFR: 8194486: Several krb5 tests failed in Mac. > > Code change looks fine. I think you can safely remove the lines commented out. If you meant to keep the history, the Mercurial repo already had it. > > Thanks > Max > >> On Jan 10, 2018, at 8:58 PM, Sibabrata Sahoo wrote: >> >> Hi, >> >> Please review the change for the following patch, >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8194486 >> Webrev: http://cr.openjdk.java.net/~ssahoo/8194486/webrev.00/ >> >> Description: >> There are several failure occurred recently because the name service used by these Tests were not determinable. This patch fixes those issues. >> >> >> Thanks, >> Siba > From Brendan.Mckenna at mdscem.com Wed Jan 17 14:42:23 2018 From: Brendan.Mckenna at mdscem.com (Brendan McKenna) Date: Wed, 17 Jan 2018 14:42:23 +0000 Subject: JCEKS Keystore problem In-Reply-To: References: Message-ID: Hi Max, Thanks for the information. In looking at the keystore, I do not see java.lang.Object. I see several references to java.lang.String and to javax.crypto.SealedObject, but no references to java.lang.Object. I can pass along a copy of one of the affected keystores, if that'd help. The problem for us is that we have a number of customer deployments using JCEKS keystores generated from earlier (pre _151) versions of Java, so we'd have to regenerate a rather large number of keystores and re-deploy them. Thanks again, though. Brendan PS. I can also confirm that the issue arises with the Oracle _151 and later JVMs as well, but I think that's to be expected. Brendan McKenna | Product Technology Manager MDS m +353 (0) 61 207423 | e brendan.mckenna at mdscem.com w mdscem.com | follow us on Twitter @MDSglobal ******************************************************* MDS is a leading provider of convergent real-time charging, billing and customer management solutions for digital service providers. Our solutions support millions of subscribers, with customers including BT, Dixons Carphone, eir, TalkTalk and Telef?nica UK. -----Original Message----- From: Weijun Wang [mailto:weijun.wang at oracle.com] Sent: 17 January 2018 14:17 To: Brendan McKenna Cc: security-dev at openjdk.java.net Subject: Re: JCEKS Keystore problem Hi Brendan If you print out the keystore, can you see the java.lang.Object string inside? If so, we are aware of this issue and it will be fixed in the Apr 2018 update releases. At the moment, you can convert the keystore to a new format using keytool from _141, like this: keytool -importkeystore -srckeystore oldname -destkeystore newname -srcstoretype jceks -deststoretype jceks -srcstorepass password -deststorepass password Of course, you can also re-create the keystores using _151. Hope this helps --Max > On Jan 17, 2018, at 8:26 PM, Brendan McKenna wrote: > > Hi, > > My apologies if this isn?t the correct place to send this email. > > We?re using OpenJDK and a part of our application makes use of JCEKS keystores. When moving from Java 1.8.0_141 to Java 1.8.0_151, however, we are no longer able to open keystores written using earlier versions of the JVM. We now get a SecurityException with the message ?Invalid secret key format?, which appears to be coming from the com.sun.crypto.provider.JceKeyStore class, line 856, in response to receiving an InvalidClassException. The keystores are still usable, so long as we avoid moving to _151, however. Although I?m not certain, it appears that the DeserializationChecker that was added in _151 is triggering this issue. > > My question though is, is there a work-around for this, or do we have to re-create our keystores using _151? > > > Thanks, > > Brendan > > > Brendan McKenna | Product Technology Manager MDS m +353 (0) 61 207423 > | e brendan.mckenna at mdscem.com w mdscem.com | follow us on Twitter > @MDSglobal > > ******************************************************* > MDS is a leading provider of convergent real-time charging, billing and customer management solutions for digital service providers. Our solutions support millions of subscribers, with customers including BT, Dixons Carphone, eir, TalkTalk and Telef?nica UK. > > This email has been sent from Martin Dawes Systems Limited trading as MDS, a registered company incorporated in England and Wales with registered number 02263085 . The registered office is The Point, 410 Birchwood Boulevard, Warrington, Cheshire WA3 7WD. MDS may monitor email traffic data and also the content of email for the purposes of security, ensure compliance with company policies and staff training. This email has been sent from Martin Dawes Systems Limited trading as MDS, a registered company incorporated in England and Wales with registered number 02263085 . The registered office is The Point, 410 Birchwood Boulevard, Warrington, Cheshire WA3 7WD. MDS may monitor email traffic data and also the content of email for the purposes of security, ensure compliance with company policies and staff training. From xuelei.fan at oracle.com Wed Jan 17 15:37:45 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 17 Jan 2018 07:37:45 -0800 Subject: RFR JDK-8194864: Outputs more details for PKCS11 tests if the NSS lib version cannot be determined In-Reply-To: <237b5f00-2ece-834b-390f-91f6d66ae360@oracle.com> References: <237b5f00-2ece-834b-390f-91f6d66ae360@oracle.com> Message-ID: <5dbae92f-f8dc-b0fb-afaa-754343ad1686@oracle.com> Looks fine to me. Thanks, Xuelei On 1/10/2018 12:28 AM, sha.jiang at oracle.com wrote: > Hi, > JDK-8186098 is raised due to the NSS lib version cannot be determined > from the lib content. > When this issue occurs, it would be better to output the parsed content > for further investigation. > > Webrev: http://cr.openjdk.java.net/~jjiang/8194864/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8194864 > > Best regards, > John Jiang > From leo at ssl.com Wed Jan 17 19:09:15 2018 From: leo at ssl.com (Leo Grove) Date: Wed, 17 Jan 2018 19:09:15 +0000 Subject: contribute to the OpenJDK security group In-Reply-To: References: <0100016101db8f7d-19737975-67eb-4dab-ba94-c68d46746ab9-000000@email.amazonses.com> Message-ID: <0100016105867b86-27ab95e1-97ea-4118-bda9-1680dadcf318-000000@email.amazonses.com> Thanks Sean, I've filled out the OCA and sent it in. I'll take a gander around after reading up on the link you posted and see where we might be able to jump in and assist. Leo On 1/17/2018 7:53 AM, Sean Mullan wrote: > Hi Leo, > > Thanks for the offer to help and contribute! I would suggest you start > by reading the OpenJDK contribution page (if you have not done so > already): > > http://openjdk.java.net/contribute/ > > which has some tips and other helpful advice. You will also need to > sign an OCA (Oracle Contributor Agreement) before we can accept any > contributions. > > Thanks, > Sean > > On 1/16/18 9:03 PM, Leo Grove wrote: >> Hello Everyone, >> >> I'd like to introduce myself. I'm Leo Grove, founder of SSL.com and >> also Java Certified Programmer ('98). Although I'm not so much into >> coding these days, I'm always looking for ways to contribute to >> internet security and the public WebPKI. We do have some very sharp >> java developers that specialize in PKI and certs, so if there is >> something you need a hand with (or a pair of eyeballs on), please let >> me know, thanks. > > From sean.mullan at oracle.com Wed Jan 17 22:36:11 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 17 Jan 2018 17:36:11 -0500 Subject: RFR [10]: 8194307: KeyStore#getInstance with custom LoadStoreParameter succeeds with invalid password Message-ID: <7de363ee-3b96-236c-b87b-05c7141075c3@oracle.com> Please review this tck-red bug that needs to be fixed in JDK 10. bug: https://bugs.openjdk.java.net/browse/JDK-8194307 webrev: http://cr.openjdk.java.net/~mullan/webrevs/8194307/webrev.00/ The current fix is slightly limited in that it doesn't allow the LoadStoreParameter to be passed onto the underlying KeyStore, but that would require an additional API change (an overloaded KeyStore.load method that takes an InputStream and a LoadStoreParameter). Also, none of the existing JDK KeyStore file-based implementations support LoadStoreParameters, so this fix should be sufficient for now or until someone needs or requests that functionality. Thanks, Sean From tobias.wagner at n-design.de Wed Jan 17 23:02:40 2018 From: tobias.wagner at n-design.de (=?utf-8?Q?Tobias_Wagner?=) Date: Thu, 18 Jan 2018 00:02:40 +0100 Subject: [PATCH]: Support for brainpool curves from CurveDB in SunEC Message-ID: -----Urspr?ngliche Nachricht----- > Von:Adam Petcher > Gesendet: Die 16 Januar 2018 18:38 > An: security-dev at openjdk.java.net > Betreff: Re: [PATCH]: Support for brainpool curves from CurveDB in SunEC > > Great! I took a look at the patch, and I have some comments, the first > of which probably needs to be addressed before I can test the change: > > 1) Is this patch against the http://hg.openjdk.java.net/jdk/jdk > repository? I suspect it isn't because some of the paths are different > than what I expect. We have made a lot of changes to the repositories in > the last few months. If this patch is against an older repo, please send > a patch against http://hg.openjdk.java.net/jdk/jdk . I switched to that repository now. As described on http://openjdk.java.net/contribute/, I was working with the http://hg.openjdk.java.net/jdk9/jdk9 repository. > 2) TestECDH.java: It's probably better to remove the provider name check > on line 116 and test on any providers that support the curve. OK, it's removed. I was thinking the same. > 3) oid.c: I think you can remove the comments that say "XXX bounds > check" (e.g. line 362). If I am interpreting these comments correctly, > they are saying that memcmp may read out of bounds, but you fixed that > problem by using oideql. I left them in place - my interpretation is, that they are meant for a check before accessing the *_oids arrays, as C arrays have no implicit check for that. As long as only oids from CurveDB are used, there would be no problems. The least significant byte of the requested oid is used as index. If that index exeeds the defined array length, something odd from the memory there is returned. At least that's my understynding of C and the comment there. > 4) Is there an existing test that exercises ECDSA with the new curves? > Maybe there is something in the PKCS11 tests that does this already, but > I didn't find it. I think we should have an ECDSA test to make sure that > we didn't forget anything. ECDSA test vectors probably aren't > necessary---a simple test that signs and verifies using the new curves > should be sufficient. Yes, there are tests in TestCurves, which runs through TestEC. TestCurves gets a List of all supported ECParameterSpec by the Provider and runs ECDSA signatures and verifications with all of them. The results of all curves are logged in the jtreg report of TestEC. I also changed the InvalidCurve test to use brainpoolP160r1 now, as brainpoolP256r1 is supported by using this patch. > > On 1/12/2018 9:12 AM, Tobias Wagner wrote: > > Hi, > > > > here is the next patch for brainpool curve support in SunEC. > > > > Differences from the first patch: > > > > * Brainpool curves with less than 256 bits are removed. Subsequently, the curve oid check is made more robust to avoid null > > pointer caused Segmentation Faults in memcmp calls. > > > > * Bug JDK-8189594 is fixed. > > > > * Known answer tests for each new curve are added to sun.security.pkcs11.ec.TestECDH. The tests are only executed, if the > > tested provider's name is "SunEC" and the tested provider claims to support the respective curve. For SunEC, these tests are > > executed during sun.security.ec.TestEC. > > > > I decided to add these test vectors to TestECDH to avoid code duplications, as TestECDH is describes exactly the test > > for that kind of test vectors. > > The superclass to TestECDH, TestPKCS11, is also adapted to provide a method to check, whether one particular curve is > > supported. > > > > While the test vectors for the 256, 384 and 512 bit curve are taken from [1], the test vector for brainpoolP320r1 comes from [2]. > > The latter one is a draft version of RFC 6954. > > > > Regards, > > Tobias > > > > [1] https://tools.ietf.org/html/rfc7027#appendix-A > > [2] https://tools.ietf.org/html/draft-merkle-ikev2-ke-brainpool-00#appendix-A.5 > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: jdk_patch_48544-48551.diff Type: application/octet-stream Size: 24791 bytes Desc: not available URL: From sha.jiang at oracle.com Thu Jan 18 04:00:24 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Thu, 18 Jan 2018 12:00:24 +0800 Subject: RFR JDK-8195667: ProblemList PKCS11 tests Secmod/AddTrustedCert.java and tls/TestKeyMaterial.java due to JDK-8180837 Message-ID: <3faf3a55-6615-219a-3b6e-3a1272b6e142@oracle.com> Hi, sun/security/pkcs11/Secmod/AddTrustedCert.java and sun/security/pkcs11/tls/TestKeyMaterial.java should be in ProblemList until JDK-8180837 is resolved. diff -r 7537c762d42d test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt??? Wed Jan 17 18:34:50 2018 -0800 +++ b/test/jdk/ProblemList.txt??? Thu Jan 18 11:58:40 2018 +0800 @@ -254,6 +254,8 @@ ?# jdk_security ?sun/security/pkcs11/ec/TestKeyFactory.java 8026976 generic-all +sun/security/pkcs11/Secmod/AddTrustedCert.java 8180837 generic-all +sun/security/pkcs11/tls/TestKeyMaterial.java 8180837 generic-all ?sun/security/tools/keytool/ListKeychainStore.sh 8156889 macosx-all Best regards, John Jiang From weijun.wang at oracle.com Thu Jan 18 04:15:54 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 18 Jan 2018 12:15:54 +0800 Subject: RFR JDK-8195667: ProblemList PKCS11 tests Secmod/AddTrustedCert.java and tls/TestKeyMaterial.java due to JDK-8180837 In-Reply-To: <3faf3a55-6615-219a-3b6e-3a1272b6e142@oracle.com> References: <3faf3a55-6615-219a-3b6e-3a1272b6e142@oracle.com> Message-ID: <083846E2-DBE2-4B64-BD6D-216186586AF2@oracle.com> Looks fine to me. Thanks Max > On Jan 18, 2018, at 12:00 PM, sha.jiang at oracle.com wrote: > > Hi, > sun/security/pkcs11/Secmod/AddTrustedCert.java and sun/security/pkcs11/tls/TestKeyMaterial.java should be in ProblemList until JDK-8180837 is resolved. > > diff -r 7537c762d42d test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt Wed Jan 17 18:34:50 2018 -0800 > +++ b/test/jdk/ProblemList.txt Thu Jan 18 11:58:40 2018 +0800 > @@ -254,6 +254,8 @@ > # jdk_security > > sun/security/pkcs11/ec/TestKeyFactory.java 8026976 generic-all > +sun/security/pkcs11/Secmod/AddTrustedCert.java 8180837 generic-all > +sun/security/pkcs11/tls/TestKeyMaterial.java 8180837 generic-all > > sun/security/tools/keytool/ListKeychainStore.sh 8156889 macosx-all > > Best regards, > John Jiang > From weijun.wang at oracle.com Thu Jan 18 10:54:36 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 18 Jan 2018 18:54:36 +0800 Subject: RFR [10]: 8194307: KeyStore#getInstance with custom LoadStoreParameter succeeds with invalid password In-Reply-To: <7de363ee-3b96-236c-b87b-05c7141075c3@oracle.com> References: <7de363ee-3b96-236c-b87b-05c7141075c3@oracle.com> Message-ID: <0303C018-07DD-472D-8B54-01178A3C2E9B@oracle.com> The code change looks fine to me. Do you mean that getInstance(File, LoadStoreParameter) should have never been invented because a static password should always be enough for a static file? Thanks Max > On Jan 18, 2018, at 6:36 AM, Sean Mullan wrote: > > Please review this tck-red bug that needs to be fixed in JDK 10. > > bug: https://bugs.openjdk.java.net/browse/JDK-8194307 > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8194307/webrev.00/ > > The current fix is slightly limited in that it doesn't allow the LoadStoreParameter to be passed onto the underlying KeyStore, but that would require an additional API change (an overloaded KeyStore.load method that takes an InputStream and a LoadStoreParameter). Also, none of the existing JDK KeyStore file-based implementations support LoadStoreParameters, so this fix should be sufficient for now or until someone needs or requests that functionality. > > Thanks, > Sean From sean.mullan at oracle.com Thu Jan 18 13:01:54 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 18 Jan 2018 08:01:54 -0500 Subject: RFR [10]: 8194307: KeyStore#getInstance with custom LoadStoreParameter succeeds with invalid password In-Reply-To: <0303C018-07DD-472D-8B54-01178A3C2E9B@oracle.com> References: <7de363ee-3b96-236c-b87b-05c7141075c3@oracle.com> <0303C018-07DD-472D-8B54-01178A3C2E9B@oracle.com> Message-ID: <24dea354-93de-6f8a-53cc-222851e1d1e3@oracle.com> On 1/18/18 5:54 AM, Weijun Wang wrote: > The code change looks fine to me. Thanks. > Do you mean that getInstance(File, LoadStoreParameter) should have never been invented because a static password should always be enough for a static file? Yes. I think we should have added getInstance(File, ProtectionParameter) instead of getInstance(File, LoadStoreParameter) and that would have been more appropriate and sufficient, as it would have still allowed a user to use a CallbackHandler to provide a password, which can be useful. --Sean > > Thanks > Max > >> On Jan 18, 2018, at 6:36 AM, Sean Mullan wrote: >> >> Please review this tck-red bug that needs to be fixed in JDK 10. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8194307 >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8194307/webrev.00/ >> >> The current fix is slightly limited in that it doesn't allow the LoadStoreParameter to be passed onto the underlying KeyStore, but that would require an additional API change (an overloaded KeyStore.load method that takes an InputStream and a LoadStoreParameter). Also, none of the existing JDK KeyStore file-based implementations support LoadStoreParameters, so this fix should be sufficient for now or until someone needs or requests that functionality. >> >> Thanks, >> Sean > From adam.petcher at oracle.com Thu Jan 18 15:26:56 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 18 Jan 2018 10:26:56 -0500 Subject: Code Review Request, JDK-8185576 : New handshake implementation In-Reply-To: References: Message-ID: Disclaimer: I am not a Reviewer. This is not a Review. I looked through all of the code and I didn't find any significant issues. In general, I think this is a nice improvement, and it makes the code easier to understand. Below are a few minor comments: SupportedGroups.java: There are (draft) OIDs for X25519 and X448, in case you want to include them here: https://tools.ietf.org/html/draft-ietf-curdle-pkix-01. Probably no need to worry about this now, though---we will fix all this when we add support for X25519/X448 later. Utilities.java: intent -> indent I found some "TODO" strings in several of the files. I don't know if you intended to leave them in for now. If you are going to leave them in, it would be more clear if you included more information saying why those parts are not done. E.g. "TODO: TLS 1.3" or "TODO: JDK-8888888". Multiple files: concumer -> consumer PredefinedDHParameterSpecs.java: Can we remove all the primes less than 1024 bits? They are all obsolete since the last update release. Also, some of these values are duplicated in sun.security.provider.ParameterCache. On 12/15/2017 11:20 PM, Xuelei Fan wrote: > Hi, > > Please review the change: > ?? http://cr.openjdk.java.net/~xuelei/8185576/webrev.00/ > > This fix is trying to re-org the TLS handshaking implementation in the > SunJSSE provider. > > The handshaking process in TLS 1.3 is lot different from that of TLS > 1.2.? For TLS 1.3 implementation, it is not straightforward any more > to use the existing state machines for TLS 1.2.?? For example, in TLS > specification, the handshake message must be delivered in strict > order. The handshake message order in TLS 1.3 protocol is re-designed > and significant different from that of TLS 1.2.? If we re-use the > state machine for TLS 1.3 and 1.2 and previous versions, the state > machine becomes very complicated and hard to maintain. > > We are consider to simplify the handshake implementation by: > 1. Use difference handshake handler for different TLS versions. > 2. Improved message driven handler for different handshake messages. > > The basic ideas for the simplification look like: > 1. message/even driving handshake processing model. > An actor is a stateless service that is used to consume an input > message, or produce output message, or both. > ?????? message A???????????? message B > ???? --------------> Actor A ------------> Actor B > > 2. immutable actor and centralized states. > Handshake states are represent in context objects (ConnectionContext), > and the context object is passed to each actor.? An actor can update > the state in the context object accordingly.? At the same time, an > actor's behavior may be different for different states. > ????? message A????????????????? message B > ?? --------------> Actor A --------------------------> Actor B > ????? Context?????????????? Context [Actor A updated] > > 3. dynamical actor hierarchical structure > The actor hierarchical structure is flexible and can be dynamically > updated if needed. > > ???? message A?????????????????? message B > ?? --------------> Actor A ----------------------------> ... > ?? (Context)?????? |??? (Context [Actor A updated])?? ^ > ?????????????????? |????????????????????????????????? | > ?????????????????? | Add Actor C between A and B????? | > ?????????????????? | [Optional]?????????????????????? | > ?????????????????? +----------------------------------+ > > ??? > ??? ... ??????? Message C > ??? [ Actor C --------------------------> ] Actor B > ????????????? (Context [Actor B updated] > > 4. consumer and producer > The consumer/producer pattern is used to consume input messages, and > produce output messages. > > ??? message A??????????????????????????????? message B > ? ------------> Consumer A??? Producer B -------------------> > ?? (Context)??? |????????????????? ^? (Context [Consumer A updated]) > ??????????????? |????????????????? | > ??????????????? | Add Producer B?? | > ??????????????? +------------------+ > > > ????????????????? message A > ? Producer A -----------------------> Consumer A --------------------> > ????? |???????? (Context)???????????? ^? (Context [Producer A updated]) > ????? |?????????????????????????????? | > ????? | Add consumer B??????????????? | > ????? +-------------------------------+ > > In this implementation, I removed: > 1. the extended master secret extension > I will add it back soon. > > 2. the KRB5 cipher suite implementation. > I'm not very sure KRB5 cipher suites are still used in practice. > Please let me know if you still using KRB5 cipher suite.? I may not > add these cipher suite back unless it is necessary. > > 3. OCSP stapling > This feature will be added back later. > > As this re-org is for TLS 1.3, so it contains a few draft skeleton for > TLS 1.3.? I will file these parts when doing the TLS 1.3 implementation. > > Please don't be hesitate if you have any questions. > > Regards, > Xuelei From fotisl at ssl.com Thu Jan 18 16:03:44 2018 From: fotisl at ssl.com (Fotis Loukos) Date: Thu, 18 Jan 2018 18:03:44 +0200 Subject: Update mechanism for the upcoming trust store Message-ID: <6cd7d58a-c233-cf45-b80c-2c48fdd5b69e@ssl.com> Hello everybody, I am watching the effort of the community to create a new trust store (JEP319). Based on the description, a trust store will be created which will be shipped with every release. I think that this is a really good step, however I believe that a different approach should be used, namely create an API that will be used to automatically populate the local trust store. If not a full API, even downloading the cacerts file from a secure location would be better. This will help in applying trust decisions in a more efficient way. Past experience has shown us that there have been CAs which unfortunatelly misissued certificates. One of the most famous examples is the Diginotar case. Waiting for the next release of openjdk may leave a lot of people vulnerable to such attacks at CAs. Most major trust store operators have already implemented mechanisms to immediately take trust decisions, until they are integrated in the next release. For example, Mozilla uses OneCRL and Google uses CRLSet. Microsoft has taken a different approach and publishes their whole trust store using the authroot.stl file and specific distrusted certs using the disallowedcerts.stl file. The same approach is being used by Adobe publishing the trust store at http://trustlist.adobe.com/tl12.acrobatsecuritysettings and Cisco publishing the different trust stores under https://www.cisco.com/security/pki/trs/. These trust stores are regularly fetched in order for the operators to be able to respond to CA security incidents as soon as possible. As far as I know, Apple is going to create an API for this. Publishing the whole trust store will also help developers who create validation programs that check against different trust stores. Many sites exist such as the ssl labs tests, that need to have access to a software's trust store, and making an automated mechanism to fetch it would be really useful. Regards, Fotis Loukos -- Fotis Loukos, PhD Director of Security Architecture SSL Corp e: fotisl at ssl.com w: https://www.ssl.com From adam.petcher at oracle.com Thu Jan 18 19:57:55 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 18 Jan 2018 14:57:55 -0500 Subject: [PATCH]: Support for brainpool curves from CurveDB in SunEC In-Reply-To: References: Message-ID: <23aaaf0c-93b1-9fe3-91bd-d622762366cf@oracle.com> I applied your patch and ran some initial tests, and everything looks good so far. I'm running the the regression tests on all platforms, and I'll let you know how it goes. We need a JDK Reviewer to review and approve the code, so I'm hoping someone will volunteer to take a look. For the benefit of the reviewer: I checked all the math parts and everything seems like it should work. Both the point and field arithmetic are done using general-purpose functions that should work for any curve over a prime field. In the case of the field arithmetic, this means the performance is going to be much worse than in other curves. This is unavoidable, though, because Brainpool primes don't have any structure that we can use to optimize the field arithmetic. There are a couple of responses inline below. On 1/17/2018 6:02 PM, Tobias Wagner wrote: > I switched to that repository now. As described on http://openjdk.java.net/contribute/, I was > working with the http://hg.openjdk.java.net/jdk9/jdk9 repository. That page seems to be out of date. I'm working to get it updated. Thanks for letting me know. >> 3) oid.c: I think you can remove the comments that say "XXX bounds >> check" (e.g. line 362). If I am interpreting these comments correctly, >> they are saying that memcmp may read out of bounds, but you fixed that >> problem by using oideql. > I left them in place - my interpretation is, that they are meant for a check > before accessing the *_oids arrays, as C arrays have no implicit check for that. > As long as only oids from CurveDB are used, there would be no problems. > The least significant byte of the requested oid is used as index. If that index > exeeds the defined array length, something odd from the memory there is returned. > At least that's my understynding of C and the comment there. You're interpretation is better than mine, so I agree it's best to leave the comment in. If you wanted to, you could address the issue by comparing against sizeof(array)/sizeof(array[0]), but this is definitely not necessary. >> 4) Is there an existing test that exercises ECDSA with the new curves? >> Maybe there is something in the PKCS11 tests that does this already, but >> I didn't find it. I think we should have an ECDSA test to make sure that >> we didn't forget anything. ECDSA test vectors probably aren't >> necessary---a simple test that signs and verifies using the new curves >> should be sufficient. > Yes, there are tests in TestCurves, which runs through TestEC. TestCurves gets a List > of all supported ECParameterSpec by the Provider and runs ECDSA signatures and verifications > with all of them. The results of all curves are logged in the jtreg report of TestEC. I see. This satisfies my request. Thanks. From weijun.wang at oracle.com Fri Jan 19 08:17:29 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 19 Jan 2018 16:17:29 +0800 Subject: [11] RFR: 8194486: Several krb5 tests failed in Mac. In-Reply-To: References: <1C6FF3C7-7B21-4EC1-AAA1-90735498DB68@oracle.com> <15E00DFA-947C-484F-8DC4-CDDBBF9F703E@oracle.com> Message-ID: Remove principalProperty/TestHosts. Useless. Remove 9999999 in @bug from AcceptPermissions.java. Don't know why it was there. No need to modify BasicProc.java, ReplayCacheTestProc.java, rcache_usemd5.sh. These tests launches sub processes and will not see the system property. Others look fine. Thanks Max > On Jan 17, 2018, at 10:20 PM, Sibabrata Sahoo wrote: > > Hi Max, > > Here is an updated patch: http://cr.openjdk.java.net/~ssahoo/8194486/webrev.01/ > > I found there are few more Test files which need the similar change as applicable to all other Test files in "sun/security/krb5/auto" folder. The change is applied to all Test files except the following 2 Test files inside the same folder. > > ReplayCacheExpunge.java > ReplayCachePrecise.java > > Thanks, > Siba > > -----Original Message----- > From: Weijun Wang > Sent: Thursday, January 11, 2018 11:33 AM > To: Sibabrata Sahoo > Cc: security-dev at openjdk.java.net > Subject: Re: [11] RFR: 8194486: Several krb5 tests failed in Mac. > > > >> On Jan 11, 2018, at 1:30 PM, Sibabrata Sahoo wrote: >> >> I will remove the commented lines. I think, it should be fine, if I do not submit the webrev again. > > Not necessary at all. > > --Max > >> >> Thanks, >> Siba >> >> -----Original Message----- >> From: Weijun Wang >> Sent: Wednesday, January 10, 2018 9:07 PM >> To: Sibabrata Sahoo >> Cc: security-dev at openjdk.java.net >> Subject: Re: [11] RFR: 8194486: Several krb5 tests failed in Mac. >> >> Code change looks fine. I think you can safely remove the lines commented out. If you meant to keep the history, the Mercurial repo already had it. >> >> Thanks >> Max >> >>> On Jan 10, 2018, at 8:58 PM, Sibabrata Sahoo wrote: >>> >>> Hi, >>> >>> Please review the change for the following patch, >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8194486 >>> Webrev: http://cr.openjdk.java.net/~ssahoo/8194486/webrev.00/ >>> >>> Description: >>> There are several failure occurred recently because the name service used by these Tests were not determinable. This patch fixes those issues. >>> >>> >>> Thanks, >>> Siba >> > From adam.petcher at oracle.com Fri Jan 19 15:29:52 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Fri, 19 Jan 2018 10:29:52 -0500 Subject: [PATCH]: Support for brainpool curves from CurveDB in SunEC In-Reply-To: <23aaaf0c-93b1-9fe3-91bd-d622762366cf@oracle.com> References: <23aaaf0c-93b1-9fe3-91bd-d622762366cf@oracle.com> Message-ID: <13597422-a6f5-b573-d60a-d49531d05b47@oracle.com> On 1/18/2018 2:57 PM, Adam Petcher wrote: > I applied your patch and ran some initial tests, and everything looks > good so far. I'm running the the regression tests on all platforms, > and I'll let you know how it goes. > Regression tests passed, and this patch is ready to be reviewed. From ecki at zusammenkunft.net Fri Jan 19 18:28:21 2018 From: ecki at zusammenkunft.net (Bernd) Date: Fri, 19 Jan 2018 19:28:21 +0100 Subject: sunrsasign.jar still searched in java 8? Message-ID: Hello, I noticed that when I strace a "java -version" with 8u152 JRE it searches for sunrsasign.jar which is not found. Is that a compatibility thing or should it not happen? It seems to be in the boot classpath even when the associated classes are in rt.jar: http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/tip/src/share/vm/runtime/os.cpp#l1197 Gruss Bernd -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Jan 19 20:28:09 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 19 Jan 2018 15:28:09 -0500 Subject: sunrsasign.jar still searched in java 8? In-Reply-To: References: Message-ID: <554203c4-e9e3-4c63-b1b1-c74332a9fff5@oracle.com> I believe sunrsasign.jar was removed in JDK 1.5. So it seems like the line below is no longer necessary and should be removed. I have copied hotspot-dev to see if this is a known issue or if I am missing something. --Sean On 1/19/18 1:28 PM, Bernd wrote: > Hello, > > I noticed that when I strace a "java -version" with 8u152 JRE it > searches for sunrsasign.jar which is not found. Is that a compatibility > thing or should it not happen? > > It seems to be in the boot classpath even when the associated classes > are in rt.jar: > > http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/tip/src/share/vm/runtime/os.cpp#l1197 > > Gruss > Bernd > From bradford.wetmore at oracle.com Fri Jan 19 21:21:02 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 19 Jan 2018 13:21:02 -0800 Subject: sunrsasign.jar still searched in java 8? In-Reply-To: References: Message-ID: <0507c4ed-158f-8e47-576f-ebda1c2103f1@oracle.com> Hrm...this was (supposedly) fixed/removed on 2003-10-20 for JDK 5...but I can't find anything in the old SCCS workspace history to indicate it was (old bug id is nowhere to be found). It's been there ever since we migrated to Mercurial. Anyway, it's gone in JDK 9 as a result of the modularity code changes. I've filed: https://bugs.openjdk.java.net/browse/JDK-8195794 Other than a bit of search overhead, I don't think it should cause a problem. This will be a pretty low bug priority bug for sustaining to fix, unless there is something I'm not catching. If someone is looking for a simple bug to learn the process of how to contribute to OpenJDK 8, this is a good candidate. That someone should probably followup with hotspot-dev [1], as this is their code. Brad [1] http://mail.openjdk.java.net/mailman/listinfo/hotspot-dev On 1/19/2018 10:28 AM, Bernd wrote: > Hello, > > I noticed that when I strace a "java -version" with 8u152 JRE it > searches for sunrsasign.jar which is not found. Is that a compatibility > thing or should it not happen? > > It seems to be in the boot classpath even when the associated classes > are in rt.jar: > > http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/tip/src/share/vm/runtime/os.cpp#l1197 > > Gruss > Bernd > From ecki at zusammenkunft.net Fri Jan 19 21:59:57 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 19 Jan 2018 22:59:57 +0100 Subject: [JDK-8195794]: sunrsasign.jar still searched in java 8? In-Reply-To: <0507c4ed-158f-8e47-576f-ebda1c2103f1@oracle.com> References: <0507c4ed-158f-8e47-576f-ebda1c2103f1@oracle.com> Message-ID: <5a626a5e.95811c0a.78dc0.6a4a@mx.google.com> Hello, I agree that it is most likely low priority. I catched it since for some reason I have a Ant Job which is pretty slow on a VM and when stracing it stats this file multiple times and even worse it reads ct.sym (which I dont know yet whats going on). But I dont think this failed stat() causes my slowness ? however it seems to happen repeatingly in some situations. I can try to propose a patch to hotspot-dev and find a sponsor, I just wont have good means to run Tests. The lib/classes/ is also a interesting find on the boot classpath ? Gruss Bernd -- http://bernd.eckenfels.net Von: Bradford Wetmore Gesendet: Freitag, 19. Januar 2018 22:21 An: Bernd; security-dev at openjdk.java.net Betreff: Re: sunrsasign.jar still searched in java 8? Hrm...this was (supposedly) fixed/removed on 2003-10-20 for JDK 5...but I can't find anything in the old SCCS workspace history to indicate it was (old bug id is nowhere to be found). It's been there ever since we migrated to Mercurial. Anyway, it's gone in JDK 9 as a result of the modularity code changes. I've filed: https://bugs.openjdk.java.net/browse/JDK-8195794 Other than a bit of search overhead, I don't think it should cause a problem. This will be a pretty low bug priority bug for sustaining to fix, unless there is something I'm not catching. If someone is looking for a simple bug to learn the process of how to contribute to OpenJDK 8, this is a good candidate. That someone should probably followup with hotspot-dev [1], as this is their code. Brad [1] http://mail.openjdk.java.net/mailman/listinfo/hotspot-dev On 1/19/2018 10:28 AM, Bernd wrote: > Hello, > > I noticed that when I strace a "java -version" with 8u152 JRE it > searches for sunrsasign.jar which is not found. Is that a compatibility > thing or should it not happen? > > It seems to be in the boot classpath even when the associated classes > are in rt.jar: > > http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/tip/src/share/vm/runtime/os.cpp#l1197 > > Gruss > Bernd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradford.wetmore at oracle.com Fri Jan 19 22:25:28 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 19 Jan 2018 14:25:28 -0800 Subject: [JDK-8195794]: sunrsasign.jar still searched in java 8? In-Reply-To: <5a626a5e.95811c0a.78dc0.6a4a@mx.google.com> References: <0507c4ed-158f-8e47-576f-ebda1c2103f1@oracle.com> <5a626a5e.95811c0a.78dc0.6a4a@mx.google.com> Message-ID: <143602b6-1bb3-fa7e-4f6e-0ec15fbc99b8@oracle.com> On 1/19/2018 1:59 PM, Bernd Eckenfels wrote: > I can try to propose a patch to hotspot-dev and find a sponsor, I just > wont have good means to run Tests. If you get an Oracle sponsor, (s)he should be able to put it through the regular hot-spot integration tests they have. > The lib/classes/ is also a interesting find on the boot classpath ? It's been a while since I've been working on a JDK 8 build, but I think lib/classes is the default location for classes in non-image builds. Brad > Gruss > > Bernd > > -- > http://bernd.eckenfels.net > > *Von: *Bradford Wetmore > *Gesendet: *Freitag, 19. Januar 2018 22:21 > *An: *Bernd ; > security-dev at openjdk.java.net > *Betreff: *Re: sunrsasign.jar still searched in java 8? > > Hrm...this was (supposedly) fixed/removed on 2003-10-20 for JDK 5...but > > I can't find anything in the old SCCS workspace history to indicate it > > was (old bug id is nowhere to be found).? It's been there ever since we > > migrated to Mercurial. > > Anyway, it's gone in JDK 9 as a result of the modularity code changes. > > I've filed: > > ???? https://bugs.openjdk.java.net/browse/JDK-8195794 > > Other than a bit of search overhead, I don't think it should cause a > > problem.? This will be a pretty low bug priority bug for sustaining to > > fix, unless there is something I'm not catching. > > If someone is looking for a simple bug to learn the process of how to > > contribute to OpenJDK 8, this is a good candidate.? That someone should > > probably followup with hotspot-dev [1], as this is their code. > > Brad > > [1]? http://mail.openjdk.java.net/mailman/listinfo/hotspot-dev > > On 1/19/2018 10:28 AM, Bernd wrote: > > > Hello, > > > > > > I noticed that when I strace a "java -version" with 8u152 JRE it > > > searches for sunrsasign.jar which is not found. Is that a compatibility > > > thing or should it not happen? > > > > > > It seems to be in the boot classpath even when the associated classes > > > are in rt.jar: > > > > > > > http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/tip/src/share/vm/runtime/os.cpp#l1197 > > > > > > Gruss > > > Bernd > > > > From david.holmes at oracle.com Sat Jan 20 09:19:54 2018 From: david.holmes at oracle.com (David Holmes) Date: Sat, 20 Jan 2018 19:19:54 +1000 Subject: sunrsasign.jar still searched in java 8? In-Reply-To: <554203c4-e9e3-4c63-b1b1-c74332a9fff5@oracle.com> References: <554203c4-e9e3-4c63-b1b1-c74332a9fff5@oracle.com> Message-ID: <35115f6f-c041-2179-fa60-eb3ccd25f561@oracle.com> On 20/01/2018 6:28 AM, Sean Mullan wrote: > I believe sunrsasign.jar was removed in JDK 1.5. So it seems like the > line below is no longer necessary and should be removed. I have copied > hotspot-dev to see if this is a known issue or if I am missing something. As per Brad's filing of https://bugs.openjdk.java.net/browse/JDK-8195794 this was claimed to have been done in another bug report, but it seems it got lost somewhere. Also see: https://bugs.openjdk.java.net/browse/JDK-7036474 which seems fixed in 8+ but not 7u. David > --Sean > > On 1/19/18 1:28 PM, Bernd wrote: >> Hello, >> >> I noticed that when I strace a "java -version" with 8u152 JRE it >> searches for sunrsasign.jar which is not found. Is that a >> compatibility thing or should it not happen? >> >> It seems to be in the boot classpath even when the associated classes >> are in rt.jar: >> >> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/tip/src/share/vm/runtime/os.cpp#l1197 >> >> >> Gruss >> Bernd >> From bradford.wetmore at oracle.com Sun Jan 21 16:28:16 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Sun, 21 Jan 2018 08:28:16 -0800 Subject: sunrsasign.jar still searched in java 8? In-Reply-To: <35115f6f-c041-2179-fa60-eb3ccd25f561@oracle.com> References: <554203c4-e9e3-4c63-b1b1-c74332a9fff5@oracle.com> <35115f6f-c041-2179-fa60-eb3ccd25f561@oracle.com> Message-ID: <4c12683c-1a20-bfaa-75df-a60125740199@oracle.com> JDK-7036474 is still open and is in another part of the code. I've linked them so maybe if one gets fixed, maybe the other will also. (*crosses fingers*) Brad On 1/20/2018 1:19 AM, David Holmes wrote: > On 20/01/2018 6:28 AM, Sean Mullan wrote: >> I believe sunrsasign.jar was removed in JDK 1.5. So it seems like the >> line below is no longer necessary and should be removed. I have copied >> hotspot-dev to see if this is a known issue or if I am missing something. > > As per Brad's filing of > > https://bugs.openjdk.java.net/browse/JDK-8195794 > > this was claimed to have been done in another bug report, but it seems > it got lost somewhere. > > Also see: > > https://bugs.openjdk.java.net/browse/JDK-7036474 > > which seems fixed in 8+ but not 7u. > > David > >> --Sean >> >> On 1/19/18 1:28 PM, Bernd wrote: >>> Hello, >>> >>> I noticed that when I strace a "java -version" with 8u152 JRE it >>> searches for sunrsasign.jar which is not found. Is that a >>> compatibility thing or should it not happen? >>> >>> It seems to be in the boot classpath even when the associated classes >>> are in rt.jar: >>> >>> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/tip/src/share/vm/runtime/os.cpp#l1197 >>> >>> >>> Gruss >>> Bernd >>> From xuelei.fan at oracle.com Mon Jan 22 23:26:17 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 22 Jan 2018 15:26:17 -0800 Subject: Code Review Request, JDK-8185576 : New handshake implementation In-Reply-To: References: Message-ID: Thanks for the code review. I will wrap up the updates in the next webrev. I plan to close the code review for the new handshaking implementation by the end of January (Jan. 31, 2018). Please let me know if you need more time. Thanks, Xuelei On 1/18/2018 7:26 AM, Adam Petcher wrote: > Disclaimer: I am not a Reviewer. This is not a Review. > > I looked through all of the code and I didn't find any significant > issues. In general, I think this is a nice improvement, and it makes the > code easier to understand. Below are a few minor comments: > > SupportedGroups.java: There are (draft) OIDs for X25519 and X448, in > case you want to include them here: > https://tools.ietf.org/html/draft-ietf-curdle-pkix-01. Probably no need > to worry about this now, though---we will fix all this when we add > support for X25519/X448 later. > > Utilities.java: intent -> indent > > I found some "TODO" strings in several of the files. I don't know if you > intended to leave them in for now. If you are going to leave them in, it > would be more clear if you included more information saying why those > parts are not done. E.g. "TODO: TLS 1.3" or "TODO: JDK-8888888". > > Multiple files: concumer -> consumer > > PredefinedDHParameterSpecs.java: Can we remove all the primes less than > 1024 bits? They are all obsolete since the last update release. Also, > some of these values are duplicated in > sun.security.provider.ParameterCache. > > > On 12/15/2017 11:20 PM, Xuelei Fan wrote: >> Hi, >> >> Please review the change: >> ?? http://cr.openjdk.java.net/~xuelei/8185576/webrev.00/ >> >> This fix is trying to re-org the TLS handshaking implementation in the >> SunJSSE provider. >> >> The handshaking process in TLS 1.3 is lot different from that of TLS >> 1.2.? For TLS 1.3 implementation, it is not straightforward any more >> to use the existing state machines for TLS 1.2.?? For example, in TLS >> specification, the handshake message must be delivered in strict >> order. The handshake message order in TLS 1.3 protocol is re-designed >> and significant different from that of TLS 1.2.? If we re-use the >> state machine for TLS 1.3 and 1.2 and previous versions, the state >> machine becomes very complicated and hard to maintain. >> >> We are consider to simplify the handshake implementation by: >> 1. Use difference handshake handler for different TLS versions. >> 2. Improved message driven handler for different handshake messages. >> >> The basic ideas for the simplification look like: >> 1. message/even driving handshake processing model. >> An actor is a stateless service that is used to consume an input >> message, or produce output message, or both. >> ?????? message A???????????? message B >> ???? --------------> Actor A ------------> Actor B >> >> 2. immutable actor and centralized states. >> Handshake states are represent in context objects (ConnectionContext), >> and the context object is passed to each actor.? An actor can update >> the state in the context object accordingly.? At the same time, an >> actor's behavior may be different for different states. >> ????? message A????????????????? message B >> ?? --------------> Actor A --------------------------> Actor B >> ????? Context?????????????? Context [Actor A updated] >> >> 3. dynamical actor hierarchical structure >> The actor hierarchical structure is flexible and can be dynamically >> updated if needed. >> >> ???? message A?????????????????? message B >> ?? --------------> Actor A ----------------------------> ... >> ?? (Context)?????? |??? (Context [Actor A updated])?? ^ >> ?????????????????? |????????????????????????????????? | >> ?????????????????? | Add Actor C between A and B????? | >> ?????????????????? | [Optional]?????????????????????? | >> ?????????????????? +----------------------------------+ >> >> ??? >> ??? ... ??????? Message C >> ??? [ Actor C --------------------------> ] Actor B >> ????????????? (Context [Actor B updated] >> >> 4. consumer and producer >> The consumer/producer pattern is used to consume input messages, and >> produce output messages. >> >> ??? message A??????????????????????????????? message B >> ? ------------> Consumer A??? Producer B -------------------> >> ?? (Context)??? |????????????????? ^? (Context [Consumer A updated]) >> ??????????????? |????????????????? | >> ??????????????? | Add Producer B?? | >> ??????????????? +------------------+ >> >> >> ????????????????? message A >> ? Producer A -----------------------> Consumer A --------------------> >> ????? |???????? (Context)???????????? ^? (Context [Producer A updated]) >> ????? |?????????????????????????????? | >> ????? | Add consumer B??????????????? | >> ????? +-------------------------------+ >> >> In this implementation, I removed: >> 1. the extended master secret extension >> I will add it back soon. >> >> 2. the KRB5 cipher suite implementation. >> I'm not very sure KRB5 cipher suites are still used in practice. >> Please let me know if you still using KRB5 cipher suite.? I may not >> add these cipher suite back unless it is necessary. >> >> 3. OCSP stapling >> This feature will be added back later. >> >> As this re-org is for TLS 1.3, so it contains a few draft skeleton for >> TLS 1.3.? I will file these parts when doing the TLS 1.3 implementation. >> >> Please don't be hesitate if you have any questions. >> >> Regards, >> Xuelei > From sha.jiang at oracle.com Tue Jan 23 08:27:08 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Tue, 23 Jan 2018 16:27:08 +0800 Subject: RFR JDK-8186098: sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failed due to libnss3 version cannot be parsed Message-ID: Hi, With some NSS libs, PKCS11 tests failed to determine the lib version. This patch improves the approach on parsing version from lib files. Webrev: http://cr.openjdk.java.net/~jjiang/8186098/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8186098 Best regards, John Jiang From weijun.wang at oracle.com Tue Jan 23 09:49:45 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 23 Jan 2018 17:49:45 +0800 Subject: RFR JDK-8186098: sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failed due to libnss3 version cannot be parsed In-Reply-To: References: Message-ID: <55E6D6B3-E0EE-42CC-97AE-5D909DA213A4@oracle.com> Can you show us why the new code works? What does "s" looks like? Thanks Max > On Jan 23, 2018, at 4:27 PM, sha.jiang at oracle.com wrote: > > Hi, > With some NSS libs, PKCS11 tests failed to determine the lib version. > This patch improves the approach on parsing version from lib files. > > Webrev: http://cr.openjdk.java.net/~jjiang/8186098/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8186098 > > Best regards, > John Jiang > From xuelei.fan at oracle.com Tue Jan 23 15:44:31 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 23 Jan 2018 07:44:31 -0800 Subject: RFR JDK-8186098: sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failed due to libnss3 version cannot be parsed In-Reply-To: References: Message-ID: Looks fine to me. You may want to add a comment about the format of the lib names and versions. Xuelei On 1/23/2018 12:27 AM, sha.jiang at oracle.com wrote: > Hi, > With some NSS libs, PKCS11 tests failed to determine the lib version. > This patch improves the approach on parsing version from lib files. > > Webrev: http://cr.openjdk.java.net/~jjiang/8186098/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8186098 > > Best regards, > John Jiang > From sean.mullan at oracle.com Tue Jan 23 19:12:21 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 23 Jan 2018 14:12:21 -0500 Subject: Update mechanism for the upcoming trust store In-Reply-To: <6cd7d58a-c233-cf45-b80c-2c48fdd5b69e@ssl.com> References: <6cd7d58a-c233-cf45-b80c-2c48fdd5b69e@ssl.com> Message-ID: Hi Fotis, This is an interesting issue and I agree it is important. From your post it seems that each implementation has come up with a different mechanism for solving this problem, which is unfortunate - it would be more ideal if we could converge on a standard mechanism for addressing it. There certainly seems that there is a need for that. Do you know if anything is being discussed along those lines? You may not be aware, but the JDK does currently support a mechanism for blacklisting certificates. The lib/security/blacklisted.certs file contains a list of the fingerprints of certificates that are explicitly distrusted. If a root was compromised and added to this file it would no longer be trusted. However, currently there is no mechanism in OpenJDK to dynamically update that file. While I think there is merit in implementing something like that, many challenges would need to be addressed as part of that, for example, where and how does this file get updated, how is it verified, etc. Thanks, Sean On 1/18/18 11:03 AM, Fotis Loukos wrote: > Hello everybody, > I am watching the effort of the community to create a new trust store > (JEP319). Based on the description, a trust store will be created which > will be shipped with every release. > I think that this is a really good step, however I believe that a > different approach should be used, namely create an API that will be > used to automatically populate the local trust store. If not a full API, > even downloading the cacerts file from a secure location would be better. > This will help in applying trust decisions in a more efficient way. Past > experience has shown us that there have been CAs which unfortunatelly > misissued certificates. One of the most famous examples is the Diginotar > case. Waiting for the next release of openjdk may leave a lot of people > vulnerable to such attacks at CAs. Most major trust store operators have > already implemented mechanisms to immediately take trust decisions, > until they are integrated in the next release. For example, Mozilla uses > OneCRL and Google uses CRLSet. Microsoft has taken a different approach > and publishes their whole trust store using the authroot.stl file and > specific distrusted certs using the disallowedcerts.stl file. The same > approach is being used by Adobe publishing the trust store at > http://trustlist.adobe.com/tl12.acrobatsecuritysettings and Cisco > publishing the different trust stores under > https://www.cisco.com/security/pki/trs/. These trust stores are > regularly fetched in order for the operators to be able to respond to CA > security incidents as soon as possible. As far as I know, Apple is going > to create an API for this. > Publishing the whole trust store will also help developers who create > validation programs that check against different trust stores. Many > sites exist such as the ssl labs tests, that need to have access to a > software's trust store, and making an automated mechanism to fetch it > would be really useful. > > Regards, > Fotis Loukos > From sha.jiang at oracle.com Wed Jan 24 03:28:15 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 24 Jan 2018 11:28:15 +0800 Subject: RFR JDK-8186098: sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failed due to libnss3 version cannot be parsed In-Reply-To: <55E6D6B3-E0EE-42CC-97AE-5D909DA213A4@oracle.com> References: <55E6D6B3-E0EE-42CC-97AE-5D909DA213A4@oracle.com> Message-ID: <2f18570c-85b2-2d1e-f17d-6c3791d093bd@oracle.com> Hi Max, On 23/01/2018 17:49, Weijun Wang wrote: > Can you show us why the new code works? The test assumes that nss3 lib contains a string likes: $Header: NSS version.number, e.g. "$Header: NSS 3.16.2" or Version: NSS version.number, e.g. "Version: NSS 3.34.1" But the current test expects that the version.number is followed by a space immediately. For example, "$Header: NSS 3.16.2 Basic". So, it tries to locate the next space index for parsing the version. Unfortunately, that assumption is not true on some NSS builds. For example, "Version: NSS 3.34.1 ?". This fix just cares the chars, such as "." or "0-9", after "$Header: NSS " or "Version: NSS ". If a char, which is not in the specific char set ("." or "0-9"), is met, that means the version has been extracted. > What does "s" looks like? The followings are some snippets of nss3 lib from different NSS builds. 1. NSS 3.16.2 on macosx Content-Length: %u From weijun.wang at oracle.com Wed Jan 24 04:20:23 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 24 Jan 2018 12:20:23 +0800 Subject: RFR JDK-8186098: sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failed due to libnss3 version cannot be parsed In-Reply-To: <2f18570c-85b2-2d1e-f17d-6c3791d093bd@oracle.com> References: <55E6D6B3-E0EE-42CC-97AE-5D909DA213A4@oracle.com> <2f18570c-85b2-2d1e-f17d-6c3791d093bd@oracle.com> Message-ID: <98D7A062-28AA-4296-A513-1336A79CC420@oracle.com> > On Jan 24, 2018, at 11:28 AM, sha.jiang at oracle.com wrote: > > Hi Max, > > On 23/01/2018 17:49, Weijun Wang wrote: >> Can you show us why the new code works? > The test assumes that nss3 lib contains a string likes: > $Header: NSS version.number, e.g. "$Header: NSS 3.16.2" > or > Version: NSS version.number, e.g. "Version: NSS 3.34.1" > > But the current test expects that the version.number is followed by a space immediately. For example, "$Header: NSS 3.16.2 Basic". So, it tries to locate the next space index for parsing the version. > Unfortunately, that assumption is not true on some NSS builds. For example, "Version: NSS 3.34.1 ?". I see. BTW, the byte-to-string conversion looks a little strange as the data is pure binary. Maybe you can use StandardCharsets.US_ASCII to be safe. --Max > This fix just cares the chars, such as "." or "0-9", after "$Header: NSS " or "Version: NSS ". If a char, which is not in the specific char set ("." or "0-9"), is met, that means the version has been extracted. > >> What does "s" looks like? > The followings are some snippets of nss3 lib from different NSS builds. > 1. NSS 3.16.2 on macosx > Content-Length: %u From fotisl at ssl.com Wed Jan 24 10:39:37 2018 From: fotisl at ssl.com (Fotis Loukos) Date: Wed, 24 Jan 2018 12:39:37 +0200 Subject: Update mechanism for the upcoming trust store In-Reply-To: References: <6cd7d58a-c233-cf45-b80c-2c48fdd5b69e@ssl.com> Message-ID: <6254fadc-06f0-c96a-0abd-69021cbd341d@ssl.com> Hello Sean, On 23/01/2018 09:12 ??, Sean Mullan wrote: > Hi Fotis, > > This is an interesting issue and I agree it is important. From your post > it seems that each implementation has come up with a different mechanism > for solving this problem, which is unfortunate - it would be more ideal > if we could converge on a standard mechanism for addressing it. There > certainly seems that there is a need for that. Do you know if anything > is being discussed along those lines? There is RFC5914 which describes the Trust Anchor Format. It can be used to create a trust store by populating a TrustAnchorList SEQUENCE. I am not sure if there is some standard implementation in Java, but it shouldn't be difficult to implement something like this. In order to be able to verify the data, I think that the best practice is to encapsulate and sign everything using the CMS/PKCS#7 format, as described in RFC5652. The signing certificate could chain to a CA which is built in the JDK. Thus, you will only have to include a single certificate in the JDK which will be used to verify the whole trust store. Of course, after parsing it, it can be converted to some other format. I would suggest to keep all the information in the TrustAnchorInfo structure for every CA in order to be able to support other extensions in the future, such as EV certificates. > > You may not be aware, but the JDK does currently support a mechanism for > blacklisting certificates. The lib/security/blacklisted.certs file > contains a list of the fingerprints of certificates that are explicitly > distrusted. If a root was compromised and added to this file it would no > longer be trusted. My biggest concern is what you describe below, the dynamic update. > > However, currently there is no mechanism in OpenJDK to dynamically > update that file. While I think there is merit in implementing something > like that, many challenges would need to be addressed as part of that, > for example, where and how does this file get updated, how is it > verified, etc. The verification step can be implemented as described above. I think that the update step requires some design, but I don't think it is that difficult. For example, a naive algorithm such as every Monday plus a random number of days/hours/minutes in order to avoid heavy traffic during the update period would be good for starters. As a first step to try a new format, you could even fetch it once during installation and provide a means for the user to update it manually. Regards, Fotis Loukos > > Thanks, > Sean > > On 1/18/18 11:03 AM, Fotis Loukos wrote: >> Hello everybody, >> I am watching the effort of the community to create a new trust store >> (JEP319). Based on the description, a trust store will be created which >> will be shipped with every release. >> I think that this is a really good step, however I believe that a >> different approach should be used, namely create an API that will be >> used to automatically populate the local trust store. If not a full API, >> even downloading the cacerts file from a secure location would be better. >> This will help in applying trust decisions in a more efficient way. Past >> experience has shown us that there have been CAs which unfortunatelly >> misissued certificates. One of the most famous examples is the Diginotar >> case. Waiting for the next release of openjdk may leave a lot of people >> vulnerable to such attacks at CAs. Most major trust store operators have >> already implemented mechanisms to immediately take trust decisions, >> until they are integrated in the next release. For example, Mozilla uses >> OneCRL and Google uses CRLSet. Microsoft has taken a different approach >> and publishes their whole trust store using the authroot.stl file and >> specific distrusted certs using the disallowedcerts.stl file. The same >> approach is being used by Adobe publishing the trust store at >> http://trustlist.adobe.com/tl12.acrobatsecuritysettings and Cisco >> publishing the different trust stores under >> https://www.cisco.com/security/pki/trs/. These trust stores are >> regularly fetched in order for the operators to be able to respond to CA >> security incidents as soon as possible. As far as I know, Apple is going >> to create an API for this. >> Publishing the whole trust store will also help developers who create >> validation programs that check against different trust stores. Many >> sites exist such as the ssl labs tests, that need to have access to a >> software's trust store, and making an automated mechanism to fetch it >> would be really useful. >> >> Regards, >> Fotis Loukos >> -- Fotis Loukos, PhD Director of Security Architecture SSL Corp e: fotisl at ssl.com w: https://www.ssl.com From tomas at primekey.se Wed Jan 24 10:39:52 2018 From: tomas at primekey.se (Tomas Gustavsson) Date: Wed, 24 Jan 2018 11:39:52 +0100 Subject: contribute to the OpenJDK security group In-Reply-To: <0100016105867b86-27ab95e1-97ea-4118-bda9-1680dadcf318-000000@email.amazonses.com> References: <0100016101db8f7d-19737975-67eb-4dab-ba94-c68d46746ab9-000000@email.amazonses.com> <0100016105867b86-27ab95e1-97ea-4118-bda9-1680dadcf318-000000@email.amazonses.com> Message-ID: <44867b0b-ecde-8037-f48b-b3aa51c44d64@primekey.se> Sorry for jumping in :-) Imho the P11 layer always needs attention. To work properly we're relying on some patches, where parts was recently merged into OpenJDK. We just started testing the Amazon CloudHSM, and that requires changes to SunPKCS11 as well to work. Not always bad in SunPKCS11 as some P11 libraries out there do strange non-conforming stuff, but there's room for more flexibility nevertheless. Cheers, Tomas On 2018-01-17 20:09, Leo Grove wrote: > Thanks Sean, I've filled out the OCA and sent it in. I'll take a gander > around after reading up on the link you posted and see where we might be > able to jump in and assist. > > Leo > > > On 1/17/2018 7:53 AM, Sean Mullan wrote: >> Hi Leo, >> >> Thanks for the offer to help and contribute! I would suggest you start >> by reading the OpenJDK contribution page (if you have not done so >> already): >> >> http://openjdk.java.net/contribute/ >> >> which has some tips and other helpful advice. You will also need to >> sign an OCA (Oracle Contributor Agreement) before we can accept any >> contributions. >> >> Thanks, >> Sean >> >> On 1/16/18 9:03 PM, Leo Grove wrote: >>> Hello Everyone, >>> >>> I'd like to introduce myself. I'm Leo Grove, founder of SSL.com and >>> also Java Certified Programmer ('98). Although I'm not so much into >>> coding these days, I'm always looking for ways to contribute to >>> internet security and the public WebPKI. We do have some very sharp >>> java developers that specialize in PKI and certs, so if there is >>> something you need a hand with (or a pair of eyeballs on), please let >>> me know, thanks. >> >> > From aph at redhat.com Wed Jan 24 11:06:07 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 24 Jan 2018 11:06:07 +0000 Subject: contribute to the OpenJDK security group In-Reply-To: <44867b0b-ecde-8037-f48b-b3aa51c44d64@primekey.se> References: <0100016101db8f7d-19737975-67eb-4dab-ba94-c68d46746ab9-000000@email.amazonses.com> <0100016105867b86-27ab95e1-97ea-4118-bda9-1680dadcf318-000000@email.amazonses.com> <44867b0b-ecde-8037-f48b-b3aa51c44d64@primekey.se> Message-ID: <344a2d12-9560-e407-39e5-1ec0ed43b285@redhat.com> On 24/01/18 10:39, Tomas Gustavsson wrote: > Imho the P11 layer always needs attention. To work properly we're > relying on some patches, where parts was recently merged into OpenJDK. > We just started testing the Amazon CloudHSM, and that requires changes > to SunPKCS11 as well to work. Not always bad in SunPKCS11 as some P11 > libraries out there do strange non-conforming stuff, but there's room > for more flexibility nevertheless. Martin Balao has been heavily reworking this layer because it leaks native memory. I'll let him fill you in on the details. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From weijun.wang at oracle.com Thu Jan 25 03:53:16 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 25 Jan 2018 11:53:16 +0800 Subject: RFR 8177398: Exclude dot files ending with .conf from krb5.conf's includedir Message-ID: <6EF11571-CF25-4A7B-89EE-A856F61200B7@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8177398/webrev.00/ Dotfiles will not be included in "includedir" of krb5.conf. Thanks Max From sha.jiang at oracle.com Thu Jan 25 05:52:57 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Thu, 25 Jan 2018 13:52:57 +0800 Subject: RFR JDK-8186098: sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failed due to libnss3 version cannot be parsed In-Reply-To: <98D7A062-28AA-4296-A513-1336A79CC420@oracle.com> References: <55E6D6B3-E0EE-42CC-97AE-5D909DA213A4@oracle.com> <2f18570c-85b2-2d1e-f17d-6c3791d093bd@oracle.com> <98D7A062-28AA-4296-A513-1336A79CC420@oracle.com> Message-ID: <339b96e2-5ffd-9c22-e1c5-2644bc84a7c0@oracle.com> Hi Max, Xuelei, Please review this updated patch: http://cr.openjdk.java.net/~jjiang/8186098/webrev.01/ Both of your suggestions are addressed. Best regards, John Jiang On 24/01/2018 12:20, Weijun Wang wrote: > >> On Jan 24, 2018, at 11:28 AM, sha.jiang at oracle.com wrote: >> >> Hi Max, >> >> On 23/01/2018 17:49, Weijun Wang wrote: >>> Can you show us why the new code works? >> The test assumes that nss3 lib contains a string likes: >> $Header: NSS version.number, e.g. "$Header: NSS 3.16.2" >> or >> Version: NSS version.number, e.g. "Version: NSS 3.34.1" >> >> But the current test expects that the version.number is followed by a space immediately. For example, "$Header: NSS 3.16.2 Basic". So, it tries to locate the next space index for parsing the version. >> Unfortunately, that assumption is not true on some NSS builds. For example, "Version: NSS 3.34.1 ?". > I see. > > BTW, the byte-to-string conversion looks a little strange as the data is pure binary. Maybe you can use StandardCharsets.US_ASCII to be safe. > > --Max > >> This fix just cares the chars, such as "." or "0-9", after "$Header: NSS " or "Version: NSS ". If a char, which is not in the specific char set ("." or "0-9"), is met, that means the version has been extracted. >> >>> What does "s" looks like? >> The followings are some snippets of nss3 lib from different NSS builds. >> 1. NSS 3.16.2 on macosx >> Content-Length: %u > From weijun.wang at oracle.com Thu Jan 25 07:14:54 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 25 Jan 2018 15:14:54 +0800 Subject: RFR JDK-8186098: sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failed due to libnss3 version cannot be parsed In-Reply-To: <339b96e2-5ffd-9c22-e1c5-2644bc84a7c0@oracle.com> References: <55E6D6B3-E0EE-42CC-97AE-5D909DA213A4@oracle.com> <2f18570c-85b2-2d1e-f17d-6c3791d093bd@oracle.com> <98D7A062-28AA-4296-A513-1336A79CC420@oracle.com> <339b96e2-5ffd-9c22-e1c5-2644bc84a7c0@oracle.com> Message-ID: The change looks fine. Thanks Max > On Jan 25, 2018, at 1:52 PM, sha.jiang at oracle.com wrote: > > Hi Max, Xuelei, > Please review this updated patch: http://cr.openjdk.java.net/~jjiang/8186098/webrev.01/ > Both of your suggestions are addressed. > > Best regards, > John Jiang > > On 24/01/2018 12:20, Weijun Wang wrote: >> >>> On Jan 24, 2018, at 11:28 AM, sha.jiang at oracle.com wrote: >>> >>> Hi Max, >>> >>> On 23/01/2018 17:49, Weijun Wang wrote: >>>> Can you show us why the new code works? >>> The test assumes that nss3 lib contains a string likes: >>> $Header: NSS version.number, e.g. "$Header: NSS 3.16.2" >>> or >>> Version: NSS version.number, e.g. "Version: NSS 3.34.1" >>> >>> But the current test expects that the version.number is followed by a space immediately. For example, "$Header: NSS 3.16.2 Basic". So, it tries to locate the next space index for parsing the version. >>> Unfortunately, that assumption is not true on some NSS builds. For example, "Version: NSS 3.34.1 ?". >> I see. >> >> BTW, the byte-to-string conversion looks a little strange as the data is pure binary. Maybe you can use StandardCharsets.US_ASCII to be safe. >> >> --Max >> >>> This fix just cares the chars, such as "." or "0-9", after "$Header: NSS " or "Version: NSS ". If a char, which is not in the specific char set ("." or "0-9"), is met, that means the version has been extracted. >>> >>>> What does "s" looks like? >>> The followings are some snippets of nss3 lib from different NSS builds. >>> 1. NSS 3.16.2 on macosx >>> Content-Length: %u >> > From xuelei.fan at oracle.com Thu Jan 25 16:22:25 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 25 Jan 2018 08:22:25 -0800 Subject: RFR JDK-8186098: sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failed due to libnss3 version cannot be parsed In-Reply-To: References: <55E6D6B3-E0EE-42CC-97AE-5D909DA213A4@oracle.com> <2f18570c-85b2-2d1e-f17d-6c3791d093bd@oracle.com> <98D7A062-28AA-4296-A513-1336A79CC420@oracle.com> <339b96e2-5ffd-9c22-e1c5-2644bc84a7c0@oracle.com> Message-ID: On 1/24/2018 11:14 PM, Weijun Wang wrote: > The change looks fine. > +1 Xuelei > Thanks > Max > >> On Jan 25, 2018, at 1:52 PM, sha.jiang at oracle.com wrote: >> >> Hi Max, Xuelei, >> Please review this updated patch: http://cr.openjdk.java.net/~jjiang/8186098/webrev.01/ >> Both of your suggestions are addressed. >> >> Best regards, >> John Jiang >> >> On 24/01/2018 12:20, Weijun Wang wrote: >>> >>>> On Jan 24, 2018, at 11:28 AM, sha.jiang at oracle.com wrote: >>>> >>>> Hi Max, >>>> >>>> On 23/01/2018 17:49, Weijun Wang wrote: >>>>> Can you show us why the new code works? >>>> The test assumes that nss3 lib contains a string likes: >>>> $Header: NSS version.number, e.g. "$Header: NSS 3.16.2" >>>> or >>>> Version: NSS version.number, e.g. "Version: NSS 3.34.1" >>>> >>>> But the current test expects that the version.number is followed by a space immediately. For example, "$Header: NSS 3.16.2 Basic". So, it tries to locate the next space index for parsing the version. >>>> Unfortunately, that assumption is not true on some NSS builds. For example, "Version: NSS 3.34.1 ?". >>> I see. >>> >>> BTW, the byte-to-string conversion looks a little strange as the data is pure binary. Maybe you can use StandardCharsets.US_ASCII to be safe. >>> >>> --Max >>> >>>> This fix just cares the chars, such as "." or "0-9", after "$Header: NSS " or "Version: NSS ". If a char, which is not in the specific char set ("." or "0-9"), is met, that means the version has been extracted. >>>> >>>>> What does "s" looks like? >>>> The followings are some snippets of nss3 lib from different NSS builds. >>>> 1. NSS 3.16.2 on macosx >>>> Content-Length: %u >>> >> > From jamil.j.nimeh at oracle.com Thu Jan 25 17:20:23 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 25 Jan 2018 09:20:23 -0800 Subject: Proposal: ChaCha20 and ChaCha20-Poly1305 Cipher implementations Message-ID: <8a16b9e2-0db1-5c5d-2386-1194ce01abff@oracle.com> Hello all, This is a proposal to introduce the ChaCha20 and ChaCha20-Poly1305 cipher implementations into JDK. At a high level, the plan is to include both ChaCha20-Poly1305 and the base ChaCha20 stream cipher into JDK as part of the SunJCE provider initially, and then add TLS cipher suites as a follow-on feature. Both algorithms will be CipherSpi implementations and will generally conform to the details of that API. I will discuss below some of the details such as which flavors of init are supported, etc. * Instantiation o For ChaCha20 and ChaCha20-Poly1305, the simple name will suffice: either "ChaCha20" for the basic stream cipher or "ChaCha20-Poly1305" for AEAD mode will work. You may however use the 3-element transform "ChaCha20/None/NoPadding" and "ChaCha20-Poly1305/None/NoPadding". Any other type of transformation string will cause NoSuchAlgorithmException to be thrown. * Initialization o All three engineInit methods in the CipherSpi API will be supported. Keys provided through the various Cipher init methods should have the algorithm String "ChaCha20" applied to it (case-insensitive). o For init/engineInit methods that take an AlgorithmParameterSpec, ChaCha20 and ChaCha20-Poly1305 use different APS classes. + ChaCha20 will have a new ChaCha20ParameterSpec which takes a nonce (byte[]) and a counter (int). This class will have getter methods to return those values if desired (getNonce() and getBlockCounter(), respectively). + ChaCha20-Poly1305 will use IvParameterSpec to provide the nonce. The primary reason this is being used instead of ChaCha20ParameterSpec is in order to make backporting to earlier JDK releases possible. Also there's no need to set a counter value, so it would end up being an ignored parameter. + For init calls where no AlgorithmParameterSpec or AlgorithmParameter has been provided, a random nonce will be set at initialization time. the counter value will be set to 1. The random nonce can be retrieved using the getIV() Cipher method or by using the getParameters() call and parsing the output from AlgorithmParameters.getEncoded(). * Use o ChaCha20 encrypt and decrypt operations would work as any stream cipher would - as many bytes of ciphertext are returned from an encrypt function as plaintext bytes submitted (and vice versa for decrypt). o ChaCha20-Poly1305 operates in a similar fashion to other AEAD ciphers. For encryption operations, as many bytes are returned as input submitted with the exception of the doFinal calls, which would return any remaining ciphertext plus an extra 16 bytes for the tag. For decryption, individual update calls return no plaintext. The plaintext is returned only after the last bytes of ciphertext are provided, the authentication tag is provided, and the doFinal call is made. Once the authentication tag has been verified then the plaintext will be returned. o The getOutputSize call will return the following + ChaCha20: Same value as the submitted input size + ChaCha20-Poly1305: For encrypt, the returned size will be the input size + 16 bytes for the tag. For decryption, the returned size will be input length - 16 bytes, or zero (whichever is larger). o Wrap and Unwrap: I have not been able to find a standardized wrap/unwrap format for ChaCha20 similar to RFC 3394 for AES. Right now the wrap() and unwrap() methods just take the encoding of the key to be wrapped and encrypts or decrypts them respectively. If anyone is aware of a wrapping format for ChaCha20 please let me know. My searches have so far come up empty. o Counter rollover protection will be enforced. For ChaCha20 and ChaCha20-Poly1305, the cipher will cease to process input once the 32-bit counter space has been exhausted. o Nonce reuse protection: For both ChaCha20 and ChaCha20-Poly1305: we will not allow reuse of the same nonce between two consecutive init() operations. * KeyGenerator o There will be a new KeyGenerator algorithm called "ChaCha20" which will create a 32-byte key suitable for use in either ChaCha20 or ChaCha20-Poly1305 cipher instances. If you use forms of the KeyGenerator.init() that take a variable key length and you do something other than 32 bytes then you'll have InvalidParameterException thrown at you. o If you use a form of the init that takes an AlgorithmParameterSpec it will throw InvalidAlgorithmParameterSpecException. This is similar in behavior to other KeyGenerators like the HmacSHA-2 family, ARCFOUR, RC2, and AES. * Other TBD/in-progress items o ChaCha20Parameters: This will be added to com.sun.crypto.provider and will be able to provide an encoding for parameters used in ChaCha20 and ChaCha20-Poly1305 ciphers. + For ChaCha20-Poly1305, the default encoded form of the AlgorithmParameters will be the AEADChaCha20Poly1305Nonce from RFC 8103 section 3 (basically the nonce as an ASN.1 OCTET STRING of 12 bytes). + For ChaCha20 I have not been able to find a standardized encoding for ChaCha20 parameters. For lack of an official format I currently have it encoding the parameters as a SEQUENCE of an OCTET STRING (the nonce) and an INTEGER (the counter starting value). # Question: If a getParameters call on a cipher is called after the cipher has been in use for some time, should such an encoding provide the counter's current value, or the starting value at the time the cipher was initialized? * Backporting o We would like to backport this, but because we need the new ChaCha20ParameterSpec class to set the initial counter value ChaCha20 will not get backported. o ChaCha20-Poly1305 however can be backported, and the use of IvParameterSpec with ChaCha20-Poly1305 will allow this to happen. Being able to backport ChaCha20-Poly1305 also allows the TLS cipher suites to be backported when those get added (see below). o Questions concerning how far back this will be backported and in what timeframes are still TBD. * Things that will not be part of this proposal... o TLS Cipher suites: Yes, we will do this, but this will be done as follow-on work. This proposal covers just the JCA portion. I've already got TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, and TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 cipher suites working, so worry not! It is our plan to have these in JSSE. Thanks to everyone who has provided feedback so far and let's set a closure date on the discussion for two weeks from now. I think we should be able to hammer out any questions/concerns within that timeframe. --Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.petcher at oracle.com Thu Jan 25 19:45:00 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 25 Jan 2018 14:45:00 -0500 Subject: Proposal: ChaCha20 and ChaCha20-Poly1305 Cipher implementations In-Reply-To: <8a16b9e2-0db1-5c5d-2386-1194ce01abff@oracle.com> References: <8a16b9e2-0db1-5c5d-2386-1194ce01abff@oracle.com> Message-ID: <635f48f1-2c77-14e7-682a-eedffc1539ed@oracle.com> On 1/25/2018 12:20 PM, Jamil Nimeh wrote: > Wrap and Unwrap: I have not been able to find a standardized > wrap/unwrap format for ChaCha20 similar to RFC 3394 for AES. Right now > the wrap() and unwrap() methods just take the encoding of the key to > be wrapped and encrypts or decrypts them respectively.? If anyone is > aware of a wrapping format for ChaCha20 please let me know.? My > searches have so far come up empty. I haven't found any standards for key wrap with ChaCha20, either. Until these standards are developed, I think the implementation should throw an exception when wrap/unwrap is requested. The problems with simply encrypting are: * No integrity protection in bare ChaCha20 * Need to generate a random nonce on wrap---this violates common expectations about key wrap algorithms * Not standard, so there is potential for confusion about what the key wrap algorithm is actually doing From jamil.j.nimeh at oracle.com Thu Jan 25 20:29:08 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 25 Jan 2018 12:29:08 -0800 Subject: Proposal: ChaCha20 and ChaCha20-Poly1305 Cipher implementations In-Reply-To: <635f48f1-2c77-14e7-682a-eedffc1539ed@oracle.com> References: <8a16b9e2-0db1-5c5d-2386-1194ce01abff@oracle.com> <635f48f1-2c77-14e7-682a-eedffc1539ed@oracle.com> Message-ID: On 1/25/2018 11:45 AM, Adam Petcher wrote: > On 1/25/2018 12:20 PM, Jamil Nimeh wrote: > >> Wrap and Unwrap: I have not been able to find a standardized >> wrap/unwrap format for ChaCha20 similar to RFC 3394 for AES. Right >> now the wrap() and unwrap() methods just take the encoding of the key >> to be wrapped and encrypts or decrypts them respectively.? If anyone >> is aware of a wrapping format for ChaCha20 please let me know.? My >> searches have so far come up empty. > > I haven't found any standards for key wrap with ChaCha20, either. > Until these standards are developed, I think the implementation should > throw an exception when wrap/unwrap is requested. > > The problems with simply encrypting are: > > * No integrity protection in bare ChaCha20 > * Need to generate a random nonce on wrap---this violates common > expectations about key wrap algorithms > * Not standard, so there is potential for confusion about what the key > wrap algorithm is actually doing > > > Yeah, that makes sense to me.? Unless we find that there is some standardized format for wrap/unwrap I'll have it throw UnsupportedOperationException. --Jamil From ecki at zusammenkunft.net Thu Jan 25 20:30:23 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 25 Jan 2018 20:30:23 +0000 Subject: Proposal: ChaCha20 and ChaCha20-Poly1305 Cipher implementations In-Reply-To: <8a16b9e2-0db1-5c5d-2386-1194ce01abff@oracle.com> References: <8a16b9e2-0db1-5c5d-2386-1194ce01abff@oracle.com> Message-ID: You Hello, The spec should most likely mention AAD data as well and the 12 Byte size of the nonce. And that the plaintext Limit is in blocks (and the AAD Limit is a 64Bit counter) (And yes there is no wrapping to be found, not even in RFC 8103 which discusses key transport,) Does it need to define what AP.getEncoded() format/OID looks like? Gruss Bernd -- http://bernd.eckenfels.net _____________________________ From: Jamil Nimeh Sent: Donnerstag, Januar 25, 2018 6:31 PM Subject: Proposal: ChaCha20 and ChaCha20-Poly1305 Cipher implementations To: OpenJDK Dev list Hello all, This is a proposal to introduce the ChaCha20 and ChaCha20-Poly1305 cipher implementations into JDK. At a high level, the plan is to include both ChaCha20-Poly1305 and the base ChaCha20 stream cipher into JDK as part of the SunJCE provider initially, and then add TLS cipher suites as a follow-on feature. Both algorithms will be CipherSpi implementations and will generally conform to the details of that API. I will discuss below some of the details such as which flavors of init are supported, etc. * Instantiation * For ChaCha20 and ChaCha20-Poly1305, the simple name will suffice: either "ChaCha20" for the basic stream cipher or "ChaCha20-Poly1305" for AEAD mode will work. You may however use the 3-element transform "ChaCha20/None/NoPadding" and "ChaCha20-Poly1305/None/NoPadding". Any other type of transformation string will cause NoSuchAlgorithmException to be thrown. * Initialization * All three engineInit methods in the CipherSpi API will be supported. Keys provided through the various Cipher init methods should have the algorithm String "ChaCha20" applied to it (case-insensitive). * For init/engineInit methods that take an AlgorithmParameterSpec, ChaCha20 and ChaCha20-Poly1305 use different APS classes. * ChaCha20 will have a new ChaCha20ParameterSpec which takes a nonce (byte[]) and a counter (int). This class will have getter methods to return those values if desired (getNonce() and getBlockCounter(), respectively). * ChaCha20-Poly1305 will use IvParameterSpec to provide the nonce. The primary reason this is being used instead of ChaCha20ParameterSpec is in order to make backporting to earlier JDK releases possible. Also there's no need to set a counter value, so it would end up being an ignored parameter. * For init calls where no AlgorithmParameterSpec or AlgorithmParameter has been provided, a random nonce will be set at initialization time. the counter value will be set to 1. The random nonce can be retrieved using the getIV() Cipher method or by using the getParameters() call and parsing the output from AlgorithmParameters.getEncoded(). * Use * ChaCha20 encrypt and decrypt operations would work as any stream cipher would - as many bytes of ciphertext are returned from an encrypt function as plaintext bytes submitted (and vice versa for decrypt). * ChaCha20-Poly1305 operates in a similar fashion to other AEAD ciphers. For encryption operations, as many bytes are returned as input submitted with the exception of the doFinal calls, which would return any remaining ciphertext plus an extra 16 bytes for the tag. For decryption, individual update calls return no plaintext. The plaintext is returned only after the last bytes of ciphertext are provided, the authentication tag is provided, and the doFinal call is made. Once the authentication tag has been verified then the plaintext will be returned. * The getOutputSize call will return the following * ChaCha20: Same value as the submitted input size * ChaCha20-Poly1305: For encrypt, the returned size will be the input size + 16 bytes for the tag. For decryption, the returned size will be input length - 16 bytes, or zero (whichever is larger). * Wrap and Unwrap: I have not been able to find a standardized wrap/unwrap format for ChaCha20 similar to RFC 3394 for AES. Right now the wrap() and unwrap() methods just take the encoding of the key to be wrapped and encrypts or decrypts them respectively. If anyone is aware of a wrapping format for ChaCha20 please let me know. My searches have so far come up empty. * Counter rollover protection will be enforced. For ChaCha20 and ChaCha20-Poly1305, the cipher will cease to process input once the 32-bit counter space has been exhausted. * Nonce reuse protection: For both ChaCha20 and ChaCha20-Poly1305: we will not allow reuse of the same nonce between two consecutive init() operations. * KeyGenerator * There will be a new KeyGenerator algorithm called "ChaCha20" which will create a 32-byte key suitable for use in either ChaCha20 or ChaCha20-Poly1305 cipher instances. If you use forms of the KeyGenerator.init() that take a variable key length and you do something other than 32 bytes then you'll have InvalidParameterException thrown at you. * If you use a form of the init that takes an AlgorithmParameterSpec it will throw InvalidAlgorithmParameterSpecException. This is similar in behavior to other KeyGenerators like the HmacSHA-2 family, ARCFOUR, RC2, and AES. * Other TBD/in-progress items * ChaCha20Parameters: This will be added to com.sun.crypto.provider and will be able to provide an encoding for parameters used in ChaCha20 and ChaCha20-Poly1305 ciphers. * For ChaCha20-Poly1305, the default encoded form of the AlgorithmParameters will be the AEADChaCha20Poly1305Nonce from RFC 8103 section 3 (basically the nonce as an ASN.1 OCTET STRING of 12 bytes). * For ChaCha20 I have not been able to find a standardized encoding for ChaCha20 parameters. For lack of an official format I currently have it encoding the parameters as a SEQUENCE of an OCTET STRING (the nonce) and an INTEGER (the counter starting value). * Question: If a getParameters call on a cipher is called after the cipher has been in use for some time, should such an encoding provide the counter's current value, or the starting value at the time the cipher was initialized? * Backporting * We would like to backport this, but because we need the new ChaCha20ParameterSpec class to set the initial counter value ChaCha20 will not get backported. * ChaCha20-Poly1305 however can be backported, and the use of IvParameterSpec with ChaCha20-Poly1305 will allow this to happen. Being able to backport ChaCha20-Poly1305 also allows the TLS cipher suites to be backported when those get added (see below). * Questions concerning how far back this will be backported and in what timeframes are still TBD. * Things that will not be part of this proposal... * TLS Cipher suites: Yes, we will do this, but this will be done as follow-on work. This proposal covers just the JCA portion. I've already got TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, and TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 cipher suites working, so worry not! It is our plan to have these in JSSE. Thanks to everyone who has provided feedback so far and let's set a closure date on the discussion for two weeks from now. I think we should be able to hammer out any questions/concerns within that timeframe. --Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Jan 25 21:00:42 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 25 Jan 2018 16:00:42 -0500 Subject: RFR 8177398: Exclude dot files ending with .conf from krb5.conf's includedir In-Reply-To: <6EF11571-CF25-4A7B-89EE-A856F61200B7@oracle.com> References: <6EF11571-CF25-4A7B-89EE-A856F61200B7@oracle.com> Message-ID: <96c3cad5-3fd2-c920-8417-a4ce69519be3@oracle.com> Looks fine to me. --Sean On 1/24/18 10:53 PM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8177398/webrev.00/ > > Dotfiles will not be included in "includedir" of krb5.conf. > > Thanks > Max > From adam.petcher at oracle.com Fri Jan 26 21:06:13 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Fri, 26 Jan 2018 16:06:13 -0500 Subject: RFR 8181594: Efficient and constant-time modular arithmetic Message-ID: JBS: https://bugs.openjdk.java.net/browse/JDK-8181594 Webrev: http://cr.openjdk.java.net/~apetcher/8181594/webrev.00/ This is a code review for the field arithmetic that will be used in implementations of X25519/X448 key agreement, the Poly1305 authenticator, and EdDSA signatures. I believe that the library has all the features necessary for X25519/X448 and Poly1305, and I expect at most a couple of minor enhancements will be required to support EdDSA. There is no public API for this library, so we can change it in the future to suit the needs of new algorithms without breaking compatibility with external code. Still, I made an attempt to clearly structure and document the (internal) API, and I want to make sure it is understandable and easy to use. This is not a general-purpose modular arithmetic library. It will only work well in circumstances where the sequence of operations is restricted, and where the prime that defines the field has some useful structure. Moreover, each new field will require some field-specific code that takes into account the structure of the prime and the way the field is used in the application. The initial implementation includes a field for Poly1305 and the fields for X25519/X448 which should also work for EdDSA. The benefits of using this library are that it is much more efficient than using similar operations in BigInteger. Also, many operations are branch-free, making them suitable for use in a side-channel resistant implementation that does not branch on secrets. To provide some context, I have attached a code snippet describing how this library can be used. The snippet is the constant-time Montgomery ladder from my X25519/X448 implementation, which I expect to be out for review soon. X25519/X448 only uses standard arithmetic operations, and the more unusual features (e.g. add modulo a power of 2) are needed by Poly1305. The field arithmetic (for all fields) is implemented using a 32-bit representation similar to the one described in the Ed448 paper[1] (in the "Implementation on 32-bit platforms" section). Though my implementation uses signed limbs, and grade-school multiplication instead of Karatsuba. The argument for correctness is essentially the same for all three fields: the magnitude of each 64-bit limb is at most 2^(k-1) after reduction, except for the last limb which may have a magnitude of up to 2^k. The values of k are between 26 to 28 (depending on the field), and we can calculate that the maximum magnitude for any limb during an add-multiply-carry-reduce sequence is always less than 2^63. Therefore, no overflow occurs and all operations are correct. Process note: this enhancement is part of JEP 324 (Key Agreement with Curve25519 and Curve448). When this code review is complete, nothing will happen until all other work for this JEP is complete, and the JEP is accepted as part of some release. This means that this code will be pushed to the repo along with the X25519/X448 code that uses it. [1] https://eprint.iacr.org/2015/625.pdf -------------- next part -------------- private IntegerModuloP_Base pointMultiply(byte[] k, IntegerModuloP u){ IntegerModuloP x_1 = u; MutableIntegerModuloP x_2 = one.mutable(); MutableIntegerModuloP z_2 = zero.mutable(); MutableIntegerModuloP x_3 = u.mutable(); MutableIntegerModuloP z_3 = one.mutable(); int swap = 0; // Variables below are reused to avoid unnecessary allocation // They will be assigned in the loop, so initial value doesn't matter MutableIntegerModuloP m1 = zero.mutable(); MutableIntegerModuloP DA = zero.mutable(); MutableIntegerModuloP E = zero.mutable(); MutableIntegerModuloP a24_times_E = zero.mutable(); for(int t = params.getBits() - 1; t >= 0; t--){ int k_t = bitAt(k, t); swap = swap ^ k_t; x_2.conditionalSwapWith(x_3, swap); z_2.conditionalSwapWith(z_3, swap); swap = k_t; // A(m1) = x_2 + z_2 m1.setValue(x_2).setSum(z_2); // D = x_3 - z_3 // DA = D * A(m1) DA.setValue(x_3).setDifference(z_3).setProduct(m1); // AA(m1) = A(m1)^2 m1.setSquare(); // B(x_2) = x_2 - z_2 x_2.setDifference(z_2); // C = x_3 + z_3 // CB(x_3) = C * B(x_2) x_3.setSum(z_3).setProduct(x_2); // BB(x_2) = B^2 x_2.setSquare(); // E = AA(m1) - BB(x_2) E.setValue(m1).setDifference(x_2); // compute a24 * E using SmallValue a24_times_E.setValue(E); a24_times_E.setProduct(a24); // assign results to x_3, z_3, x_2, z_2 // x_2 = AA(m1) * BB x_2.setProduct(m1); // z_2 = E * (AA(m1) + a24 * E) z_2.setValue(m1).setSum(a24_times_E).setProduct(E); // z_3 = x_1*(DA - CB(x_3))^2 z_3.setValue(DA).setDifference(x_3).setSquare().setProduct(x_1); // x_3 = (CB(x_3) + DA)^2 x_3.setSum(DA).setSquare(); } x_2.conditionalSwapWith(x_3, swap); z_2.conditionalSwapWith(z_3, swap); // return (x_2 * z_2^(p - 2)) return x_2.setProduct(z_2.multiplicativeInverse()); } From sean.mullan at oracle.com Fri Jan 26 21:31:29 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 26 Jan 2018 16:31:29 -0500 Subject: Update mechanism for the upcoming trust store In-Reply-To: <6254fadc-06f0-c96a-0abd-69021cbd341d@ssl.com> References: <6cd7d58a-c233-cf45-b80c-2c48fdd5b69e@ssl.com> <6254fadc-06f0-c96a-0abd-69021cbd341d@ssl.com> Message-ID: On 1/24/18 5:39 AM, Fotis Loukos wrote: >> You may not be aware, but the JDK does currently support a mechanism for >> blacklisting certificates. The lib/security/blacklisted.certs file >> contains a list of the fingerprints of certificates that are explicitly >> distrusted. If a root was compromised and added to this file it would no >> longer be trusted. > My biggest concern is what you describe below, the dynamic update. > >> However, currently there is no mechanism in OpenJDK to dynamically >> update that file. While I think there is merit in implementing something >> like that, many challenges would need to be addressed as part of that, >> for example, where and how does this file get updated, how is it >> verified, etc. > The verification step can be implemented as described above. I think > that the update step requires some design, but I don't think it is that > difficult. For example, a naive algorithm such as every Monday plus a > random number of days/hours/minutes in order to avoid heavy traffic > during the update period would be good for starters. As a first step to > try a new format, you could even fetch it once during installation and > provide a means for the user to update it manually. One thing we could potentially do initially is to provide a stable https URL where an updated blacklist could be downloaded, something like what Mozilla does for OneCRL [1]. This would be an initial step, not the whole solution of course, but it at least would allow someone to quickly update their JDK should a certificate need to be distrusted ASAP. Let me look into that a bit. I think implementing a dynamic solution is more challenging and would require more design/review, etc but feel free to provide more details on any additional thoughts or design sketches you might have. --Sean [1] https://firefox.settings.services.mozilla.com/v1/buckets/blocklists/collections/certificates/records From jamil.j.nimeh at oracle.com Fri Jan 26 21:57:42 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 26 Jan 2018 13:57:42 -0800 Subject: Proposal: ChaCha20 and ChaCha20-Poly1305 Cipher implementations In-Reply-To: References: <8a16b9e2-0db1-5c5d-2386-1194ce01abff@oracle.com> Message-ID: <05ada6f3-4792-d8ed-7bd8-cb61e085abd8@oracle.com> Hi Bernd, thank you for the feedback! On 01/25/2018 12:30 PM, Bernd Eckenfels wrote: > You Hello, > > The spec should most likely mention AAD data as well and the 12 Byte > size of the nonce. And that the plaintext Limit is in blocks (and the > AAD Limit is a 64Bit counter) Good point about AAD. My code currently doesn't check to make sure the total AAD from each AAD update doesn't overflow the 64-bit length. It definitely needs to and can be done pretty easily. Thanks for pointing that out. In terms of nonce length checking, I'll have to handle it multiple ways. For ChaCha20ParameterSpec, I can check it in the constructor and that's easy to do. Because ChaCha20-Poly1305 will use IvParameterSpec, a check will need to be done in the init call. If I handle it there I could avoid it in the ChaCha20ParameterSpec too, but it seems better to report an error sooner rather than later and I don't think it hurts to have the check in both places. I will probably also need a similar check in ChaCha20Parameters when AP.init() is called with whatever encoding we're going with. > > (And yes there is no wrapping to be found, not even in RFC 8103 which > discusses key transport,) Thanks for confirming our suspicions so far. > > Does it need to define what AP.getEncoded() format/OID looks like? Let me work backward from your two points: Are you referring to the use of an OID instead of a name for use with AP.getInstance()? If so I'll need to look that up, but I agree that it needs to be called out in the specification. Thank you for pointing that out. Should we call out the encoding format? It should. I would expect the output for ChaCha20-Poly1305 to just be a DER-encoded OCTET STRING, so it would look something like 0x04 0x0C [insert 12 bytes here] ChaCha20 is the one that concerns me, because I see no standardized encoding. There are other algs that do SEQUENCES of octet strings and integers in varying orders, but of course the meanings of those differ. The ASN.1 that I'm currently encoding (because I wanted *something*) is: SEQUENCE { OCTET STRING (12 byte nonce) INTEGER (initial counter value) } What worries me a bit is what alg name to assign to it in the standard names document. If I call it "ChaCha20" and then some standardized format is developed, then we have a potential conflict down the line as we make our AP conform to the new standard. If I come up with another name (call it "FooFoo20" as a placeholder), then getEncoded("FooFoo20") could continue to provide that encoding into the future and leave room for a standardized encoding with the name "ChaCha20". But what of the default? Without a standardized format, does FooFoo20 become the default? And when the standardized version becomes real then the default probably should change to ChaCha20's encoding and we have another behavioral change there. Neither of those alternatives really sit well with me. I admit I don't have a good answer yet on this one. --Jamil > > Gruss > Bernd > -- > http://bernd.eckenfels.net > _____________________________ > From: Jamil Nimeh > Sent: Donnerstag, Januar 25, 2018 6:31 PM > Subject: Proposal: ChaCha20 and ChaCha20-Poly1305 Cipher implementations > To: OpenJDK Dev list > > > Hello all, > > This is a proposal to introduce the ChaCha20 and ChaCha20-Poly1305 > cipher implementations into JDK. At a high level, the plan is to > include both ChaCha20-Poly1305 and the base ChaCha20 stream cipher > into JDK as part of the SunJCE provider initially, and then add TLS > cipher suites as a follow-on feature. > > Both algorithms will be CipherSpi implementations and will generally > conform to the details of that API. I will discuss below some of the > details such as which flavors of init are supported, etc. > > * Instantiation > o For ChaCha20 and ChaCha20-Poly1305, the simple name will > suffice: either "ChaCha20" for the basic stream cipher or > "ChaCha20-Poly1305" for AEAD mode will work. You may however > use the 3-element transform "ChaCha20/None/NoPadding" and > "ChaCha20-Poly1305/None/NoPadding". Any other type of > transformation string will cause NoSuchAlgorithmException to > be thrown. > * Initialization > o All three engineInit methods in the CipherSpi API will be > supported. Keys provided through the various Cipher init > methods should have the algorithm String "ChaCha20" applied to > it (case-insensitive). > o For init/engineInit methods that take an > AlgorithmParameterSpec, ChaCha20 and ChaCha20-Poly1305 use > different APS classes. > + ChaCha20 will have a new ChaCha20ParameterSpec which takes > a nonce (byte[]) and a counter (int). This class will > have getter methods to return those values if desired > (getNonce() and getBlockCounter(), respectively). > + ChaCha20-Poly1305 will use IvParameterSpec to provide the > nonce. The primary reason this is being used instead of > ChaCha20ParameterSpec is in order to make backporting to > earlier JDK releases possible. Also there's no need to > set a counter value, so it would end up being an ignored > parameter. > + For init calls where no AlgorithmParameterSpec or > AlgorithmParameter has been provided, a random nonce will > be set at initialization time. the counter value will be > set to 1. The random nonce can be retrieved using the > getIV() Cipher method or by using the getParameters() call > and parsing the output from AlgorithmParameters.getEncoded(). > * Use > o ChaCha20 encrypt and decrypt operations would work as any > stream cipher would - as many bytes of ciphertext are returned > from an encrypt function as plaintext bytes submitted (and > vice versa for decrypt). > o ChaCha20-Poly1305 operates in a similar fashion to other AEAD > ciphers. For encryption operations, as many bytes are > returned as input submitted with the exception of the doFinal > calls, which would return any remaining ciphertext plus an > extra 16 bytes for the tag. For decryption, individual update > calls return no plaintext. The plaintext is returned only > after the last bytes of ciphertext are provided, the > authentication tag is provided, and the doFinal call is made. > Once the authentication tag has been verified then the > plaintext will be returned. > o The getOutputSize call will return the following > + ChaCha20: Same value as the submitted input size > + ChaCha20-Poly1305: For encrypt, the returned size will be > the input size + 16 bytes for the tag. For decryption, > the returned size will be input length - 16 bytes, or zero > (whichever is larger). > o Wrap and Unwrap: I have not been able to find a standardized > wrap/unwrap format for ChaCha20 similar to RFC 3394 for AES. > Right now the wrap() and unwrap() methods just take the > encoding of the key to be wrapped and encrypts or decrypts > them respectively. If anyone is aware of a wrapping format > for ChaCha20 please let me know. My searches have so far come > up empty. > o Counter rollover protection will be enforced. For ChaCha20 > and ChaCha20-Poly1305, the cipher will cease to process input > once the 32-bit counter space has been exhausted. > o Nonce reuse protection: For both ChaCha20 and > ChaCha20-Poly1305: we will not allow reuse of the same nonce > between two consecutive init() operations. > * KeyGenerator > o There will be a new KeyGenerator algorithm called "ChaCha20" > which will create a 32-byte key suitable for use in either > ChaCha20 or ChaCha20-Poly1305 cipher instances. If you use > forms of the KeyGenerator.init() that take a variable key > length and you do something other than 32 bytes then you'll > have InvalidParameterException thrown at you. > o If you use a form of the init that takes an > AlgorithmParameterSpec it will throw > InvalidAlgorithmParameterSpecException. This is similar in > behavior to other KeyGenerators like the HmacSHA-2 family, > ARCFOUR, RC2, and AES. > * Other TBD/in-progress items > o ChaCha20Parameters: This will be added to > com.sun.crypto.provider and will be able to provide an > encoding for parameters used in ChaCha20 and ChaCha20-Poly1305 > ciphers. > + For ChaCha20-Poly1305, the default encoded form of the > AlgorithmParameters will be the AEADChaCha20Poly1305Nonce > from RFC 8103 section 3 (basically the nonce as an ASN.1 > OCTET STRING of 12 bytes). > + For ChaCha20 I have not been able to find a standardized > encoding for ChaCha20 parameters. For lack of an official > format I currently have it encoding the parameters as a > SEQUENCE of an OCTET STRING (the nonce) and an INTEGER > (the counter starting value). > # Question: If a getParameters call on a cipher is > called after the cipher has been in use for some time, > should such an encoding provide the counter's current > value, or the starting value at the time the cipher > was initialized? > * Backporting > o We would like to backport this, but because we need the new > ChaCha20ParameterSpec class to set the initial counter value > ChaCha20 will not get backported. > o ChaCha20-Poly1305 however can be backported, and the use of > IvParameterSpec with ChaCha20-Poly1305 will allow this to > happen. Being able to backport ChaCha20-Poly1305 also allows > the TLS cipher suites to be backported when those get added > (see below). > o Questions concerning how far back this will be backported and > in what timeframes are still TBD. > * Things that will not be part of this proposal... > o TLS Cipher suites: Yes, we will do this, but this will be done > as follow-on work. This proposal covers just the JCA > portion. I've already got > TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, > TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, and > TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 cipher suites > working, so worry not! It is our plan to have these in JSSE. > > Thanks to everyone who has provided feedback so far and let's set a > closure date on the discussion for two weeks from now. I think we > should be able to hammer out any questions/concerns within that timeframe. > > --Jamil > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Sat Jan 27 17:42:54 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sat, 27 Jan 2018 18:42:54 +0100 Subject: Proposal: ChaCha20 and ChaCha20-Poly1305 Cipher implementations In-Reply-To: <05ada6f3-4792-d8ed-7bd8-cb61e085abd8@oracle.com> References: <8a16b9e2-0db1-5c5d-2386-1194ce01abff@oracle.com> <05ada6f3-4792-d8ed-7bd8-cb61e085abd8@oracle.com> Message-ID: <5a6cba1d.2583df0a.3db6.371b@mx.google.com> Hello Jamil, thanks BTW for bringing modern cryto to the OpenJDK. ? I was not refering to OID for getInstance, however now that you mention it it would be good to have such an alias. RFC 8103 defines id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::={ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 18 } You are right, I was just asking to spell out the AP.getEncoding() format. It seems generally hard to come by, so thats good to have it in the JavaDoc of the Parameters object. It is good to be concerned about bare ChaCha20 beeing underspecified. I wonder, do we need tp provide it at all? Gruss Bernd -- http://bernd.eckenfels.net Von: Jamil Nimeh Gesendet: Freitag, 26. Januar 2018 22:57 An: Bernd Eckenfels; OpenJDK Dev list Betreff: Re: Proposal: ChaCha20 and ChaCha20-Poly1305 Cipher implementations Hi Bernd, thank you for the feedback! On 01/25/2018 12:30 PM, Bernd Eckenfels wrote: You Hello, The spec should most likely mention AAD data as well and the 12 Byte size of the nonce. And that the plaintext Limit is in blocks (and the AAD Limit is a 64Bit counter) Good point about AAD.? My code currently doesn't check to make sure the total AAD from each AAD update doesn't overflow the 64-bit length.? It definitely needs to and can be done pretty easily.? Thanks for pointing that out. In terms of nonce length checking, I'll have to handle it multiple ways.? For ChaCha20ParameterSpec, I can check it in the constructor and that's easy to do.? Because ChaCha20-Poly1305 will use IvParameterSpec, a check will need to be done in the init call.? If I handle it there I could avoid it in the ChaCha20ParameterSpec too, but it seems better to report an error sooner rather than later and I don't think it hurts to have the check in both places. I will probably also need a similar check in ChaCha20Parameters when AP.init() is called with whatever encoding we're going with. (And yes there is no wrapping to be found, not even in RFC 8103 which discusses key transport,) Thanks for confirming our suspicions so far. Does it need to define what AP.getEncoded() format/OID looks like? Let me work backward from your two points: Are you referring to the use of an OID instead of a name for use with AP.getInstance()?? If so I'll need to look that up, but I agree that it needs to be called out in the specification.? Thank you for pointing that out. Should we call out the encoding format? It should.? I would expect the output for ChaCha20-Poly1305 to just be a DER-encoded OCTET STRING, so it would look something like 0x04 0x0C [insert 12 bytes here] ChaCha20 is the one that concerns me, because I see no standardized encoding.? There are other algs that do SEQUENCES of octet strings and integers in varying orders, but of course the meanings of those differ.? The ASN.1 that I'm currently encoding (because I wanted *something*) is: SEQUENCE { ??? OCTET STRING (12 byte nonce) ??? INTEGER (initial counter value) } What worries me a bit is what alg name to assign to it in the standard names document.? If I call it "ChaCha20" and then some standardized format is developed, then we have a potential conflict down the line as we make our AP conform to the new standard.? If I come up with another name (call it "FooFoo20" as a placeholder), then getEncoded("FooFoo20") could continue to provide that encoding into the future and leave room for a standardized encoding with the name "ChaCha20".? But what of the default?? Without a standardized format, does FooFoo20 become the default?? And when the standardized version becomes real then the default probably should change to ChaCha20's encoding and we have another behavioral change there.? Neither of those alternatives really sit well with me.? I admit I don't have a good answer yet on this one. --Jamil Gruss Bernd -- http://bernd.eckenfels.net _____________________________ From: Jamil Nimeh Sent: Donnerstag, Januar 25, 2018 6:31 PM Subject: Proposal: ChaCha20 and ChaCha20-Poly1305 Cipher implementations To: OpenJDK Dev list Hello all, This is a proposal to introduce the ChaCha20 and ChaCha20-Poly1305 cipher implementations into JDK.? At a high level, the plan is to include both ChaCha20-Poly1305 and the base ChaCha20 stream cipher into JDK as part of the SunJCE provider initially, and then add TLS cipher suites as a follow-on feature. Both algorithms will be CipherSpi implementations and will generally conform to the details of that API.? I will discuss below some of the details such as which flavors of init are supported, etc. ? Instantiation o For ChaCha20 and ChaCha20-Poly1305, the simple name will suffice: either "ChaCha20" for the basic stream cipher or "ChaCha20-Poly1305" for AEAD mode will work.? You may however use the 3-element transform "ChaCha20/None/NoPadding" and "ChaCha20-Poly1305/None/NoPadding".? Any other type of transformation string will cause NoSuchAlgorithmException to be thrown. ? Initialization o All three engineInit methods in the CipherSpi API will be supported.? Keys provided through the various Cipher init methods should have the algorithm String "ChaCha20" applied to it (case-insensitive). o For init/engineInit methods that take an AlgorithmParameterSpec, ChaCha20 and ChaCha20-Poly1305 use different APS classes. ? ChaCha20 will have a new ChaCha20ParameterSpec which takes a nonce (byte[]) and a counter (int).? This class will have getter methods to return those values if desired (getNonce() and getBlockCounter(), respectively). ? ChaCha20-Poly1305 will use IvParameterSpec to provide the nonce.? The primary reason this is being used instead of ChaCha20ParameterSpec is in order to make backporting to earlier JDK releases possible.? Also there's no need to set a counter value, so it would end up being an ignored parameter. ? For init calls where no AlgorithmParameterSpec or AlgorithmParameter has been provided, a random nonce will be set at initialization time.? the counter value will be set to 1.? The random nonce can be retrieved using the getIV() Cipher method or by using the getParameters() call and parsing the output from AlgorithmParameters.getEncoded(). ? Use o ChaCha20 encrypt and decrypt operations would work as any stream cipher would - as many bytes of ciphertext are returned from an encrypt function as plaintext bytes submitted (and vice versa for decrypt). o ChaCha20-Poly1305 operates in a similar fashion to other AEAD ciphers.? For encryption operations, as many bytes are returned as input submitted with the exception of the doFinal calls, which would return any remaining ciphertext plus an extra 16 bytes for the tag.? For decryption, individual update calls return no plaintext.? The plaintext is returned only after the last bytes of ciphertext are provided, the authentication tag is provided, and the doFinal call is made.? Once the authentication tag has been verified then the plaintext will be returned. o The getOutputSize call will return the following ? ChaCha20: Same value as the submitted input size ? ChaCha20-Poly1305: For encrypt, the returned size will be the input size + 16 bytes for the tag.? For decryption, the returned size will be input length - 16 bytes, or zero (whichever is larger). o Wrap and Unwrap: I have not been able to find a standardized wrap/unwrap format for ChaCha20 similar to RFC 3394 for AES.? Right now the wrap() and unwrap() methods just take the encoding of the key to be wrapped and encrypts or decrypts them respectively.? If anyone is aware of a wrapping format for ChaCha20 please let me know.? My searches have so far come up empty. o Counter rollover protection will be enforced.? For ChaCha20 and ChaCha20-Poly1305, the cipher will cease to process input once the 32-bit counter space has been exhausted. o Nonce reuse protection: For both ChaCha20 and ChaCha20-Poly1305: we will not allow reuse of the same nonce between two consecutive init() operations. ? KeyGenerator o There will be a new KeyGenerator algorithm called "ChaCha20" which will create a 32-byte key suitable for use in either ChaCha20 or ChaCha20-Poly1305 cipher instances.? If you use forms of the KeyGenerator.init() that take a variable key length and you do something other than 32 bytes then you'll have InvalidParameterException thrown at you. o If you use a form of the init that takes an AlgorithmParameterSpec it will throw InvalidAlgorithmParameterSpecException.? This is similar in behavior to other KeyGenerators like the HmacSHA-2 family, ARCFOUR, RC2, and AES. ? Other TBD/in-progress items o ChaCha20Parameters: This will be added to com.sun.crypto.provider and will be able to provide an encoding for parameters used in ChaCha20 and ChaCha20-Poly1305 ciphers. ? For ChaCha20-Poly1305, the default encoded form of the AlgorithmParameters will be the AEADChaCha20Poly1305Nonce from RFC 8103 section 3 (basically the nonce as an ASN.1 OCTET STRING of 12 bytes). ? For ChaCha20 I have not been able to find a standardized encoding for ChaCha20 parameters.? For lack of an official format I currently have it encoding the parameters as a SEQUENCE of an OCTET STRING (the nonce) and an INTEGER (the counter starting value). ? Question: If a getParameters call on a cipher is called after the cipher has been in use for some time, should such an encoding provide the counter's current value, or the starting value at the time the cipher was initialized? ? Backporting o We would like to backport this, but because we need the new ChaCha20ParameterSpec class to set the initial counter value ChaCha20 will not get backported. o ChaCha20-Poly1305 however can be backported, and the use of IvParameterSpec with ChaCha20-Poly1305 will allow this to happen.? Being able to backport ChaCha20-Poly1305 also allows the TLS cipher suites to be backported when those get added (see below). o Questions concerning how far back this will be backported and in what timeframes are still TBD. ? Things that will not be part of this proposal... o TLS Cipher suites: Yes, we will do this, but this will be done as follow-on work.? This proposal covers just the JCA portion.? I've already got TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, and TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 cipher suites working, so worry not!? It is our plan to have these in JSSE. Thanks to everyone who has provided feedback so far and let's set a closure date on the discussion for two weeks from now.? I think we should be able to hammer out any questions/concerns within that timeframe. --Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Sat Jan 27 19:03:04 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Sat, 27 Jan 2018 11:03:04 -0800 Subject: Proposal: ChaCha20 and ChaCha20-Poly1305 Cipher implementations In-Reply-To: <5a6cba1d.2583df0a.3db6.371b@mx.google.com> Message-ID: <201801271903.w0RJ3AAB008960@aserv0121.oracle.com> Hi Bernd, To your last question, maybe we don't provide an encoding and Cipher.getParameters() would throw an exception.? And the form of Cipher.getInstance() that takes AlgorithmParameters for ChaCha20 would throw an exception also. And down the line if a parameter encoding is standardized we can enhance ChaCha20 classes to support it. --Jamil -------- Original message --------From: Bernd Eckenfels Date: 1/27/18 9:42 AM (GMT-08:00) To: Jamil Nimeh , OpenJDK Dev list Subject: Re: Proposal: ChaCha20 and ChaCha20-Poly1305 Cipher implementations Hello Jamil,?thanks BTW for bringing modern cryto to the OpenJDK. ??I was not refering to OID for getInstance, however now that you mention it it would be good to have such an alias. RFC 8103 defines id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::={ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 18 }You are right, I was just asking to spell out the AP.getEncoding() format. It seems generally hard to come by, so thats good to have it in the JavaDoc of the Parameters object.?It is good to be concerned about bare ChaCha20 beeing underspecified. I wonder, do we need tp provide it at all??GrussBernd-- http://bernd.eckenfels.net?Von: Jamil Nimeh Gesendet: Freitag, 26. Januar 2018 22:57 An: Bernd Eckenfels; OpenJDK Dev list Betreff: Re: Proposal: ChaCha20 and ChaCha20-Poly1305 Cipher implementations?Hi Bernd, thank you for the feedback!?On 01/25/2018 12:30 PM, Bernd Eckenfels wrote:You Hello,?The spec should most likely mention AAD data as well and the 12 Byte size of the nonce. And that the plaintext Limit is in blocks (and the AAD Limit is a 64Bit counter)Good point about AAD.? My code currently doesn't check to make sure the total AAD from each AAD update doesn't overflow the 64-bit length.? It definitely needs to and can be done pretty easily.? Thanks for pointing that out. In terms of nonce length checking, I'll have to handle it multiple ways.? For ChaCha20ParameterSpec, I can check it in the constructor and that's easy to do.? Because ChaCha20-Poly1305 will use IvParameterSpec, a check will need to be done in the init call.? If I handle it there I could avoid it in the ChaCha20ParameterSpec too, but it seems better to report an error sooner rather than later and I don't think it hurts to have the check in both places. I will probably also need a similar check in ChaCha20Parameters when AP.init() is called with whatever encoding we're going with. ?(And yes there is no wrapping to be found, not even in RFC 8103 which discusses key transport,)Thanks for confirming our suspicions so far. ?Does it need to define what AP.getEncoded() format/OID looks like?Let me work backward from your two points: Are you referring to the use of an OID instead of a name for use with AP.getInstance()?? If so I'll need to look that up, but I agree that it needs to be called out in the specification.? Thank you for pointing that out. Should we call out the encoding format? It should.? I would expect the output for ChaCha20-Poly1305 to just be a DER-encoded OCTET STRING, so it would look something like 0x04 0x0C [insert 12 bytes here] ChaCha20 is the one that concerns me, because I see no standardized encoding.? There are other algs that do SEQUENCES of octet strings and integers in varying orders, but of course the meanings of those differ.? The ASN.1 that I'm currently encoding (because I wanted *something*) is: SEQUENCE { ??? OCTET STRING (12 byte nonce) ??? INTEGER (initial counter value) } What worries me a bit is what alg name to assign to it in the standard names document.? If I call it "ChaCha20" and then some standardized format is developed, then we have a potential conflict down the line as we make our AP conform to the new standard.? If I come up with another name (call it "FooFoo20" as a placeholder), then getEncoded("FooFoo20") could continue to provide that encoding into the future and leave room for a standardized encoding with the name "ChaCha20".? But what of the default?? Without a standardized format, does FooFoo20 become the default?? And when the standardized version becomes real then the default probably should change to ChaCha20's encoding and we have another behavioral change there.? Neither of those alternatives really sit well with me.? I admit I don't have a good answer yet on this one. --Jamil ?GrussBernd-- http://bernd.eckenfels.net_____________________________ From: Jamil Nimeh Sent: Donnerstag, Januar 25, 2018 6:31 PM Subject: Proposal: ChaCha20 and ChaCha20-Poly1305 Cipher implementations To: OpenJDK Dev list Hello all,This is a proposal to introduce the ChaCha20 and ChaCha20-Poly1305 cipher implementations into JDK.? At a high level, the plan is to include both ChaCha20-Poly1305 and the base ChaCha20 stream cipher into JDK as part of the SunJCE provider initially, and then add TLS cipher suites as a follow-on feature.Both algorithms will be CipherSpi implementations and will generally conform to the details of that API.? I will discuss below some of the details such as which flavors of init are supported, etc.Instantiation For ChaCha20 and ChaCha20-Poly1305, the simple name will suffice: either "ChaCha20" for the basic stream cipher or "ChaCha20-Poly1305" for AEAD mode will work.? You may however use the 3-element transform "ChaCha20/None/NoPadding" and "ChaCha20-Poly1305/None/NoPadding".? Any other type of transformation string will cause NoSuchAlgorithmException to be thrown.Initialization All three engineInit methods in the CipherSpi API will be supported.? Keys provided through the various Cipher init methods should have the algorithm String "ChaCha20" applied to it (case-insensitive).For init/engineInit methods that take an AlgorithmParameterSpec, ChaCha20 and ChaCha20-Poly1305 use different APS classes. ChaCha20 will have a new ChaCha20ParameterSpec which takes a nonce (byte[]) and a counter (int).? This class will have getter methods to return those values if desired (getNonce() and getBlockCounter(), respectively).ChaCha20-Poly1305 will use IvParameterSpec to provide the nonce.? The primary reason this is being used instead of ChaCha20ParameterSpec is in order to make backporting to earlier JDK releases possible.? Also there's no need to set a counter value, so it would end up being an ignored parameter.For init calls where no AlgorithmParameterSpec or AlgorithmParameter has been provided, a random nonce will be set at initialization time.? the counter value will be set to 1.? The random nonce can be retrieved using the getIV() Cipher method or by using the getParameters() call and parsing the output from AlgorithmParameters.getEncoded().Use ChaCha20 encrypt and decrypt operations would work as any stream cipher would - as many bytes of ciphertext are returned from an encrypt function as plaintext bytes submitted (and vice versa for decrypt).ChaCha20-Poly1305 operates in a similar fashion to other AEAD ciphers.? For encryption operations, as many bytes are returned as input submitted with the exception of the doFinal calls, which would return any remaining ciphertext plus an extra 16 bytes for the tag.? For decryption, individual update calls return no plaintext.? The plaintext is returned only after the last bytes of ciphertext are provided, the authentication tag is provided, and the doFinal call is made.? Once the authentication tag has been verified then the plaintext will be returned. The getOutputSize call will return the following ChaCha20: Same value as the submitted input size ChaCha20-Poly1305: For encrypt, the returned size will be the input size + 16 bytes for the tag.? For decryption, the returned size will be input length - 16 bytes, or zero (whichever is larger).Wrap and Unwrap: I have not been able to find a standardized wrap/unwrap format for ChaCha20 similar to RFC 3394 for AES.? Right now the wrap() and unwrap() methods just take the encoding of the key to be wrapped and encrypts or decrypts them respectively.? If anyone is aware of a wrapping format for ChaCha20 please let me know.? My searches have so far come up empty.Counter rollover protection will be enforced.? For ChaCha20 and ChaCha20-Poly1305, the cipher will cease to process input once the 32-bit counter space has been exhausted.Nonce reuse protection: For both ChaCha20 and ChaCha20-Poly1305: we will not allow reuse of the same nonce between two consecutive init() operations.KeyGenerator There will be a new KeyGenerator algorithm called "ChaCha20" which will create a 32-byte key suitable for use in either ChaCha20 or ChaCha20-Poly1305 cipher instances.? If you use forms of the KeyGenerator.init() that take a variable key length and you do something other than 32 bytes then you'll have InvalidParameterException thrown at you.If you use a form of the init that takes an AlgorithmParameterSpec it will throw InvalidAlgorithmParameterSpecException.? This is similar in behavior to other KeyGenerators like the HmacSHA-2 family, ARCFOUR, RC2, and AES.Other TBD/in-progress items ChaCha20Parameters: This will be added to com.sun.crypto.provider and will be able to provide an encoding for parameters used in ChaCha20 and ChaCha20-Poly1305 ciphers. For ChaCha20-Poly1305, the default encoded form of the AlgorithmParameters will be the AEADChaCha20Poly1305Nonce from RFC 8103 section 3 (basically the nonce as an ASN.1 OCTET STRING of 12 bytes).For ChaCha20 I have not been able to find a standardized encoding for ChaCha20 parameters.? For lack of an official format I currently have it encoding the parameters as a SEQUENCE of an OCTET STRING (the nonce) and an INTEGER (the counter starting value). Question: If a getParameters call on a cipher is called after the cipher has been in use for some time, should such an encoding provide the counter's current value, or the starting value at the time the cipher was initialized?Backporting We would like to backport this, but because we need the new ChaCha20ParameterSpec class to set the initial counter value ChaCha20 will not get backported -------------- next part -------------- An HTML attachment was scrubbed... URL: From anders.rundgren.net at gmail.com Sun Jan 28 09:48:17 2018 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Sun, 28 Jan 2018 10:48:17 +0100 Subject: Da Capo: JSON "clear text" signatures Message-ID: The JSON "clear text" signature initiative seems to (finally) be headed for IETF standardization.? The plan is having a BOF session at the next IETF in London. This scheme builds on EcmaScript JSON processing rules for data normalization which only rely on JSON.parse() and JSON.stringify(). A thorny issue for implementers is though serializing the JSON "Number" type. An with Node.js, Chrome, Firefox, Safari (unfortunately not entirely compatible...) solution is currently available in "Nashorn": http://hg.openjdk.java.net/jdk8/jdk8/nashorn/file/096dc407d310/src/jdk/nashorn/internal/objects/NativeNumber.java It would be great if such support could for example be included as a static method in java.lang.Double, making Java and EcmaScript/JavaScript 100% interoperable with respect to this feature, the rest is actually close to trivial. thanx, Anders https://github.com/OAI/OpenAPI-Specification/issues/1464#issue-291622705 From anders.rundgren.net at gmail.com Mon Jan 29 14:15:17 2018 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Mon, 29 Jan 2018 15:15:17 +0100 Subject: Da Capo: JSON "clear text" signatures In-Reply-To: References: Message-ID: <5e1cda3f-4baa-d2b2-c098-c1fd2e6663ea@gmail.com> On 2018-01-29 14:52, Hannes Walln?fer wrote: > Hi Anders, > > I think I lack the context required to understand what you?re asking for. Can you explain how transmitting numbers/doubles in JSON should work and how the static method you?re asking for would enable this? Sure. Signatures depend on that data appears identical on both sides (sender + receiver). If one side outputs the integer 10 as 10.0 (which is OK JSON-wise), the signature will break in an EcmaScript environment where it must be 10 and nothing else. JSON tools would call the proposed static method rather than building their own number serializer. Initially I thought number serialization was a simple problem but that was entirely wrong :-) Fortunately the ECMA folks have the expertize needed and their solution is already supported in billions of devices. Nashorn almost cuts it but only for JavaScript, not Java. > Also, is there a document somewhere describing the IETF standardization work you?re talking about? You will have to wait to next week (when it becomes public), but in the meantime you can take a look at the core "input specifications": https://cyberphone.github.io/doc/security/jose-jcs.html https://cyberphone.github.io/doc/security/jose-jef.html Thanx, Anders > > Thanks, > Hannes > >> Am 28.01.2018 um 10:48 schrieb Anders Rundgren : >> >> The JSON "clear text" signature initiative seems to (finally) be headed for IETF standardization. The plan is having a BOF session at the next IETF in London. >> >> This scheme builds on EcmaScript JSON processing rules for data normalization which only rely on JSON.parse() and JSON.stringify(). >> >> A thorny issue for implementers is though serializing the JSON "Number" type. >> >> An with Node.js, Chrome, Firefox, Safari (unfortunately not entirely compatible...) solution is currently available in "Nashorn": >> http://hg.openjdk.java.net/jdk8/jdk8/nashorn/file/096dc407d310/src/jdk/nashorn/internal/objects/NativeNumber.java >> >> It would be great if such support could for example be included as a static method in java.lang.Double, making Java and EcmaScript/JavaScript 100% interoperable with respect to this feature, the rest is actually close to trivial. >> >> thanx, >> Anders >> https://github.com/OAI/OpenAPI-Specification/issues/1464#issue-291622705 > From fotisl at ssl.com Mon Jan 29 14:30:23 2018 From: fotisl at ssl.com (Fotis Loukos) Date: Mon, 29 Jan 2018 16:30:23 +0200 Subject: Update mechanism for the upcoming trust store In-Reply-To: References: <6cd7d58a-c233-cf45-b80c-2c48fdd5b69e@ssl.com> <6254fadc-06f0-c96a-0abd-69021cbd341d@ssl.com> Message-ID: <700b828c-694e-31ef-7dfe-c88fe33df6a8@ssl.com> On 26/01/2018 11:31 ??, Sean Mullan wrote: > On 1/24/18 5:39 AM, Fotis Loukos wrote: >>> You may not be aware, but the JDK does currently support a mechanism for >>> blacklisting certificates. The lib/security/blacklisted.certs file >>> contains a list of the fingerprints of certificates that are explicitly >>> distrusted. If a root was compromised and added to this file it would no >>> longer be trusted. >> My biggest concern is what you describe below, the dynamic update. >> >>> However, currently there is no mechanism in OpenJDK to dynamically >>> update that file. While I think there is merit in implementing something >>> like that, many challenges would need to be addressed as part of that, >>> for example, where and how does this file get updated, how is it >>> verified, etc. >> The verification step can be implemented as described above. I think >> that the update step requires some design, but I don't think it is that >> difficult. For example, a naive algorithm such as every Monday plus a >> random number of days/hours/minutes in order to avoid heavy traffic >> during the update period would be good for starters. As a first step to >> try a new format, you could even fetch it once during installation and >> provide a means for the user to update it manually. > > One thing we could potentially do initially is to provide a stable https > URL where an updated blacklist could be downloaded, something like what > Mozilla does for OneCRL [1]. This would be an initial step, not the > whole solution of course, but it at least would allow someone to quickly > update their JDK should a certificate need to be distrusted ASAP. > > Let me look into that a bit. > > I think implementing a dynamic solution is more challenging and would > require more design/review, etc but feel free to provide more details on > any additional thoughts or design sketches you might have. I find it pretty important to ensure that the file is also signed and not just served over https. I was wondering if the community runs a private CA, or has access to an HSM that can be used to generate and store a private key that will sign these files. Regards, Fotis > > --Sean > > [1] > https://firefox.settings.services.mozilla.com/v1/buckets/blocklists/collections/certificates/records > > > -- Fotis Loukos, PhD Director of Security Architecture SSL Corp e: fotisl at ssl.com w: https://www.ssl.com From anders.rundgren.net at gmail.com Mon Jan 29 14:46:33 2018 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Mon, 29 Jan 2018 15:46:33 +0100 Subject: Da Capo: JSON "clear text" signatures In-Reply-To: <5A6F346B.6080709@oracle.com> References: <5e1cda3f-4baa-d2b2-c098-c1fd2e6663ea@gmail.com> <5A6F346B.6080709@oracle.com> Message-ID: <6dfd33eb-66bd-a275-cd96-409e07cc558e@gmail.com> On 2018-01-29 15:49, Sundararajan Athijegannathan wrote: > Just to be clear. so.. do you want a toString (static method?) variant > in java.lang.Double class as per this specification? I don't think this is a major issue because all fundamental JSON types anyway needs be dealt with separately or through a super interface. The existing Nashorn method (after upgrade to match ES better) moved to the Java layer would probably be just fine. Anders > > -Sundar > > On 29/01/18, 7:45 PM, Anders Rundgren wrote: >> On 2018-01-29 14:52, Hannes Walln?fer wrote: >>> Hi Anders, >>> >>> I think I lack the context required to understand what you?re asking >>> for. Can you explain how transmitting numbers/doubles in JSON should >>> work and how the static method you?re asking for would enable this? >> >> Sure. Signatures depend on that data appears identical on both sides >> (sender + receiver). >> If one side outputs the integer 10 as 10.0 (which is OK JSON-wise), >> the signature will break in an EcmaScript environment where it must be >> 10 and nothing else. >> JSON tools would call the proposed static method rather than building >> their own number serializer. >> >> Initially I thought number serialization was a simple problem but that >> was entirely wrong :-) >> Fortunately the ECMA folks have the expertize needed and their >> solution is already supported in billions of devices. >> Nashorn almost cuts it but only for JavaScript, not Java. >> >>> Also, is there a document somewhere describing the IETF >>> standardization work you?re talking about? >> >> You will have to wait to next week (when it becomes public), but in >> the meantime you can take a look at the core "input specifications": >> https://cyberphone.github.io/doc/security/jose-jcs.html >> https://cyberphone.github.io/doc/security/jose-jef.html >> >> Thanx, >> Anders >> >>> >>> Thanks, >>> Hannes >>> >>>> Am 28.01.2018 um 10:48 schrieb Anders Rundgren >>>> : >>>> >>>> The JSON "clear text" signature initiative seems to (finally) be >>>> headed for IETF standardization. The plan is having a BOF session >>>> at the next IETF in London. >>>> >>>> This scheme builds on EcmaScript JSON processing rules for data >>>> normalization which only rely on JSON.parse() and JSON.stringify(). >>>> >>>> A thorny issue for implementers is though serializing the JSON >>>> "Number" type. >>>> >>>> An with Node.js, Chrome, Firefox, Safari (unfortunately not entirely >>>> compatible...) solution is currently available in "Nashorn": >>>> http://hg.openjdk.java.net/jdk8/jdk8/nashorn/file/096dc407d310/src/jdk/nashorn/internal/objects/NativeNumber.java >>>> >>>> >>>> It would be great if such support could for example be included as a >>>> static method in java.lang.Double, making Java and >>>> EcmaScript/JavaScript 100% interoperable with respect to this >>>> feature, the rest is actually close to trivial. >>>> >>>> thanx, >>>> Anders >>>> https://github.com/OAI/OpenAPI-Specification/issues/1464#issue-291622705 >>>> >>> >> From p.goovaerts at Conti7.be Wed Jan 24 10:36:10 2018 From: p.goovaerts at Conti7.be (Patrick Goovaerts) Date: Wed, 24 Jan 2018 10:36:10 +0000 Subject: Webservice error - 2 counts of InaccessibleWSDLException - due to JDK update from 112 to 121 Message-ID: Hi, After updating JKD 1.8.0 from u112 to u121, i get errors executing webservices which uses a certificate. The error I get is: com.sun.xml.internal.ws.wsdl.parser.InaccessibleWSDLException: 2 counts of InaccessibleWSDLException In the example I ran the code with u152 but same prob occurs as from u121 Anyone who could help me with this? ==================================== PC - COMMAND PROMPT - JAVA 1_8_00152 ==================================== C:\Data\Kantoor\WebServices\PLDA>"C:\Program Files\Java\jdk8\bin\java" -version java version "1.8.0_152" Java(TM) SE Runtime Environment (build 1.8.0_152-b16) Java HotSpot(TM) 64-Bit Server VM (build 25.152-b16, mixed mode) C:\Data\Kantoor\WebServices\PLDA>"C:\Program Files\JAVA\jdk8\bin\java" -cp WS-Clients.jar;Conti7.jar;Conti7Utilities.jar com.clipper.ws.clients.Plda 2018-01-23 21:39:06.559 com.clipper.ws.clients.Plda Plda(keyStore=C:/Data/kantoor/WebServices/PLDA/PGO_Conti71619.pfx, keyStoreType=pkcs12, keyStorePwd=Conti7Sp0rtlife): Creating WebService Plda object... 2018-01-23 21:39:06.576 com.clipper.ws.clients.Plda Create PldaWebwervice_Service(): Creating Service Exception in thread "main" com.sun.xml.internal.ws.wsdl.parser.InaccessibleWSDLException: 2 counts of InaccessibleWSDLException. java.net.SocketException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext) java.net.SocketException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext) at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.tryWithMex(RuntimeWSDLParser.java:260) at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:231) at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:194) at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:163) at com.sun.xml.internal.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:348) at com.sun.xml.internal.ws.client.WSServiceDelegate.(WSServiceDelegate.java:306) at com.sun.xml.internal.ws.client.WSServiceDelegate.(WSServiceDelegate.java:215) at com.sun.xml.internal.ws.client.WSServiceDelegate.(WSServiceDelegate.java:196) at com.sun.xml.internal.ws.client.WSServiceDelegate.(WSServiceDelegate.java:192) at com.sun.xml.internal.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104) at javax.xml.ws.Service.(Service.java:77) at com.clipper.ws.plda.PldaWebservice_Service.(PldaWebservice_Service.java:51) at com.clipper.ws.clients.Plda.(Plda.java:30) at com.clipper.ws.clients.Plda.main(Plda.java:80) Patrick Goovaerts -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannes.wallnoefer at oracle.com Mon Jan 29 13:52:16 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Mon, 29 Jan 2018 14:52:16 +0100 Subject: Da Capo: JSON "clear text" signatures In-Reply-To: References: Message-ID: Hi Anders, I think I lack the context required to understand what you?re asking for. Can you explain how transmitting numbers/doubles in JSON should work and how the static method you?re asking for would enable this? Also, is there a document somewhere describing the IETF standardization work you?re talking about? Thanks, Hannes > Am 28.01.2018 um 10:48 schrieb Anders Rundgren : > > The JSON "clear text" signature initiative seems to (finally) be headed for IETF standardization. The plan is having a BOF session at the next IETF in London. > > This scheme builds on EcmaScript JSON processing rules for data normalization which only rely on JSON.parse() and JSON.stringify(). > > A thorny issue for implementers is though serializing the JSON "Number" type. > > An with Node.js, Chrome, Firefox, Safari (unfortunately not entirely compatible...) solution is currently available in "Nashorn": > http://hg.openjdk.java.net/jdk8/jdk8/nashorn/file/096dc407d310/src/jdk/nashorn/internal/objects/NativeNumber.java > > It would be great if such support could for example be included as a static method in java.lang.Double, making Java and EcmaScript/JavaScript 100% interoperable with respect to this feature, the rest is actually close to trivial. > > thanx, > Anders > https://github.com/OAI/OpenAPI-Specification/issues/1464#issue-291622705 From tomas at primekey.se Tue Jan 30 08:22:23 2018 From: tomas at primekey.se (Tomas Gustavsson) Date: Tue, 30 Jan 2018 09:22:23 +0100 Subject: PKCS#11 provider issues with min and max size Message-ID: <97ca28d8-8466-9f9f-c19d-567b38f7a0f7@primekey.se> Hi, At some revision in the PKCS#11 provider there was introduced checking of C_GetMechanismInfo min and max sizes. This has turned out to be a bit fragile. Let me give two real world examples: 1. Amazon Cloud HSM report minSize and maxSize for EC keys to 0. The Java PKCS#11 provider will happily take 0 as maxSize and refuse to generate any EC keys at all. Needless to say, without the Java check it would be no problem. 131: C_GetMechanismInfo 2018-01-30 07:52:20.740 [in] slotID = 0x1 CKM_EC_KEY_PAIR_GEN [out] pInfo: CKM_EC_KEY_PAIR_GEN : min:0 max:0 flags:0x10001 ( Hardware KeyPair ) Returned: 0 CKR_OK (we are reporting this to Amazon as well) 2. Thales HSMs (some?) report maxSize for RSA_PKCS key generation as 4096, but will happily generate 8192 bit keys. I.e. the reported maxSize is not true. We have customers who used to generate 8192 bit RSA keys, but after a Java update can not do so anymore, because Java compares against this value. * Suggestions: 1. In the constructor of P11KeyPairGenerator where minKeyLen and maxKeyLen are calculated, never allow maxKeyLen to be less than minKeyLen. I.e. change the part: // auto-adjust default keysize in case it's out-of-range if ((minKeyLen != -1) && (keySize < minKeyLen)) { keySize = minKeyLen; } if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { keySize = maxKeyLen; } To include something like: // auto-adjust default keysize in case it's out-of-range if ((minKeyLen != -1) && (keySize < minKeyLen)) { keySize = minKeyLen; } if ((maxKeyLen != -1) && (maxKeyLen < minKeyLen)) { maxKeyLen = minKeyLen; } if ((maxKeyLen != -1) && (keySize > maxKeyLen)) { keySize = maxKeyLen; } 2. Allow to ignore checking of maxKeyLen by some means, i.e. allow to ignore checking against C_GetMechanismInfo if you know that the HSM does not provide sane values. I.e. an environment variable for example reverting back to the old behavior when these were ignored. Regards, Tomas Gustavsson -- ********** PrimeKey Solutions AB Lundagatan 16, 171 63 Solna, Sweden Mob: +46 (0)707421096 Internet: www.primekey.se Twitter: twitter.com/primekeyPKI ********** From adam.petcher at oracle.com Tue Jan 30 16:52:01 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 30 Jan 2018 11:52:01 -0500 Subject: RFR 8181594: Efficient and constant-time modular arithmetic In-Reply-To: References: Message-ID: <7bd6c1ae-4173-4384-fc57-66d1b185ba56@oracle.com> +core-libs-dev On 1/26/2018 4:06 PM, Adam Petcher wrote: > JBS: https://bugs.openjdk.java.net/browse/JDK-8181594 > Webrev: http://cr.openjdk.java.net/~apetcher/8181594/webrev.00/ > > This is a code review for the field arithmetic that will be used in > implementations of X25519/X448 key agreement, the Poly1305 > authenticator, and EdDSA signatures. I believe that the library has > all the features necessary for X25519/X448 and Poly1305, and I expect > at most a couple of minor enhancements will be required to support > EdDSA. There is no public API for this library, so we can change it in > the future to suit the needs of new algorithms without breaking > compatibility with external code. Still, I made an attempt to clearly > structure and document the (internal) API, and I want to make sure it > is understandable and easy to use. > > This is not a general-purpose modular arithmetic library. It will only > work well in circumstances where the sequence of operations is > restricted, and where the prime that defines the field has some useful > structure. Moreover, each new field will require some field-specific > code that takes into account the structure of the prime and the way > the field is used in the application. The initial implementation > includes a field for Poly1305 and the fields for X25519/X448 which > should also work for EdDSA. > > The benefits of using this library are that it is much more efficient > than using similar operations in BigInteger. Also, many operations are > branch-free, making them suitable for use in a side-channel resistant > implementation that does not branch on secrets. > > To provide some context, I have attached a code snippet describing how > this library can be used. The snippet is the constant-time Montgomery > ladder from my X25519/X448 implementation, which I expect to be out > for review soon. X25519/X448 only uses standard arithmetic operations, > and the more unusual features (e.g. add modulo a power of 2) are > needed by Poly1305. > > The field arithmetic (for all fields) is implemented using a 32-bit > representation similar to the one described in the Ed448 paper[1] (in > the "Implementation on 32-bit platforms" section). Though my > implementation uses signed limbs, and grade-school multiplication > instead of Karatsuba. The argument for correctness is essentially the > same for all three fields: the magnitude of each 64-bit limb is at > most 2^(k-1) after reduction, except for the last limb which may have > a magnitude of up to 2^k. The values of k are between 26 to 28 > (depending on the field), and we can calculate that the maximum > magnitude for any limb during an add-multiply-carry-reduce sequence is > always less than 2^63. Therefore, no overflow occurs and all > operations are correct. > > Process note: this enhancement is part of JEP 324 (Key Agreement with > Curve25519 and Curve448). When this code review is complete, nothing > will happen until all other work for this JEP is complete, and the JEP > is accepted as part of some release. This means that this code will be > pushed to the repo along with the X25519/X448 code that uses it. > > [1] https://eprint.iacr.org/2015/625.pdf > > > -------------- next part -------------- private IntegerModuloP_Base pointMultiply(byte[] k, IntegerModuloP u){ IntegerModuloP x_1 = u; MutableIntegerModuloP x_2 = one.mutable(); MutableIntegerModuloP z_2 = zero.mutable(); MutableIntegerModuloP x_3 = u.mutable(); MutableIntegerModuloP z_3 = one.mutable(); int swap = 0; // Variables below are reused to avoid unnecessary allocation // They will be assigned in the loop, so initial value doesn't matter MutableIntegerModuloP m1 = zero.mutable(); MutableIntegerModuloP DA = zero.mutable(); MutableIntegerModuloP E = zero.mutable(); MutableIntegerModuloP a24_times_E = zero.mutable(); for(int t = params.getBits() - 1; t >= 0; t--){ int k_t = bitAt(k, t); swap = swap ^ k_t; x_2.conditionalSwapWith(x_3, swap); z_2.conditionalSwapWith(z_3, swap); swap = k_t; // A(m1) = x_2 + z_2 m1.setValue(x_2).setSum(z_2); // D = x_3 - z_3 // DA = D * A(m1) DA.setValue(x_3).setDifference(z_3).setProduct(m1); // AA(m1) = A(m1)^2 m1.setSquare(); // B(x_2) = x_2 - z_2 x_2.setDifference(z_2); // C = x_3 + z_3 // CB(x_3) = C * B(x_2) x_3.setSum(z_3).setProduct(x_2); // BB(x_2) = B^2 x_2.setSquare(); // E = AA(m1) - BB(x_2) E.setValue(m1).setDifference(x_2); // compute a24 * E using SmallValue a24_times_E.setValue(E); a24_times_E.setProduct(a24); // assign results to x_3, z_3, x_2, z_2 // x_2 = AA(m1) * BB x_2.setProduct(m1); // z_2 = E * (AA(m1) + a24 * E) z_2.setValue(m1).setSum(a24_times_E).setProduct(E); // z_3 = x_1*(DA - CB(x_3))^2 z_3.setValue(DA).setDifference(x_3).setSquare().setProduct(x_1); // x_3 = (CB(x_3) + DA)^2 x_3.setSum(DA).setSquare(); } x_2.conditionalSwapWith(x_3, swap); z_2.conditionalSwapWith(z_3, swap); // return (x_2 * z_2^(p - 2)) return x_2.setProduct(z_2.multiplicativeInverse()); } From joe.darcy at oracle.com Tue Jan 30 17:42:57 2018 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 30 Jan 2018 09:42:57 -0800 Subject: JDK 11 RFR of JDK-8196414: Update ProviderVersionCheck.java to pass on updated JDK versions Message-ID: <97895015-0ad6-5a14-d5a8-bd68f60afee7@oracle.com> Hello, The test ??? java/security/Provider/ProviderVersionCheck.java has a version-check that is hard coded; therefore, it has to be updated with each major JDK update. If the test made its check based on the runtime version, no explicit update would be needed. Please review the patch below which changes the test as suggested. This change is part of the set of test updates to support increasing the version number in JDK 11. Thanks, -Joe diff -r bcce1fa183e7 test/jdk/java/security/Provider/ProviderVersionCheck.java --- a/test/jdk/java/security/Provider/ProviderVersionCheck.java Mon Jan 29 17:58:12 2018 +0100 +++ b/test/jdk/java/security/Provider/ProviderVersionCheck.java Tue Jan 30 09:39:51 2018 -0800 @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 2013, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2013, 2018, Oracle and/or its affiliates. All rights reserved. ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. ? * ? * This code is free software; you can redistribute it and/or modify it @@ -27,7 +27,7 @@ ?/* ? * @test - * @bug 8030823 8130696 + * @bug 8030823 8130696 8196414 ? * @run main/othervm ProviderVersionCheck ? * @summary Verify all providers in the default Providers list have the proper ? * version for the release @@ -42,7 +42,7 @@ ???????? for (Provider p: Security.getProviders()) { ???????????? System.out.print(p.getName() + " "); -??????????? if (p.getVersion() != 10.0d) { +??????????? if (p.getVersion() != (double)Runtime.version().feature()) { ???????????????? System.out.println("failed. " + "Version received was " + ???????????????????????? p.getVersion()); ???????????????? failure = true; From sean.mullan at oracle.com Tue Jan 30 18:03:23 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 30 Jan 2018 13:03:23 -0500 Subject: JDK 11 RFR of JDK-8196414: Update ProviderVersionCheck.java to pass on updated JDK versions In-Reply-To: <97895015-0ad6-5a14-d5a8-bd68f60afee7@oracle.com> References: <97895015-0ad6-5a14-d5a8-bd68f60afee7@oracle.com> Message-ID: <02db76fa-c9ca-5094-0a41-3c62c471b139@oracle.com> Does Runtime.version().feature() return the same value as the "java.specification.version" property? (see sun.security.util.SecurityConstants.PROVIDER_VER). That is the value that the JDK security providers use as their version. If not, this test may fail when we bump up the version to 11 and we probably would want to also set SecurityConstants.PROVIDER_VER to the value of Runtime.version().feature() instead (you could include that as part of this fix). --Sean On 1/30/18 12:42 PM, joe darcy wrote: > Hello, > > The test > > ??? java/security/Provider/ProviderVersionCheck.java > > has a version-check that is hard coded; therefore, it has to be updated > with each major JDK update. If the test made its check based on the > runtime version, no explicit update would be needed. > > Please review the patch below which changes the test as suggested. This > change is part of the set of test updates to support increasing the > version number in JDK 11. > > Thanks, > > -Joe > > > diff -r bcce1fa183e7 > test/jdk/java/security/Provider/ProviderVersionCheck.java > --- a/test/jdk/java/security/Provider/ProviderVersionCheck.java Mon Jan > 29 17:58:12 2018 +0100 > +++ b/test/jdk/java/security/Provider/ProviderVersionCheck.java Tue Jan > 30 09:39:51 2018 -0800 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2013, 2017, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2013, 2018, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -27,7 +27,7 @@ > > ?/* > ? * @test > - * @bug 8030823 8130696 > + * @bug 8030823 8130696 8196414 > ? * @run main/othervm ProviderVersionCheck > ? * @summary Verify all providers in the default Providers list have > the proper > ? * version for the release > @@ -42,7 +42,7 @@ > > ???????? for (Provider p: Security.getProviders()) { > ???????????? System.out.print(p.getName() + " "); > -??????????? if (p.getVersion() != 10.0d) { > +??????????? if (p.getVersion() != (double)Runtime.version().feature()) { > ???????????????? System.out.println("failed. " + "Version received was " + > ???????????????????????? p.getVersion()); > ???????????????? failure = true; > From joe.darcy at oracle.com Tue Jan 30 18:19:55 2018 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 30 Jan 2018 10:19:55 -0800 Subject: JDK 11 RFR of JDK-8196414: Update ProviderVersionCheck.java to pass on updated JDK versions In-Reply-To: <02db76fa-c9ca-5094-0a41-3c62c471b139@oracle.com> References: <97895015-0ad6-5a14-d5a8-bd68f60afee7@oracle.com> <02db76fa-c9ca-5094-0a41-3c62c471b139@oracle.com> Message-ID: Hi Sean, On 1/30/2018 10:03 AM, Sean Mullan wrote: > Does Runtime.version().feature() return the same value as the > "java.specification.version" property? (see > sun.security.util.SecurityConstants.PROVIDER_VER). > > That is the value that the JDK security providers use as their > version. If not, this test may fail when we bump up the version to 11 > and we probably would want to also set SecurityConstants.PROVIDER_VER > to the value of Runtime.version().feature() instead (you could include > that as part of this fix). > The following patch based on java.specification.version @@ -42,7 +42,8 @@ ???????? for (Provider p: Security.getProviders()) { ???????????? System.out.print(p.getName() + " "); -??????????? if (p.getVersion() != 10.0d) { +??????????? String specVersion = System.getProperty("java.specification.version"); +??????????? if (p.getVersion() != Double.parseDouble(specVersion)) { ???????????????? System.out.println("failed. " + "Version received was " + ???????????????????????? p.getVersion()); ???????????????? failure = true; passes both on JDK 10 builds and an internal JDK 11 build with the version updated. Thanks, -Joe From sean.mullan at oracle.com Tue Jan 30 18:29:36 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 30 Jan 2018 13:29:36 -0500 Subject: JDK 11 RFR of JDK-8196414: Update ProviderVersionCheck.java to pass on updated JDK versions In-Reply-To: References: <97895015-0ad6-5a14-d5a8-bd68f60afee7@oracle.com> <02db76fa-c9ca-5094-0a41-3c62c471b139@oracle.com> Message-ID: <6ca8cb81-b4cf-ba7d-3319-bd4991b23361@oracle.com> On 1/30/18 1:19 PM, joe darcy wrote: > Hi Sean, > > On 1/30/2018 10:03 AM, Sean Mullan wrote: >> Does Runtime.version().feature() return the same value as the >> "java.specification.version" property? (see >> sun.security.util.SecurityConstants.PROVIDER_VER). >> >> That is the value that the JDK security providers use as their >> version. If not, this test may fail when we bump up the version to 11 >> and we probably would want to also set SecurityConstants.PROVIDER_VER >> to the value of Runtime.version().feature() instead (you could include >> that as part of this fix). >> > > The following patch based on java.specification.version > > @@ -42,7 +42,8 @@ > > ???????? for (Provider p: Security.getProviders()) { > ???????????? System.out.print(p.getName() + " "); > -??????????? if (p.getVersion() != 10.0d) { > +??????????? String specVersion = > System.getProperty("java.specification.version"); > +??????????? if (p.getVersion() != Double.parseDouble(specVersion)) { > ???????????????? System.out.println("failed. " + "Version received was " + > ???????????????????????? p.getVersion()); > ???????????????? failure = true; > > passes both on JDK 10 builds and an internal JDK 11 build with the > version updated. Ok, good to know. I'm fine with this change. --Sean From sean.mullan at oracle.com Wed Jan 31 16:32:59 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 31 Jan 2018 11:32:59 -0500 Subject: Webservice error - 2 counts of InaccessibleWSDLException - due to JDK update from 112 to 121 In-Reply-To: References: Message-ID: <8e5c371f-1095-2970-1915-26ddb8de2f35@oracle.com> On 1/24/18 5:36 AM, Patrick Goovaerts wrote: > Hi, > > After updating JKD 1.8.0 from u112 to u121, i get errors executing > webservices which uses a certificate. > > The error I get is: > com.sun.xml.internal.ws.wsdl.parser.InaccessibleWSDLException: 2 counts > of InaccessibleWSDLException > > In the example I ran the code with u152 but same prob occurs as from u121 > > Anyone who could help me with this? Not sure, but can you get a more complete stack trace which would show the underlying cause of the NoSuchAlgorithmException? You could also try adding -Djava.security.debug=all -Djavax.net.debug=all to your command line to see if anything interesting comes up in the debug messages. Also, this is not a support forum, but hopefully those tips above will get you on the right track. If you are still having trouble and can come up with a reproducible test case that we can run, you can file a bug at https://bugreport.java.com/ --Sean > > ==================================== > > PC - COMMAND PROMPT - JAVA 1_8_00152 > > ==================================== > > C:\Data\Kantoor\WebServices\PLDA>"C:\Program Files\Java\jdk8\bin\java" > -version > > java version "1.8.0_152" > > Java(TM) SE Runtime Environment (build 1.8.0_152-b16) > > Java HotSpot(TM) 64-Bit Server VM (build 25.152-b16, mixed mode) > > C:\Data\Kantoor\WebServices\PLDA>"C:\Program Files\JAVA\jdk8\bin\java" > -cp WS-Clients.jar;Conti7.jar;Conti7Utilities.jar > com.clipper.ws.clients.Plda > > 2018-01-23 21:39:06.559 com.clipper.ws.clients.Plda > Plda(keyStore=C:/Data/kantoor/WebServices/PLDA/PGO_Conti71619.pfx, > keyStoreType=pkcs12, keyStorePwd=Conti7Sp0rtlife): Creating WebService > Plda object... > > 2018-01-23 21:39:06.576 com.clipper.ws.clients.Plda Create > PldaWebwervice_Service(): Creating Service > > Exception in thread "main" > com.sun.xml.internal.ws.wsdl.parser.InaccessibleWSDLException: 2 counts > of InaccessibleWSDLException. > > java.net.SocketException: java.security.NoSuchAlgorithmException: Error > constructing implementation (algorithm: Default, provider: SunJSSE, > class: sun.security.ssl.SSLContextImpl$DefaultSSLContext) > > java.net.SocketException: java.security.NoSuchAlgorithmException: Error > constructing implementation (algorithm: Default, provider: SunJSSE, > class: sun.security.ssl.SSLContextImpl$DefaultSSLContext) > > ??????? at > com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.tryWithMex(RuntimeWSDLParser.java:260) > > ??????? at > com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:231) > > ??????? at > com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:194) > > ??????? at > com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:163) > > ??????? at > com.sun.xml.internal.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:348) > > ??????? at > com.sun.xml.internal.ws.client.WSServiceDelegate.(WSServiceDelegate.java:306) > > ??????? at > com.sun.xml.internal.ws.client.WSServiceDelegate.(WSServiceDelegate.java:215) > > ??????? at > com.sun.xml.internal.ws.client.WSServiceDelegate.(WSServiceDelegate.java:196) > > ??????? at > com.sun.xml.internal.ws.client.WSServiceDelegate.(WSServiceDelegate.java:192) > > ??????? at > com.sun.xml.internal.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104) > > ??????? at javax.xml.ws.Service.(Service.java:77) > > ??????? at > com.clipper.ws.plda.PldaWebservice_Service.(PldaWebservice_Service.java:51) > > ??????? at com.clipper.ws.clients.Plda.(Plda.java:30) > > ??????? at com.clipper.ws.clients.Plda.main(Plda.java:80) > > *Patrick Goovaerts* > > ** >