[8u] RFR: Backport 8181594: Efficient and constant-time modular arithmetic

[Andrew John Hughes]

On 14/06/2019 22:16, Alvarez, David wrote:
> Correction, this is the RFR for 8181594: Efficient and constant-time modular arithmetic
> 
> On 2019-06-14, 14:13, "Alvarez, David" <alvdavi at amazon.com> wrote:
> 
>     Hi,
>     
>     Please review this backport of JDK-8181594: Efficient and constant-time modular arithmetic
>     
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8181594
>     Original: http://hg.openjdk.java.net/jdk/jdk/rev/d213d70182a9
>     Webrev: http://cr.openjdk.java.net/~phh/8181594/webrev.8u.00/
>     
>     JDK-8181594 is marked as jdk8u-critical-yes
>     
>     This is the first of a chain of three patches, JDK-8181594, JDK-8208648 and JDK-8208698 I will be sending today
>     
>     The patch consists only of new files, so there were no conflicts. However, jdk/src/share/classes/sun/security/util/math/intpoly/IntegerPolynomial1305.java makes use of VarHandle, so I had to replace that part with a ByteBuffer. I’ve attached the differences between the original patch and my patch below.
>     
>     Thanks,
>     David
>     
>     --- a/src/jdk/src/share/classes/sun/security/util/math/intpoly/IntegerPolynomial1305.java
>     +++ b/src/jdk/src/share/classes/sun/security/util/math/intpoly/IntegerPolynomial1305.java
>     @@ -26,7 +26,6 @@
>     package sun.security.util.math.intpoly;
>     
>     import java.lang.invoke.MethodHandles;
>     -import java.lang.invoke.VarHandle;
>     import java.math.BigInteger;
>     import java.nio.*;
>     
>     @@ -167,14 +166,13 @@ public class IntegerPolynomial1305 extends IntegerPolynomial {
>              result[4] = (high >>> 40) + (highByte << 24L);
>          }
>     
>     -    private static final VarHandle AS_LONG_LE = MethodHandles
>     -        .byteArrayViewVarHandle(long[].class, ByteOrder.LITTLE_ENDIAN);
>     -
>          protected void encode(byte[] v, int offset, int length, byte highByte,
>                                long[] result) {
>              if (length == 16) {
>     -            long low = (long) AS_LONG_LE.get(v, offset);
>     -            long high = (long) AS_LONG_LE.get(v, offset + 8);
>     +            long low = ByteBuffer.wrap(v, offset, 8)
>     +                    .order(ByteOrder.LITTLE_ENDIAN).getLong();
>     +            long high = ByteBuffer.wrap(v, offset + 8, 8)
>     +                    .order(ByteOrder.LITTLE_ENDIAN).getLong();
>                  encode(high, low, highByte, result);
>              } else {
>                  super.encode(v, offset, length, highByte, result);
>     
>     
>     
>     
> 

Would it not make more sense to create one ByteBuffer of v.length and
then read two longs from it? That would seem to be a little more
efficient and closer to the original e.g.


asLongLEBuffer = ByteBuffer.wrap(v, offset,
v.length).order(ByteOrder.LITTLE_ENDIAN);
long low = asLongLEBuffer.getLong();
long high = asLongLEBuffer.getLong();
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew