New candidate JEP: 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
http://openjdk.java.net/jeps/339 - Mark
Re: RFR[11] JDK-8206258: [Test Error] sun/security/pkcs11 tests fail if NSS libs not found
Updated webrev looks fine.
Thanks,
Valerie
On 7/23/2018 11:10 PM, sha.ji...@oracle.com wrote:
Hi Valerie,
Thanks for your review!
Please take a look at this new webrev:
http://cr.openjdk.java.net/~jjiang/8206258/webrev.02
On 2018/7/24 06:18, Valerie Peng wrote:
Hi John,
Changes look fine.
I just have one nit, perhaps add more information reporting when
skipping tests, e.g.
PKCS11Test: line 163
Different tests may have different reasons for skipping testing.
So, it would be better to output the info in PKCS11Test's child classes.
In fact, the tests overriding the method PKCS11Test::skipTest already
report the reasons respectively.
TestNssDbSqlite.java: line 68.
Add the below line
120 System.out.println("Cannot init security module
database, skipping");
Best regards,
John Jiang
Thanks,
Valerie
On 7/9/2018 12:38 AM, sha.ji...@oracle.com wrote:
Hi Thomas,
Thanks for your testing.
I'm not sure that's a reasonable case.
From my view, PKCS11Test.java simply checks if the NSS library
directory exists.
But it looks unnecessary to check every library file.
In fact, if removing libnss3 or libsoftokn3's dependencies, like
libnssutil3, the test also fails.
However, I still re-checked my previous solution, and made a new
webrev [1].
The constant badNSSVersion in PKCS11Test.java may not be fine.
The static field nss_library in PKCS11Test.java can be softokn3 or
nss3 for different tests.
badNSSVersion should be checked after the target nss library is
determined.
And this checking should happen before the real testing, especially
before security manager is enabled.
So, a new extension method, exactly PKCS11Test::skipTest, was
introduced, and the affected tests were modified accordingly.
[1] http://cr.openjdk.java.net/~jjiang/8206258/webrev.01/
Best regards,
John Jiang
On 2018/7/4 14:15, Thomas Stüfe wrote:
Hi,
Unfortunately this is not enough.
Running tests with your patch and NSS libs disabled (I renamed
libsoftokn3.so) yields the following errors:
sun/security/pkcs11/Secmod/AddPrivateKey.java
Failed. Execution
failed: `main' threw exception: java.security.ProviderException: Could
not initialize NSS
sun/security/pkcs11/Secmod/AddTrustedCert.java
Failed. Execution
failed: `main' threw exception: java.security.ProviderException: Could
not initialize NSS
sun/security/pkcs11/Secmod/Crypto.java
Failed. Execution
failed: `main' threw exception: java.security.ProviderException: Could
not initialize NSS
sun/security/pkcs11/Secmod/GetPrivateKey.java
Failed. Execution
failed: `main' threw exception: java.security.ProviderException: Could
not initialize NSS
sun/security/pkcs11/Secmod/JksSetPrivateKey.java
Failed. Execution
failed: `main' threw exception: java.security.ProviderException: Could
not initialize NSS
sun/security/pkcs11/Secmod/LoadKeystore.java
Failed. Execution
failed: `main' threw exception: java.security.ProviderException: Could
not initialize NSS
sun/security/pkcs11/Secmod/TestNssDbSqlite.java
Failed. Execution
failed: `main' threw exception: java.security.ProviderException: Could
not initialize NSS
sun/security/pkcs11/Secmod/TrustAnchors.java
Failed. Execution
failed: `main' threw exception: java.security.ProviderException: Could
not initialize NSS
Excerpt from TestNssDbSqlite.jtr:
--messages:(3/98)--
command: build TestNssDbSqlite
reason: Named class compiled on demand
elapsed time (seconds): 0.0
result: Passed. All files up to date
#section:main
--messages:(5/721)--
command: main TestNssDbSqlite
reason: User specified action: run main/othervm/timeout=120
TestNssDbSqlite
Mode: othervm [/othervm specified]
Additional options from @modules: --add-modules
java.base,jdk.crypto.cryptoki --add-exports
java.base/sun.security.rsa=ALL-UNNAMED --add-exports
java.base/sun.security.provider=ALL-UNNAMED --add-exports
java.base/sun.security.jca=ALL-UNNAMED --add-exports
java.base/sun.security.tools.keytool=ALL-UNNAMED --add-exports
java.base/sun.security.x509=ALL-UNNAMED --add-exports
java.base/com.sun.crypto.provider=ALL-UNNAMED --add-exports
jdk.crypto.cryptoki/sun.security.pkcs11=ALL-UNNAMED --add-opens
jdk.crypto.cryptoki/sun.security.pkcs11=ALL-UNNAMED
elapsed time (seconds): 0.445
--configuration:(11/604)--
Boot Layer
add modules: java.base jdk.crypto.cryptoki
add exports: java.base/com.sun.crypto.provider ALL-UNNAMED
java.base/sun.security.jca ALL-UNNAMED
java.base/sun.security.provider ALL-UNNAMED
java.base/sun.security.rsa ALL-UNNAMED
Code Review Request, JDK-8208166, Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029
Hi, Please review the update for JDK-8208166: http://cr.openjdk.java.net/~xuelei/8208166/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8208166 Thanks, Xuelei
Re: Please review EdDSA API
On 7/25/2018 11:24 AM, Michael StJohns wrote: *sigh* Private keys are big integers. There's an associated parameter used in signing that the implementation described in the RFC (*not a standard please note*) generates from a common random byte array - that byte array is NOT a (or the) private key. E.g. Private key ::= OctetToInteger(Adjust(Left (HASH(random), length))) and SigningValue ::= Right(HASH(random),length). Instead, you can get the exact same result (deterministic signatures) - and store a bog standard EC private key - by PrivateKey ::= OctetToInteger(Adjust(random)); Did you mean PrivateKey ::= OctetToInteger(random)? Setting/clearing bits here destroys information. If we don't prune here, then we can reverse this operation later to get the byte array back to give to the hash. SigningValue ::= HASH (IntegerToOctet(PrivateKey)); // signing value may be regenerated at any time and need not be stored in the ECPrivateKey class. With the modification above, I agree that this would give the value that can be split in half to produce the scalar value (after pruning and interpreting as an integer) and the prefix that is used in signing. I think there may be some issues with this approach, but we need to start by agreeing on what you are proposing. Can you confirm that my understanding of your proposal is correct, or else clarify it for me?
Re: Please review EdDSA API
On 7/25/2018 10:29 AM, Adam Petcher wrote: 2) Similar to X25519/X448, private keys are byte arrays, and public keys coordinates. Though we can't get by with a single BigInteger coordinate for EdDSA, so I am using the new EdPoint class to hold the coordinates. *sigh* Private keys are big integers. There's an associated parameter used in signing that the implementation described in the RFC (*not a standard please note*) generates from a common random byte array - that byte array is NOT a (or the) private key. E.g. Private key ::= OctetToInteger(Adjust(Left (HASH(random), length))) and SigningValue ::= Right(HASH(random),length). Instead, you can get the exact same result (deterministic signatures) - and store a bog standard EC private key - by PrivateKey ::= OctetToInteger(Adjust(random)); SigningValue ::= HASH (IntegerToOctet(PrivateKey)); // signing value may be regenerated at any time and need not be stored in the ECPrivateKey class. Adjust twiddles the bits in the byte array to make the byte array a valid little-endian private key before encoding for this set of curves. OctetToInteger turns that byte array into a BigInteger. At this point in time, you've got the correct values to do your point math using common libraries if you don't happen to have implemented exactly what's in the RFC. I know the above is a losing argument, but seriously, do we really need two new groups of EC classes simply because someone wrote an RFC that didn't consider existing representational structures? Or will it be three or more? Later, Mike
Re: RFR: Backport for JDK-8207237 to JDK 11
Looks fine to me. Xuelei On 7/25/2018 8:14 AM, Jamil Nimeh wrote: Hi folks, This is a review for a backport to the JDK 11 repo of a change I did earlier to jdk/jdk that fixed the SSLSocket.setEnabledCipherSuites method. It no longer accepts empty strings in the cipher suite list. Instread, it returns to the behavior of throwing IllegalArgumentException as it did before the new TLS handshaker code was committed. Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8207237-jdk11/webrev.01/ JBS: https://bugs.openjdk.java.net/browse/JDK-8207237 Thanks, --Jamil
RFR: Backport for JDK-8207237 to JDK 11
Hi folks, This is a review for a backport to the JDK 11 repo of a change I did earlier to jdk/jdk that fixed the SSLSocket.setEnabledCipherSuites method. It no longer accepts empty strings in the cipher suite list. Instread, it returns to the behavior of throwing IllegalArgumentException as it did before the new TLS handshaker code was committed. Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8207237-jdk11/webrev.01/ JBS: https://bugs.openjdk.java.net/browse/JDK-8207237 Thanks, --Jamil
Re: Please review EdDSA API
+core-libs-dev for additional API expertise. On 7/25/2018 10:29 AM, Adam Petcher wrote: The draft CSR[1] for the EdDSA API[2] is ready for review. Please take a look and send me any feedback you may have. Here are a few high-level notes to explain the API: 1) Where possible, this API is similar to the API for X25519/X448. To get the complete background/motivation for the API design, you can review the discussion[3] on this topic. 2) Similar to X25519/X448, private keys are byte arrays, and public keys coordinates. Though we can't get by with a single BigInteger coordinate for EdDSA, so I am using the new EdPoint class to hold the coordinates. 3) EdDSA has multiple signature modes defined in the RFC[4], including some that "prehash" the input before signing. The draft API uses the EdDSAParameterSpec class to specify parameters of these modes. The standard does not allow an arbitrary choice of prehash function, so the API for EdDSA does not support algorithm names like "SHA256withEdDSA". [1] https://wiki.openjdk.java.net/display/csr/Main [2] https://bugs.openjdk.java.net/browse/JDK-8190219 [3] http://mail.openjdk.java.net/pipermail/security-dev/2017-September/016325.html [4] https://tools.ietf.org/html/rfc8032
