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
