Hi Bernd, it's not a stupid question at all. I think what you might be
looking for is Cipher.getIV()? In the case of ChaCha20-Poly1305, that
method returns the nonce as a byte array where getParameters() returns
an AlgorithmParameters object where the encoding is consistent with RFC
8103.
But both getParameters() and getIV() were doing the wrong thing
(chucking NPE) when they should've either come up with a random param or
null, respectively when in a pre-initialized state.
--Jamil
On 12/7/2020 5:19 PM, Bernd Eckenfels wrote:
BTW stupid - somewhat related - question, why does the nonce to be
parsed out of a DER blob, shouldn’t there be an getter on the
Parameter Spec object? Many protocols would need the raw array, is
there a matching spec - or should we add one?
Gruss
Bernd
--
http://bernd.eckenfels.net
------------------------------------------------------------------------
*Von:* security-dev <security-dev-r...@openjdk.java.net> im Auftrag
von Jamil Nimeh <jni...@openjdk.java.net>
*Gesendet:* Monday, December 7, 2020 9:05:16 PM
*An:* security-dev@openjdk.java.net <security-dev@openjdk.java.net>
*Betreff:* Re: RFR: 8257769: Cipher.getParameters() throws NPE for
ChaCha20-Poly1305 [v2]
On Mon, 7 Dec 2020 19:53:27 GMT, Valerie Peng <valer...@openjdk.org>
wrote:
>> Jamil Nimeh has updated the pull request incrementally with one
additional commit since the last revision:
>>
>> pre-init getParameters nonce data is now a local variable
>
>
src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java
line 232:
>
>> 230: // this call should cause a random nonce to be
generated, but
>> 231: // not attached to the object.
>> 232: byte[] nonceData = initialized ? nonce :
createRandomNonce(null);
>
> The "initialized" variable is set to false in engineDoFinal() call.
So, if users call getParameters() after finish cipher operation, this
will return random nonces instead of the one used in previous doFinal
operation. Will this be a little un-intuitive?
Unintuitive is a charitable way to put it. After doFinal the Cipher
technically isn't in an uninitialized state per the spec, it's
supposed to be in the state it would be immediately following init().
So the wrong behavior would happen in this use case. Will fix.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1644
<https://git.openjdk.java.net/jdk/pull/1644>
