This is a discussion on RE: ASN1_INTEGER <==> int - Openssl ; > Clarification: > > In DER, the following is prohibited: > 1. leading zero bytes if the next non-zero octet does not start with bit > 7 set (0x80 mask). > 2. leading 0xff (-1, 255) bytes, if the next ...
> In DER, the following is prohibited:
> 1. leading zero bytes if the next non-zero octet does not start with bit
> 7 set (0x80 mask).
> 2. leading 0xff (-1, 255) bytes, if the next non-0xff octet starts with
> bit 7 set (0x80 mask).
Thanks for the clarification. It tooks me about as many times to get it
right in my BER/DER code as it does for me to get it right in communication.
The DER specification requires an integer to be encoded into octets using
2's complement and as few octets as possible. This means you cannot have a
leading zero unless the high bit of the next octet is set. Similarly, you
cannot have a leading 0xff unless the high bit of the next octet is clear.
The most-significant bit is always the sign bit.
So (all numbers in hex):
00 20 : Illegal DER, leading 00 not needed
00 80 : Legal, leading 00 needed to make number positive
FF 03 : Legal, leading FF needed to make number negative
FF D0 : Illegal DER, FF not needed
Note that these are all legal BER and are all perfectly valid and
meaningful integer encodings. DER, however, requires the minimum number of
octets to be used.
In cryptography applications, DER is important because if you change the
binary representation of a certificate or public key, its checksum will
change and signatures would be invalidated. DER allows you to convert a key
or certificate to a native format, then write it back out and get the exact
OpenSSL Project http://www.openssl.org
Development Mailing List email@example.com
Automated List Manager firstname.lastname@example.org