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

[Alvarez, David]

Here is the updated webrev with suggested changes:

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.02/

--
David

On 2019-06-17, 09:41, "Andrew John Hughes" <gnu.andrew at redhat.com> wrote:

    
    
    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