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" <[email protected]> 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
signature.asc
Description: OpenPGP digital signature
