Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integer encoding not being handled correctly #88

Open
jakekgrog opened this issue Apr 29, 2024 · 1 comment
Open

Integer encoding not being handled correctly #88

jakekgrog opened this issue Apr 29, 2024 · 1 comment

Comments

@jakekgrog
Copy link

jakekgrog commented Apr 29, 2024

Hi there,

First off, I'm no ASN.1 expert so please correct me and close the issue if I'm wrong.

My understanding is that INTEGER types can be positive, negative, zero and have any magnitude.

In most languages you have the ability to specify a size and sign of a number

If the number is signed, then the high-order bit (the first bit of the most significant byte) determines whether the value is negative or positive.

To account for this, I understand ASN.1 Integers are padded with 0x00 if the high order bit is set. Hence a "2048-bit" (256-byte) number may actually use 257 bytes in ASN.1.

In pseudo code that is:

# parsing
if 0x00 == bytes[0] {
  bytes = bytes.slice(1)
}
# packing
if 0x80 & bytes[0] {
  bytes = bytes.prepend(0)
}

The prepending of 0x00 doesn't appear to be happening and I've had to manually add a 0x00 byte as the first byte if the first byte is > 0x80.

As an example:

const param = "FFFFFFFF00000001000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFF";

let output = new ASN1.Integer({
    valueHex: new Uint8Array([hexStringToArray(param)]).buffer,
});

console.log(Buffer.from(param.toBER(), 'hex').toString('hex'));

// The above should output '022100ffffffff00000001000000000000000000000000ffffffffffffffffffffffff'
// Note the prepended 0x00
// However that isn't happening
// Instead the output is '0220ffffffff00000001000000000000000000000000ffffffffffffffffffffffff'

As DER is a subset of BER, my understanding is BER encoding should prepend the 0x00 byte?

@tstiemerling
Copy link

tstiemerling commented Feb 18, 2025

This is correct, and is causing RSA public key decoding to fail in my application. Someone should really fix this.

Integer values are encoded into a TLV triplet that begins with a Tag value of 0x02. The Value field of the TLV triplet contains the encoded integer if it is positive, or its two's complement if it is negative. If the integer is positive but the high order bit is set to 1, a leading 0x00 is added to the content to indicate that the number is not negative. For example, the high order byte of 0x8F (10001111) is 1.

If the integer contains fewer than 128 bytes, the Length field requires only one byte to specify the content length. If the integer is more than 127 bytes, bit 7 of the Length field is set to 1 and bits 6 through 0 specify the number of additional bytes used to identify the content length.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants