On Wed, 2 Mar 2022 21:47:06 GMT, Valerie Peng <valer...@openjdk.org> wrote:
>> The comment said "pad it w/ leading 0s". So let's pad it.
>
> src/java.base/share/classes/com/sun/crypto/provider/DHKeyAgreement.java line
> 347:
>
>> 345: // Array too short, pad it w/ leading 0s
>> 346: if (secret.length < expectedLen) {
>> 347: Arrays.fill(sharedSecret, offset, offset + (expectedLen
>> - secret.length), (byte)0);
>
> nit: longer than 80 chars?
I'll wrap it.
> test/jdk/com/sun/crypto/provider/KeyAgreement/DHKeyAgreementPadding.java line
> 28:
>
>> 26: * @bug 8281628
>> 27: * @library /test/lib
>> 28: * @summary KeyAgreement : generateSecret intermittently not resetting
>
> nit: describe the fix instead of just using the bug synopsis.
OK.
> test/jdk/com/sun/crypto/provider/KeyAgreement/DHKeyAgreementPadding.java line
> 56:
>
>> 54: // Different stale data
>> 55: aliceSecret[0] = 0;
>> 56: bobSecret[0] = 1;
>
> Instead of only the first byte difference, would it be easier to trigger the
> bug with completely different buffer value, say FFFFFF vs 000000?
Maybe not. When the generated secret is shorter, the padded bytes are always at
the beginning.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7665
