Re: PKCS11 generateKeyPair with alias

I would expect you can actually store the key on a PKCS11 backed Keystore, what would be the natural API (although it’s hard for the provider to implement it if it can’t use temporary handles like this) Gruss Bernd -- http://bernd.eckenfels.net Von: -989298816m

Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable

Hallo Sean, The change looks fine to me, but if you have to roll another version maybe you could add a comment on this line to explain its purpose. Since this line is changed in the patch it would be a good time: System.java:350 sm.checkPackageAccess("java.lang"); Is that some kind of warm-

Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable

There is another way, by reusing the existing security manager property with a new keyword („default“ is already a well known value) one could implement the stable suppression of the SM without actually needing a new property. It also avoids unclear meaning of denied but specified SM: java.secu

Re: Conceptual feedback on new ECC JEP

Hello, I think I missed it, but where is the conversion on BigInteger branching on key material? Isn’t this only branching on effective constant values? Or are you concerned about Spectre-type problems? Besides that I totally agree on the idea of having a more secure implementation which can b

Re: Jar's CodeSigner null on Java 10, non-null on Java 8

What are the Hashes, signatures algorithms and key Sizes? Maybe one of the newer security properties turning those off? Does it have a timestamp? Gruss Bernd -- http://bernd.eckenfels.net Von: -2123340816m Auftrag von Gesendet: Freitag, Oktober 5, 2018 10:13 PM An

Re: DSA default algorithm for keytool -genkeypair. Bad choice?

It might not apply to this specific default but in the past DSA was often chosen (over RSA) as a default as it was regarded as less suspicious to been understood as an encryption capable algorithm (as opposed to RSA). But of course that thinking was never correct and the justification for interp

Re: Fluent builder API for JCA/JSSE classes

Thats very cool! Maybe this is the right thread to discuss the future of the sun.security.x509 package. Currently your implementation will only work if that package is exported. The Depth of implementation of those classes however would be a nice Addition to an (optional?) API. Gruss Bernd -

Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

http://cr.openjdk.java.net/~dlong/8212605/webrev.1/src/java.base/share/classes/java/security/AccessController.java.udiff.html In checkContext should the security manager be null checked first instead of last to optimize for the typical case? (If the side effects in that expression are desired it

Re: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation

Hello, I would agree ignoring an (conflicting) option adds confusion. When specifying a curve is a new feature we don’t need to worry about beeing compatible, therefore I would forbid mixing curve names and keysize at all (even when the size matches). I guess we cannot remove the option to on

Re: RFR: 8213952: Relax DNSName restriction as per RFC 1123

You could also add (a..b, false) and (.a, false), (a., false) to the testcases. I noticed that there are different types of Exception messages (DNS name, DNSName, DNS Name or name constrained, DNS name and SAN), would be good if all of them have the same keyword? Gruss Bernd -- http://bernd.eck

Re: RFR: 8213952: Relax DNSName restriction as per RFC 1123

nicer validation reports without relying on the message or Stacktraces. Gruss Bernd -- http://bernd.eckenfels.net Von: Seán Coffey Gesendet: Freitag, November 16, 2018 5:15 PM An: Bernd Eckenfels; security-dev@openjdk.java.net Betreff: Re: RFR: 8213952: Relax DNSName

Re: RFR(S)JDK-8214074: Ghash optimization using AVX instructions

Hello, What is the purpose of setting some of them to 0 twice? (It’s a new array which should be all-0 anyway.) + for (int i = 1; i < 9 ; i++) { +subkeyHtbl[2*i] = 0; +subkeyHtbl[2*i+1] = 0; +} Also, is the subkeyH no longer be needed (or can be redesigned t

Re: AES ctr benchmark performance

Quick Question, why did you Need to switch it on and out of curiosity how do the times look like when you switch NI off? Greetings Bernd -- http://bernd.eckenfels.net Von: Anthony Scarpino Gesendet: Montag, 3. Dezember 2018 21:13 An: Kasper Janssens; security-dev@openjdk.java.net Betreff: Re: A

Re: AES ctr benchmark performance

Gesendet: Montag, 3. Dezember 2018 21:37 An: Bernd Eckenfels; security-dev@openjdk.java.net Betreff: Re: AES ctr benchmark performance Very slow.. Roughly 181k ops/sec vs 6100 ops/sec, for 16k datasize. As far as why there is a switch, mostly debugging or possible bugs in hotspot that cause the

Re: AES ctr benchmark performance

Hello, and to partially answer myself: the UnlockDiagnostics is needed for Java 9+ Gruss Bernd -- http://bernd.eckenfels.net Von: Anthony Scarpino Gesendet: Montag, 3. Dezember 2018 21:37 An: Bernd Eckenfels; security-dev@openjdk.java.net Betreff: Re: AES ctr benchmark performance Very slow

Re: RFR (12): 8207258: Distrust TLS server certificates anchored by Symantec Root CAs

Woha, having a specific property named after an brand looks awfully specific and even hostile. (Yes it can be removed in a future version when all existing certs are expected to expire, but having code patches distributed for such policy enforcement does look like a heavy gun) Won’t it be a bet

Re: RFR (12): 8207258: Distrust TLS server certificates anchored by Symantec Root CAs

Actually I was referring to the property name in the issue, did not notice that the description differs from the patch, sorry. Gruss Bernd -- http://bernd.eckenfels.net

Re: RFR JDK-7092821 "java.security.Provider.getService() is synchronized and became scalability bottleneck"

Maybe a comment should point to the description of this pattern (if it applies): https://www.oracle.com/technetwork/java/seccodeguide-139067.html#4-5 Gruss Bernd Gruss Bernd -- http://bernd.eckenfels.net Von: security-dev im Auftrag von Valerie Peng Gesendet:

Re: 12 RFR(M) 8214583: AccessController.getContext may return wrongvalue after JDK-8212605

In a related matter, are the existing tests reliable to detect the Situation (at least for the Default runtime/compiler behavior). i.e. are the testcases covering stack Evaluation in a compiled context where EA would elimiiminate it? Gruss Bernd -- http://bernd.eckenfels.net Von: dean.l...@ora

Re: 8217579: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is gone after 8211883

Hello Sean, Maybe you also want to change comment and name of the SUPPORTE_DDEFAULT Array to „SUPPORTED_LIMITED“ since Unlimited is now Default? private final static String[] ENABLED_DEFAULT …. // supported ciphersuites using default JCE policy jurisdiction files // AES/256 unavail

Re: Signed JCE and providers jars

The OpenJDK JCA does not do provider signature checking. So you can install your own providers and don’t need to sign them. Gruss Bernd -- http://bernd.eckenfels.net Von: security-dev im Auftrag von David Penick Gesendet: Montag, Februar 4, 2019 11:18 AM An: s

Re: CSR Review Request, JDK-8163326, The default enabled cipher suites should prefer forward secrecy

I am not clear on what would „preferred in current default context“ mean. Does that mean it preferred the PFS ciphers anyway.. for suggested order in client handshake? as server? And what would be the non-Default context. Is this „TLS“ context? Gruss Bernd -- http://bernd.eckenfels.net ___

Re: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ ) ignoresthe provider argument.

Looking at the patch it seems obvious that this functionality was intentional at least for having a PKCS11 MAC. Do we really want to removbe that Option and if yes des it require some form of aproval? (I think the change is good in General but that case Needs to be decided). Since this is relae

AW: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ )ignoresthe provider argument.

a JCE PBKDF2 on a JVM where BC FIPS has higher prio would be wrong anyway. I thin I havent seen what the case for the init falure in BC MAC was, is this also key related? Gruss Bernd -- http://bernd.eckenfels.net Von: Jamil Nimeh Gesendet: Donnerstag, 14. März 2019 17:18 An: Bernd Eckenfels

Re: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_)ignoresthe provider argument.

, the FIPS provisions are more sad in that case…) Gruss Bernd -- http://bernd.eckenfels.net Von: Jamil Nimeh Gesendet: Donnerstag, 14. März 2019 18:16 An: Bernd Eckenfels; OpenJDK Dev list Betreff: Re: AW: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_)ignoresthe provider argument

Re: CSR Review Request, JDK-8163326, The default enabled cipher suites should prefer forward secrecy

