RFR JDK-8075286: Additional tests for signature algorithm OIDs and transformation string

Hi Security developers, I have a security test bug https://bugs.openjdk.java.net/browse/JDK-8075286, which adds more cases for NSA Suite B algorithms in jdk repo. Please review this patch at http://cr.openjdk.java.net/~fyuan/jjiang/8075286/webrev.00/ Every comment is appreciated. Best Regards

RFR 8129789: implies() of ServicePermission and DelegationPermission underspecified

Please review this spec clarification at http://cr.openjdk.java.net/~weijun/8129789/webrev.00 Thanks Max

Re: RFR JDK-8134364: Add defensive copies to get/set methods for OCSPNonceExtension

Hi Sean, et al., I've updated the review to incorporate Sean's comments. Sean, I was able to remove encodeInternal() and make it into a one-liner inside each of the ctors, so that shrunk things down a bit more which is nice. Let me know what you think. Webrev: http://cr.openjdk.java.net/~j

[9] RFR: 8134708: Certpath validation fails to load certs and CRLs if AIA and CRLDP extensions point to LDAP resources

Hello, Please review this fix for 9. Certpath validation fails to load certs and CRLs if AIA and CRLDP extensions point to LDAP resources. This happens because LDAPCertStore accepts only instances of LDAPCertStoreParameters and URICertStoreParameters classes, but sun.security.provider.certpa

Re: RFR JDK-8134364: Add defensive copies to get/set methods for OCSPNonceExtension

Hi Sean, thanks for the comments, they all sound very reasonable to me. I'll get on fixing those now. WRT the cloning, I figured that since the class had public visibility and the methods in question were public methods that it was better to err on the side of safety, even with the class bein

Re: RFR: 8134869: AARCH64: GHASH intrinsic is not optimal

Very nice rewrite. Looks good. Thanks, Vladimir On 9/1/15 7:45 AM, Andrew Haley wrote: I've been looking at the intrinsic we have for GHASH. While it is decent as it goes, its performance is considerably worse than some other implementations of GHASH on the same processor. Thanks are due to A

Re: RFR JDK-8134364: Add defensive copies to get/set methods for OCSPNonceExtension

On 08/28/2015 09:25 PM, Jamil Nimeh wrote: Hello all, I've removed the CertAttrSet interface from OCSPNonceExtension and trimmed away a few unneeded methods. As a result the class is immutable now. Looks a lot cleaner. Strictly speaking, the cloning is not necessary since this is an internal

Re: GCM performance and Unsafe byte array accesses

On 09/01/2015 04:42 PM, Anthony Scarpino wrote: > Does your alignment changes affect x86 only or should this help all > architectures? It does the best thing it can on every architecture. On those which support unaligned accesses, it uses them; if not, it doesn't. But there is a very cool optim

Re: GCM performance and Unsafe byte array accesses

Hi Andrew, Does your alignment changes affect x86 only or should this help all architectures? In general I don't see a disadvantage and that it could be expanded to other places in crypto too. But I have think about the effects on sparc, so that would need to be tested. Right now the sparc in

Re: [9] RFR 8133801: sun/security/pkcs11/Provider/ConfigShortPath.java failed in jigsaw nightly at Windows

Looks good to me. --Sean On 08/31/2015 07:49 PM, Valerie Peng wrote: Hi, Can someone please help reviewing this regression test update? http://cr.openjdk.java.net/~valeriep/8133801/webrev.00/ Both tests are updated to not using private SunPKCS11 constructors. The test Absolute.java has been

RFR: 8134869: AARCH64: GHASH intrinsic is not optimal

I've been looking at the intrinsic we have for GHASH. While it is decent as it goes, its performance is considerably worse than some other implementations of GHASH on the same processor. Thanks are due to Alexander Alexeev who did a fine job implementing the x86 algorithm on AArch64, but the resu