BigInteger magnitude (Related to RFR: 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes)
Michael StJohns
mstjohns at comcast.net
Wed Jan 28 20:03:44 UTC 2015
In the code for dealing with R and S in the ECDSA engine is the same construct I've seen several times and programmed in several different ways mostly inside the security code. To wit:
Given a positive BigInteger, return a byte array of the magnitude of a specific length, right adjusted and left zero padded.
E.g. if "r" is a BigInteger with a positive value of 5, then "r.getMagnitude(4)" would return a byte[] of length 4 consisting of { 0, 0, 0, 5 }.
That construct occurs in the R/S encoding for ECDSA signatures and in the encoding of the derived shared secret from a DH or ECDH. It probably occurs elsewhere as this is a pretty common sub function for crypto.
Would it make sense to add to BigInteger some or all of the following methods:
(In BigInteger)
byte[] getMagnitude(int magLengthInBytes)
void getMagnitude (byte[] magnitude)
void getMagnitude (byte[] magnitude, int magOffset, int magLengthInBytes)
ByteBuffer getMagnitude(ByteBuffer buffer, intMagLengthInBytes) - or -
(in ByteBuffer) ByteBuffer putBigIntegerMagnitude(BigInteger bigint, int magLengthInBytes)
(If we add the last two, then perhaps add the equivalent constructors or duals:
BigInteger (int signum, byte[] magnitude, int magOffset, int magLengthInBytes)
BigInteger (int signum, ByteBuffer magnitude, int magLengthInBytes) - or -
(in ByteBuffer) BigInteger getBigIntegerByMagnitude (int signum, int magLengthInBytes);
)
And then ideally go back and clean up the code tree to use these as the common constructs.
Throws a NumberFormatException if the magnitude won't fit in the number of bytes (e.g. 100000 in a magnitude of 2 array)
These are probably public API changes.
Mike
More information about the security-dev
mailing list