view Request, JDK-8163326, The default enabled cipher suites should prefer forward secrecy Hi, I extended this CSR to cover more update, and update per the comments. Please let me know your concerns by the end of March 21, 2019. Thanks, Xuelei On 3/6/2019 3:41 PM, Bernd Eckenfels wrote: > I am no

Re: RFR 6722928: Support SSPI as a native GSS-API provider

Just to add another aspect to the discussion, there are at least 3 DLLs out there which implement this functionality (Microsoft’s JDBC driver, jTDS driver and Waffle) + commercial solutions as we have heared. All of them are used to allow authenticating the current user against services (mostly

Re: RFR [13] JDK-8221882: Use fiber-friendly java.util.concurrent.locks in JSSE

Hello, There are a few places where a synchronized method is freed up w/o new lock, which is generally a good thing but I wonder if there is a justification available why it is no problem (DTLSInputRecord vs. DTLSOutputRecord). Is the DCL In EphemeralKepair Safe, I am not sure how arrays and no

Re: JNI Signal Chaining and OWASP (Security)

Just to state the obvious, the LD_PRELOAD risk does not go away when you don’t use the feature. I think this scan result should be ignored (at best). It is more a weakness of the Linux bintools/ld and not your extension. (In normal usage there is no risk as an attacker who can modify the environ

Refresh cacert File?

hello, I think it was discussed on security-dev before but did not result in some action as far as I understand it. Currently the „cacert“ file shipped with 8u upstream builds is a bit outdated. It contains multiple expired certificates and misses latest additions. Also I noted there are mult

Re: Refresh cacert File?

, April 18, 2019 10:34 AM An: Bernd Eckenfels; jdk8u-...@openjdk.java.net Cc: security-dev@openjdk.java.net Betreff: Re: Refresh cacert File? Hi, On Wed, 2019-04-17 at 22:43 +, Bernd Eckenfels wrote: > hello, > > I think it was discussed on security-dev before but did not result

Re: RFR 8223063: Support CNG RSA keys

Max, would it make sense to specify ` -csp "Microsoft Software Key Storage Provider"` to make sure it stores the key in a CNG KSP? (I am not sure what the default provider is). Also maybe make the key non-exportable to make sure key-handles are actually used for the operations? Gruss Bernd --

Re: Request for Review [14] JDK-8226976, SessionTimeOutTests uses == operator for String value check

Also the `is*` prefix would point to a boolean, that’s maybe a cleaner data type than a case sensitive string? -- http://bernd.eckenfels.net Von: security-dev im Auftrag von Xuelei Fan Gesendet: Montag, Juli 1, 2019 6:44 PM An: security-dev@openjdk.java.net B

Re: RFR [11] CSR for "Add Brainpool ECC support (RFC 5639)"

0. After > this brainpool support is integrated, it'll be easier to re-evaluate > these. > > > As for PKCS11, Tobias tested this against a 3rd party PKCS11 library and > the result is positive if I recall correctly. > > > Thanks, > Valerie > > > On

Re: the GMT timestamp given in the trace is sometimes wrong

It would make sense to no longer calculate and print the timestamp in the debug log if we don’t want it to be relied upon. This would be less missleading (and mopst likely the shifting logic can be removed?) -- http://bernd.eckenfels.net Von: security-dev im A

Re: RFR [14] 8214483: Remove algorithms that use MD5, DES, or ECB from security requirements

Hello, While it is probably a good thing to not use ECB I can imagine you actually need it to implement single-block operations, so I am not sure if it’s a good idea if any general purpose JVM does not provide AES/ECB or RSA/ECB? (Maybe a new raw single block mode instead?) For example TLS1.2

Microsoft LDAP Channel Binding

Hello, Microsoft just released an Security Advisory, announcing that upcoming Windows Server Versions will turn on mandatory TLS Channel Binding (and turn off simple binds with mandatory SASL signing) on LDAP Servers. They also reminded Administrators to install the KB patch and turn the harden

Re: Microsoft LDAP Channel Binding

-kerberos/pull/92 Gruss Bernd -- http://bernd.eckenfels.net Von: Michael Osipov <1983-01...@gmx.net> Gesendet: Mittwoch, Dezember 18, 2019 6:37 PM An: Bernd Eckenfels; security-dev@openjdk.java.net Betreff: Re: Microsoft LDAP Channel Binding Am 2019-12-18 um

Re: Microsoft LDAP Channel Binding

Here is a related bug https://bugs.openjdk.java.net/browse/JDK-8208301 for ADFS. Gruss Bernd -- http://bernd.eckenfels.net Von: Bernd Eckenfels Gesendet: Mittwoch, Dezember 18, 2019 4:29 AM An: security-dev@openjdk.java.net Betreff: Microsoft LDAP Channel

Re: Microsoft LDAP Channel Binding

versible (and a new password must be set). Next will be testing with TLS (and channel binding) once I get the LDAP certificate set up for this. -- http://bernd.eckenfels.net Von: Michael Osipov <1983-01...@gmx.net> Gesendet: Mittwoch, Dezember 18, 2019 6:37 P

Re: LDAP Channel Binding

Hello, Some updates: Microsoft moved their automatic update of the LDAP policies in Windows Server updates to March 2020 (but still recommend to activate it earlier). And I did some tests: when you turn on the mandatory LDAP Signing, then simple binds or Digest-md5 binds over LDAP are rejected

Re: LDAP Channel Binding

Von: Michael Osipov <1983-01...@gmx.net> Gesendet: Saturday, January 18, 2020 9:39:08 PM An: Bernd Eckenfels ; security-dev@openjdk.java.net Betreff: Re: LDAP Channel Binding Am 2020-01-16 um 11:32 schrieb Bernd Eckenfels: > Hello, > > Some updates

Re: LDAP Channel Binding

r 19, 2020 11:15 AM An: Bernd Eckenfels Cc: security-dev@openjdk.java.net Betreff: Re: LDAP Channel Binding Am 2020-01-19 um 08:02 schrieb Bernd Eckenfels: > You said it is confusing, but the bug you mentioned is only a valid > feature request, it does not talk about failing binds. I would

Re: LDAP Channel Binding

Von: Michael Osipov <1983-01...@gmx.net> Gesendet: Sonntag, Januar 19, 2020 11:15 AM An: Bernd Eckenfels Cc: security-dev@openjdk.java.net Betreff: Re: LDAP Channel Binding Am 2020-01-19 um 08:02 schrieb Bernd Eckenfels: > You said it is confusing, but the bug you mentioned

Re: LDAP Channel Binding

an additional check condition if the new APIs are enough to handle that. Gruss Bernd -- http://bernd.eckenfels.net Von: Michael Osipov <1983-01...@gmx.net> Gesendet: Sunday, February 16, 2020 11:02:16 AM An: Weijun Wang Cc: Bernd Eckenfels ; securi

Re: LDAP Channel Binding

could actually happen by extending GSS-SPNEGO, but that would really be a strange layering of multiple security mechanisms. Gruss Bernd -- http://bernd.eckenfels.net Von: Weijun Wang Gesendet: Dienstag, Februar 18, 2020 3:18 PM An: Bernd Eckenfels Cc: security-

Re: LDAP Channel Binding

Just a small addition, cause I found some more details (but still not enough). there seems to be some precedence for tls-server-endpoint instead, which would be I guess a bit easier to produce: https://blogs.msdn.microsoft.com/openspecification/2013/03/26/ntlm-and-channel-binding-hash-aka-extend

Re: [15] RFR: 8238560: Cleanup and consolidate algorithms in the jdk.tls.legacyAlgorithms security property

Hello Sean, Are the separate entries for 3DES and DES needed or can they also be collapsed? BTW i am always unsre about the interactions of setting the Protocol and the enabled ciphers so I am in the habit to set the protocols before using getEnabled or setting enabled ciphers. I guess it makes

Re: [15] RFR 8172680: Support SHA-3 based Hmac algorithms

Hello Valerie. In MacKAT 121 you would get a NPE if the catch prints the skip message, probably needs an additional return; guard? The BAOS default length change in parse() was not immediately clear to me? (Maybe next s. Base64?) BTW It is good to see that you also add truncated SHA512 variant

Re: NPE is used in javax.security.auth.Subject for flowcontrol

Hello, I would agree with the interpretation that the NPE is not mandatory. But even if we keep it, the actual problem in addAll() should be fixed? There is no point in calling contains(null) on a SecureSet, right? Gruss Bernd -- http://bernd.eckenfels.net Von:

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

Not completely sure about which of the involved apIs have what possible extensions. Maybe we can somehow make two mechanisms one which is the compatible default and one would be the rfc compliant method. Then SASL can be configured and use different mechanism names with a new propert? That would

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

LdapCtxt: 2568 /** 2569 * Sets the read timeout value 2570 */ 2571 private void setChannelBindingType(String cbTypeProp) { Not sure if that javadoc is the right one? And I also wonder if enforcing the timeout is needed, and if yes if it should be documented why. Was not obv

Re: [RFR] 8229148: SSLSession.invalidate() does not invalidate stateless tickets

Hello, The change seems reasonable, but should there maybe a method to refresh temporary keys used for those session tokens - I.e. "invalidate all" and link to that so specific implementations are encourages to offer such an API. Gruss Bernd -- http://bernd.eckenfels.net ___

KWP instead of AESWrap

Hello, JCE implements the AESWrap cipher, but it's does not offer the KWP mode of NIST 800-38F. KW and KWP use the same wrapping algorithm W which is also used by AESWrap, however do to different initialisation vectors the existing implementation can not be used to implement the padded wrapping

Re: Browser's accepting certificates that Java does not

Note that many browsers also download certs from the AIA and even "well known" mechanisms. It won't help to access more truststores, that would be a function you need to prove directly. Also the dynamic installation from Windows Updates or offline from crypt32.dll is not triggered when only brow

Re: NPE in jarsigner -verify for broken TSA

Hello, Just a little update, after implementing a jarsigner -verify after each sign operation and by retrying signatures when it fails, we could resolve the problem, when signing 50 jars one or two failed with NullPointer and worked after immediate retry. Gruss Bernd -- https://bernd.eckenfels

Re: [TLS-backport8] Does TLSv1.3 work with www.google.com

Hello Jamil, Thanks for responding, you are correct, this system property resolves my problem (on both the Oracle as well as Azure JRE). There is however something fishy going on. With the OpenJSSE provider (as provided by Zulu) the default for this option seems to be =true, as the extension i

Re: [TLS-backport8] Does TLSv1.3 work with www.google.com

Jamil, just a folllw up, I noticed in the bug comets that there are multiple conditions where boringSSL fails, seems like OpenJSSE somehow does not trigger the fingerprint match w/ and w/o status request. Gruss Bernd -- http://bernd.eckenfels.net Von: Bernd

Re: SSLSocket HandshakeCompletionListener Threading

I agree with that statement as an author of applications which have to connect to a wide range of external systems with a wide range of libraries and components. It should be configurable as a parameter on socket, session or factory level. I find a new API is more than welcome, especially if it

Re: Please add HMAC keygen to SunPKCS11

Hello, I would agree with this request, my usecase would be to use a HSM, where I typically don’t want to import keys but generate them safely on the HSM so not even admins have access to the key material ever (besides maybe having a key handle to wrap it). Isn’t that what the KeyGen interface

Re: RFR: JDK-8255395 Implement Enhanced Pseudo-Random Number Generators (CSR)

Hello, Not sure if it is needed to implement a new RandumGenerator interface instead of extending SecureRandom, but the extensions and the discovery mechanism looks good. One thing I am wondering about is if reseed() and reseed(Param) should be part of the new RandomGenerator interface as well

constant time compare is not used anywhere important

Hello, while researching on the SSL3 rsaHandshakeFix (dont ask :) I noticed that JSSE uses Arrays.equals() in some places to compare byte arrays with cryptographic material, at least in one instance it does even use it to verify and reject a MAC in a network protocol. I am not sure if this specif

skip-tls

Hello, I just run across this work from a team of researchers on TLS protocol fuzzing. One part of this article describes what CVE-2014-6593 is all about. https://www.smacktls.com/#skip I must say, I had a brief look into this while checking the fixes in the January CPU, but due to the rather lo

Re: TLS ALPN Proposal

> > There was also some internal discussion about whether the values > > should be Strings or byte arrays. The ALPN RFC only discusses > > bytes, and a String.toBytes("US-ASCII") would limit the API to > > ASCII strings. > > > > Lastly, we could also add some convenience values for well-known > >

disabledAlgorithms "DHE keySize < 1024" support?

Hello, does jdk.tls.disabledAlgorithms support to disable DHE based on the prime size (similiar to RSA keySize)? I have tried it, but I can only disable DHE completely, but I cannot get a Java TLS client to enforce higher standards (i.e. at least 768, better 1024) bit. I tried Oracle 8u40. Is ther

Re: disabledAlgorithms "DHE keySize < 1024" support?

Am Sat, 23 May 2015 08:30:26 +0800 schrieb Xuelei Fan : > Please refer to the "Customizing Size of Ephemeral Diffie-Hellman > Keys" section of JSSE Reference Guide. > > http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html Thanks Xulei, but I think this does not a

Re: disabledAlgorithms "DHE keySize < 1024" support?

Am Sat, 23 May 2015 22:16:16 +0800 schrieb Xuelei Fan : > I did not get your ideas in the previous mail. > "jdk.tls.disabledAlgorithms" is expected to work to disable weak DH > keys (for example, ""DHE keySize < 768"). Can you describe your > concern more? This is exactly what I want to do. In o

Re: disabledAlgorithms "DHE keySize < 1024" support?

Am Sat, 23 May 2015 17:18:07 +0200 schrieb Bernd Eckenfels : > I searched the ClientHandshaker for usages of algorithmConstraints, > and it does not use it for the DHE part. It only question > KEY_AGREEMENT for cipher suite selection. (But I am not so famiiar > with the code, maybe y

Re: disabledAlgorithms "DHE keySize < 1024" support?

Am Sat, 23 May 2015 17:48:25 +0200 schrieb Bernd Eckenfels : > I also run some connection test In case somebody wonders, the test code is here: https://github.com/ecki/JavaCryptoTest#simple-weakdh-logjam-test-client Gruss Bernd

configurable DHE key size

Hello, I need to correct a statement: Am Sat, 23 May 2015 15:50:06 +0200 schrieb Bernd Eckenfels : > BTW in Regards to the Server side: > > That document should mention that the parameter group is generated > randomly on first use (matching DSA restrictions). It is a good thing &g

Re: Run-time configurable sandboxes

Hello, partial quote as I want to add to a point: Am Tue, 26 May 2015 16:19:59 -0400 schrieb Michael Maass : > 3. Common security reasons to use the sandbox: (a) using a third > party library that isn't fully trusted (convenience often trumps > security) and (b) frameworks loading third party pl

Re: disabledAlgorithms "DHE keySize < 1024" support?

Hello, just for the records, IBM has issued in their June 2015 Security update a Logjam fix in 8 SR1-FP1 and 7R1 SP3-FP1 (and others). Unfortunatelly I havent found online documentation yet which describes what actually has changed. (their previous CVE analysis workaround did recommend to turn of

Re: RFR: JEP 249 (OCSP Stapling for TLS)

Hello, this is a general comment, not necesarily applicable for the OCSP stapling options directly: Am Tue, 23 Jun 2015 15:39:30 +0800 schrieb Xuelei Fan : > Caches, for example session/trust manager/key manager, are used a lot > in SSL/TLS handshaking. Dynamic system property may make the > b

Re: TLS hostname verifier: reverse resolves peer addresses?

Am Mon, 3 Nov 2014 00:15:28 +0100 schrieb Bernd Eckenfels : > JSSE... I noticed, that > the Java 8 hostname verifier (algorithm https configured) will reverse > resolve hostnames and use them. Is this JDK-8067695 (not public) and fixed in 8u51? Does this have an CVE entry in the 8u51

Re: TLS ALPN Proposal v3

Am Fri, 24 Jul 2015 14:38:36 -0500 schrieb Jason Greene : > The truth is that there is a gap between the current capabilities of > TLS stacks and what the specs are trying to achieve. Ultimately the > desired semantic the specs are trying to achieve is that every ALPN > protocol can have its own TL

Re: RFR 8048357: PKCS basic tests

Hello Amanda, out of curiosity I was looking at the tests, and have a few comments: PKCS7VerifyTest.java 63byte[] base64Bytes = new byte[pkcs7In.available()]; 64 if (pkcs7In.read(base64Bytes) < base64Bytes.length) { There are two pet peeves of mine. available() to get the

Possible HMAC (PBKDF2) optimization

Hello, triggered by a talk at Passwordconf'15 by Joseph Birr-Pixton about slow PBKDF2 implementations (where Java was particular bad) https://www.youtube.com/watch?v=k_szwKBuNBw https://bsideslv2015.sched.org/event/3uke/pbkdf2-performance-matters I had a look at the source because I remembered t

Re: Code Review Request 8149017 Delayed provider selection broken inRSA client key exchange

BTW, the System.out is already in the existing code, but I wonder if this should use Debug.println instead? Gruss Bernd -- http://bernd.eckenfels.net Von: Xuelei Fan Gesendet: Dienstag, 15. März 2016 11:02 An: OpenJDK Betreff: Re: Code Review Request 8149017 Delayed provider selection broken

Re: Code Review Request 8072452 Support DHE sizes up to 8192-bits

Hello Xuelei, glad to see this. :) --java.base/share/classes/sun/security/ssl/DHCrypt.java Does the comment "// FEDHE" stand for FFDHE (JDK-8140436)? maybe name the variables ffdhe instead of p? (they might be directly used clients to verify well known parameters) Unrelated to the ch

ISO10126PADDING, minor optimizations and random question

Hello, while looking at ISO10126Padding I noticed a few minor optimizations are possible: http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/com/sun/crypto/provider/ISO10126Padding.java?av=f unpad() - there is already a int cast done to this value: 104int sta

Non constant time padding check in SunJCE PKCS5Padding

Hello, I had a look at the PKCS5Padding because I had the problem that AES/CBC/NOPADDING is much faster than AES/CBC/PKCS5PADDING (for larger single block with doFinal() encryptions). I havent found out the reason for that (I suspect it does a unecesary input copy). (opening another thread for thi

RFC7525 mapped to JSSE

Hello, because I was asked by a customer I started to map the RFC7525 https://tools.ietf.org/html/rfc7525 recommendations for TLS to JSSE implementation. It is not complete yet but I think I at least have extraced all "normative" requirements from the RFC into this table: https://docs.google.

Re: RFR: 8061842: Package jurisdiction policy files as something other than JAR

Hello, I am glad as a user that I am only annoyed by the limited policies and that I do not have to actually implement features to restrict my software. :) However your mail reminded me: will it be a good idea to implement something like a Fips-compliant runtime in terms of (yet another) policy?

Re: RFC7525 mapped to JSSE

SHA2 is requested in the signature algorithm extension. > > JDK does not implement the truncted HMAC extension. > > JDK supports hostname verification APIs for HTTPS, and support > hostname verification during handshaking for HTTPS and LDAP. > > JDK tests the DH public k

DHKeyGenerator comment nit and discussion on minimum random key size

Hallo, I have noticed in DHKeyGenerator, that there is a comment which is not totally correct: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/496a116876a3/src/java.base/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java#l192 192// generate random x up to 2^lSize bits long 1

Re: DHKeyGenerator comment nit and discussion on minimum random key size

not require a loop of the condition can be satisifed in another way. Gruss Bernd Am Sun, 21 Aug 2016 14:51:05 +0200 schrieb Bernd Eckenfels : > Hallo, > > I have noticed in DHKeyGenerator, that there is a comment which is not > totally correct: > > http://hg.openjdk.java.net/

Re: RFR 8157404: Unable to read certain PKCS12 keystores from SequenceInputStream

Hello, readBytes read all bytes of a specified length. If the length is not known it is not usefull to use. Besides it is also not usefull to only read available() bytes, as the nmber of bytes read might be up to all kinds of factors (including io request and tcp segment boundaries). It is not a

Re: RFR 8163304: jarsigner -verbose -verify should print the algorithms used to sign the jar

Am Wed, 19 Oct 2016 16:13:24 -0400 schrieb Sean Mullan : > 150 "The jar will be treated as unsigned, because it > is signed with a weak algorithm that is now disabled.\n\nRe-run > jarsigner with the -verbose option for more details."}, I also wondered: what if there are multiple s

Re: Code Review Reqeust, JDK-8169362, Interop automated testing with Chrome

Hello, just a Nit, but should this be clientNet/AppOutbound instead of Inbound (or maybe use Response instead?) in ClientHelloInterOp#run Is it Ok that there is no asserts? What cipher would be picked for example? ClientHelloInterOp  In 271+304 I would use try-with-resource or not close the in mem

JDK 9 and JCE code signing (where and sha1WithDSA 1024?)

Hello, how will the JCE Provider signing in Java 9 work? Are the jmod files signed (I dont see a signature in them in the Windows EA builds)? On the BouncyCastle Crypto mailing list there has been a discussion that currently JCE code signing (of Jars) is done with a SHA1 chained 1024 bit DSA sig

TLS session cache access (for FTP clients with data connection session reuse)

With FTP/TLS there is a risk that data connections are guessed by attackers and there is no binding of the login credentials on the control connection and the data connection. Some FTP servers implement protection about this by requiring the data connection to resume the cached TLS session from th

Re: [PATCH] 8158517: Minor optimizations to ISO10126PADDING

Thanks for committing, looks fine with me as well. Gruss Bernd On Wed, Dec 7, 2016 at 5:25 PM +0100, "Sean Mullan" wrote: Looks good. Minor comment - update the copyright to include 2016 as the last year it was updated, ex: * Copyright (c) 2003, 2016, Oracle and/or its affilia

Re: RFR 8171190: Bump reference of NIST 800-57 Part 1 Rev 3 to Rev 4 in JarSigner API spec

Hello, I noticed in the existing code: Is the comment "256 bits" referring to the 'comparable strength'? # if (bitLength > 7680) { // 256 bits If so, it seems misleading, according to table 2 this would be 192 bit. Maybe this can be corrected, removed or the meaning of the comment clarified. Gru

Re: RFR : 8173783: IllegalArgumentException: jdk.tls.namedGroups

Should it use Debug.println? Gruss Bernd -- http://bernd.eckenfels.net On Tue, Feb 7, 2017 at 7:51 PM +0100, "Xuelei Fan" wrote: Looks fine to me. Thanks, Xuelei On 2/7/2017 7:25 AM, Seán Coffey wrote: > The recent JDK-8148516 enhancement causes issue for JDKs without EC > suppo

Re: [RFR] 8174849: Change SHA1 certpath restrictions

Hello, The bug does not explain why. I would understand to completely deny SHA1 (I.e. Unconditionally), but allowing it seems strange, especially without a justification. Gruss Bernd -- http://bernd.eckenfels.net On Mon, Feb 13, 2017 at 10:57 PM +0100, "Anthony Scarpino" wrote:

Re: Generate Keypairs with strong prng provider (SHA1PRNG)

Hello, yes on Java 8 the keytool will use SHA1PRNG (on Windows) and with Java 9 it will use DRBG(128,reseed_only). I guess both are not well suited for larger permanent keys (like Keytool is supposed to create). But agreed, the Java 9 default is less problematic. Hmm.. thinking out loud. maybe

Re: Generate Keypairs with strong prng provider (SHA1PRNG)

7;t there some certification requirements in the queue for key generation anyway?) (And one can only dream of a 8 backport :) Gruss Bernd -- http://bernd.eckenfels.net From: Weijun Wang Sent: Friday, March 17, 2017 9:53:34 AM To: Bernd Eckenfels; security-dev@openjdk.ja

Re: RFR: 3 security-libs release notes on keytool/krb5/etc

I wonder if "weak key" should be replaced by "weak key length" or "short key". It might otherwise imply key quality tests which are not carried out. Gruss Bernd -- http://bernd.eckenfels.net From: security-dev on behalf of Weijun Wang Sent: Friday, March 24, 2

Re: RFR: 3 security-libs release notes on keytool/krb5/etc

;. >> >> I prefer the term "weak" which implies it is a risk. We already use that >> term in jarsigner so I think we should keep it consistent. You also >> print the size of the key so that describes what is wrong with it. >> >> --Sean >> >>&

Re: Short AES GCM Tags?

Hello, I also think there is no short version for TLS anyway. RFC 5288 states that the Tag is 128 bit and the hmac truncation extension (which would allow 80 bit) is not valid for GCM. Gruss Bernd -- http://bernd.eckenfels.net From: security-dev on behalf of Va

  1   2   3   >