RFR 8206915: XDH TCK issues

[Sean Mullan]

On 7/11/18 11:01 AM, Adam Petcher wrote:
> On 7/11/2018 10:41 AM, Sean Mullan wrote:
> 
>> XDHKeyAgreement.java
>>
>> 176         byte[] result = secret;
>>
>> Shouldn't this be:
>>
>> 176         byte[] result = secret.clone();
>>
>> since engineGenerateSecret() says it is returned in a new buffer.
> 
> I don't think cloning is necessary. The new array is created in 
> engineDoPhase, and it is always set to null in engineGenerateSecret 
> after it is returned or copied to the output buffer. In essence, this 
> overload of engineDoPhase transfers ownership of the array, and the 
> other one destroys it. So this engineDoPhase effectively returns a new 
> array, and I don't think it is possible for two clients (in the same 
> thread) to get the same array from these methods. Though I would 
> appreciate it if you could double-check this and make sure you agree.

Ok, I see. I think it should be ok. I checked and the KeyAgreement/Spi 
APIs do not specifically say anything about concurrent access by 
multiple threads. However, typically I think it's normal to assume that 
they don't support concurrent access (i.e. unexpected behavior may 
result if so) unless it specifically says so.

--Sean