BigInteger magnitude (Related to RFR: 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes)

[Michael StJohns]

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