Re: Fwd: libtasn1 implements ASN.1 INTEGER as 64bit long

[Simon Josefsson]

Jeff Johnson <address@hidden> writes:

> Apologies for e-mailing directly. Same message
> to address@hidden just bounced.

Strange, let's see if this bounces too...

>> From: Jeff Johnson <address@hidden>
>> Date: July 13, 2010 10:37:46 AM EDT
>> To: address@hidden
>> Subject: libtasn1 implements ASN.1 INTEGER as 64bit long
>> 
>> Hi --
>> 
>> For various crypto related reasons @rpm5.org, I found
>> myself looking at how gnutls uses libtasn1 a couple
>> weeks ago.
>> 
>> Much to my surprise I find that libtasn1 chooses to
>> implement an ASN.1 INTEGER type as an "unsigned long".

That is wrong, it doesn't.    One of the design goals is that INTEGERS
shouldn't be limited in range, see:

http://www.gnu.org/software/libtasn1/manual/libtasn1.html#Introduction

>> Thats well, not gonna work for my purposes: RSA-64bit
>> was insecure in 1990.
>> 
>> Since I'm gonna need an ASN.1 INTEGER implementation anyways,
>> I though I might also offer to send a patch for libtasn1.
>> 
>> If you can describe a little bit what you would like to
>> see in libtasn1 I can likely spin a patch to accommodate
>> whatever you wish.
>> 
>> Specifically:
>> 
>>      Should libtasn1 be tied into GMP? libgcrypt? bc(1)? big number's
>>      for an INTEGER? type? All of the above? None of the above?
>> 
>> Alternatively, since ASN.1 and libtasn1 have no need for arithmetic per-se
>> (but might need a well defined MPI signed/unsigned comparison, haven't 
>> looked deeply yet),
>> INTEGER can likely be reworked as an opaque variable length octet array if
>> you wish to avoid having multiple MPI representations tied into libtasn1
>> and keep libtasn1 as a standalone library.
>> 
>> What say ye?

Libtasn1 already implements your alternative idea.  When you read an
integer value, it will return a byte array in two complement form.  See:

http://www.gnu.org/software/libtasn1/manual/libtasn1.html#asn1_005fread_005fvalue

We felt this way was simpler, as it lets the application chose whatever
MP implementation it wants.

As you noticed, picking one of GMP, libgcrypt, bc or anything else would
restrict the usefulness of Libtasn1 quite severely, and an opaque
variant seemed better.

/Simon