ECDSA key components can end up less than 64 bytes long

[fguitton]

In the current repo we can see that a padding of ECDSA key components is commented out.
This is leading to keys of sizes inferior to 64 bytes.
Older copies on this library had this working to ensure consistent size.

Is there any plan to uncomment this ? What was the original thinking behind commenting it out ?

MSR-JavaScript-Crypto/scripts/ecdsa.js

Lines 210 to 213 in 9837453

	function padTo8BytesIncrement( array ) {
	return array;
	//return msrcryptoUtilities.padFront(array, 0, Math.ceil(array.length / 8) * 8);
	}

[ljoy913]

I'm double checking to be sure, but I believe a fix to bytes-to-digits made this padding unnecessary - and poor housekeeping resulting in the commented-out code and unnecessary no-op function not being removed.

[ljoy913]

Ok. final answer, the above fix I mentioned was unrelated to this:

The padding of the zeros was removed to make the library compatible with pre-chromium MS Edge. The WebCrypto API on pre-chromium (legacy) Edge did not allow for leading zeros in its keys.

So if a 32-byte key had a leading zero, Edge would throw an error. It would only accept the key without the leading zeros as a 31-byte key.

This msrcrypto library can handle import the same key in either form.

Chrome will throw an error is if the key has less than 32 bytes - so it requires the zero-padding. The new chromium-Edge also requires the full 32-bytes.

So a couple of years ago it made sense to use the non-padded keys to be compatible with MS Edge, as it was trivial to pad a zero if a key was a byte short to be compatible with chrome, etc.

Now that Edge has moved to chromium, it make less sense. I'll start on a PR to restore the zero-padding.