RFR: 8257769: Cipher.getParameters() throws NPE for ChaCha20-Poly1305 [v2]

[Jamil Nimeh]

Oh, one other thing in case you weren't talking about this in the 
context of Cipher and instead were talking about the AlgorithmParameters 
object itself.  If that's all you've got in scope one approach is to 
call getParameterSpec(IvParameterSpec.class).getIV();  That will give 
you the byte array as well.  Now that I think about it, I should 
probably do that in my test code because I went and manually parsed the 
DER encoding.  :)  Glad you brought it up.

--Jamil

On 12/7/2020 5:39 PM, Jamil Nimeh wrote:
>
> 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-retn at openjdk.java.net> im Auftrag 
>> von Jamil Nimeh <jnimeh at openjdk.java.net>
>> *Gesendet:* Monday, December 7, 2020 9:05:16 PM
>> *An:* security-dev at openjdk.java.net <security-dev at 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 <valeriep at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20201207/a4cf13f7/attachment.htm>