CC: | gbarr [...] pobox.com |
Subject: | ASN.1 encoding of integers > 0x7FFFFFFF |
Date: | Thu, 26 Nov 2009 12:44:00 +0100 |
To: | bug-Convert-ASN1 [...] rt.cpan.org |
From: | Markus Wernig <markus [...] wernig.net> |
Hello
I have noted that Convert::ASN1 encodes integers > 0x7FFFFFFF
differently from what I would expect.
The following example should demonstrate the behaviour:
Show quoted text
----- BEGIN EXAMPLE -----
#!/usr/bin/perl
use Convert::ASN1 qw ( :all );
use strict;
my $asn = Convert::ASN1->new;
$asn->configure('encoding' => 'DER');
$asn->prepare(q<
int INTEGER
>) or print "Error preparing was: ", $asn->{'error'}, "\n";
my $pdu = undef;
$pdu = $asn->encode(
int => 0xDEADBEEF
) or print "Error encoding was: ", $asn->{'error'}, "\n";
print unpack('H*', $pdu), "\n";
----- END EXAMPLE -----
This results in an ASN.1 Hex representation of:
020500deadbeef
Which I don`t understand. I would have expected it to be
0204deadbeef
instead.
0x80000000 results in 02050080000000
0x7FFFFFFF results in 02047FFFFFFF
To my understanding, encoding an extra leading byte with 00 contradicts
X.690, which states in 8.3.2:
"If the contents octets of an integer value encoding consist of more
than one octet, then the bits of the first octet
and bit 8 of the second octet:
a) shall not all be ones; and
b) shall not all be zero."
I assume this has to do with signedness and the size of an integer on
the system the program is run on, but could not find any reference to it
in the documentation. The results are the same on 32 and 64 bit systems.
I'm not quite sure if this is a bug, and would be grateful if you could
have a look at it. If this is intended behaviour, could you please share
the rationale behind it (any pointer welcome).
Thank you very much
Markus
--
Markus Wernig
Unix/Network Security Engineer - CISSP, CCSE
GPG: CA558BF7
http://xfer.ch
---------------------------------------------
Linux User Group Bern - http://lugbe.ch
---------------------------------------------
Message body not shown because it is not plain text.