RFR 8241960: The SHA3 message digests are not thread safe when cloned

[Valerie Peng]

Right, with a closer look, it does require multiple threads to trigger 
this problem.

Valerie


On 3/31/2020 6:10 PM, Weijun Wang wrote:
>
>> On Apr 1, 2020, at 4:01 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>
>> Hi Alexey,
>>
>> Good catch, thanks for the report, I will review it.
>>
>> On a first look, it seems that this is more about the clone() method of the SHA-3 impl missed copying/cloning an internal field.
>>
>> Given that this is about SUN provider, I've modified the synopsis accordingly and move the priority up to P3.
>>
>> It may not take multi-thread to reproduce this? If so, we can simplify the regression test.
> Looks like a must:
>
>      private void keccak() {
>          // convert the 200-byte state into 25 lanes
>          bytes2Lanes(state, lanes);
>          // process the lanes through step mappings
>          for (int ir = 0; ir < NR; ir++) {
>              smIota(smChi(smPiRho(smTheta(lanes))), ir);
>          }
>          // convert the resulting 25 lanes back into 200-byte state
>          lanes2Bytes(lanes, state);
>      }
>
> One object's lanes can only be used by another if this method is called by multiple threads at the same time.
>
> --Max
>
>> Regards,
>> Valerie
>> On 3/31/2020 11:27 AM, Alexey Bakhtin wrote:
>>> Hi All,
>>>
>>> Please review fix for SHA3 message digests thread safety.
>>> Issue reproduced on the JDK11, JDK13 and JDK14
>>> JTREG test is provided in the patch
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8241960
>>> Webrev: https://cr.openjdk.java.net/~abakhtin/8241960/webrev.v0/
>>>
>>> Regards
>>> Alexey
>>>