Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Convert-ASN1 CPAN distribution.

Report information
The Basics
Id: 52088
Status: rejected
Priority: 0/
Queue: Convert-ASN1

People
Owner: Nobody in particular
Requestors: gbarr [...] pobox.com
markus [...] wernig.net
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



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 ---------------------------------------------
Download smime.p7s
application/x-pkcs7-signature 5.4k

Message body not shown because it is not plain text.

CC: bug-Convert-ASN1 [...] rt.cpan.org
Subject: Re: ASN.1 encoding of integers > 0x7FFFFFFF
Date: Thu, 26 Nov 2009 09:52:43 -0600
To: Markus Wernig <markus [...] wernig.net>
From: Graham Barr <gbarr [...] pobox.com>
On Nov 26, 2009, at 5:44 AM, Markus Wernig wrote: Show quoted text
> Hello > > I have noted that Convert::ASN1 encodes integers > 0x7FFFFFFF > differently from what I would expect. > > The following example should demonstrate the behaviour: > > ----- 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."
How does it contradict? that states that the left most 9 bits cannot all be the same in binary the first byte and bit 8 of the second byte are 00000001 basically the left most bit denotes sign, 0xDEADBEEF is unsigned but 0204DEADBEEF is a negative number because the left most bit is 1 Graham. Show quoted text
> > 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 > --------------------------------------------- >