Re: ASN1_INTEGER <==> int
David Schwartz wrote:[color=blue][color=green]
>> 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).[/color]
> 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.[/color]
As rightfully pointed out by Peter Sylvester, in this respect BER is
equivalent to DER as well.
> 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
> same representation.
> OpenSSL Project [url]http://www.openssl.org[/url]
> Development Mailing List [email]email@example.com[/email]
> Automated List Manager [email]firstname.lastname@example.org[/email][/color]
OpenSSL Project [url]http://www.openssl.org[/url]
Development Mailing List [email]email@example.com[/email]
Automated List Manager [email]firstname.lastname@example.org[/email]