Re: RFR 8177398: Exclude dot files ending with .conf from krb5.conf's includedir
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
Re: Proposal: ChaCha20 and ChaCha20-Poly1305 Cipher implementations
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
Re: Proposal: ChaCha20 and ChaCha20-Poly1305 Cipher implementations
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
Re: Proposal: ChaCha20 and ChaCha20-Poly1305 Cipher implementations
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
Proposal: ChaCha20 and ChaCha20-Poly1305 Cipher implementations
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,
Re: RFR JDK-8186098: sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failed due to libnss3 version cannot be parsed
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.ji...@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.ji...@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
