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

[Weijun Wang]

> 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
>>