[Patches] [ python-Patches-923643 ] long <-> byte-string conversion

SourceForge.net noreply at sourceforge.net
Sat Mar 27 01:45:54 EST 2004


Patches item #923643, was opened at 2004-03-25 19:17
Message generated for change (Comment added) made by trevp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=923643&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Trevor Perrin (trevp)
Assigned to: Nobody/Anonymous (nobody)
Summary: long <-> byte-string conversion

Initial Comment:

Sometimes you want to turn a long into a byte-string, 
or vice-versa.  This is useful in cryptographic protocols, 
and probably other network protocols where you need 
to exchange large integers.

In 2.4, you can handle unsigned longs with this:

def stringToLong(s):
    return long(binascii.hexlify(s), 16)

def longToString(n):
    return binascii.unhexlify("%x" % n)

However, these functions are slower than they need to 
be, they&#039;re kinda kludgey, and they don&#039;t handle 
negative values.

So here&#039;s a proposal:

def stringToLong(s):
    return long(s, 256)

def longToString(n):
    return n.tostring()

These functions operate on big-endian, 2&#039;s-complement 
byte-strings.  If the value is positive but has its most-
significant-bit set, an extra zero-byte will be 
prepended.  This is the same way OpenSSL and (I think) 
GMP handle signed numbers.

These functions are ~5x faster than the earlier ones, 
they&#039;re cleaner, and they work with negative numbers.  

If you only want to deal with unsigned positive numbers, 
you&#039;ll have to do some adjustments:

def stringToLong(s):
    return long(&#039;\0&#039;+s, 256)

def longToString(n):
    s = n.tostring()
    if s[0] == &#039;\0&#039; and s != &#039;\0&#039;:
        s = s[1:]
    return s

That&#039;s not ideal, but it seems better than any interface 
change I could think of.

Anyways, the patch adds this to longs.  It should be 
added to ints too, and I guess it needs tests etc..  I 
can help with that, if the basic idea is acceptable.

Trevor

----------------------------------------------------------------------

>Comment By: Trevor Perrin (trevp)
Date: 2004-03-26 22:45

Message:
Logged In: YES 
user_id=973611

You're right, we should support unsigned strings somehow.  
Adding another argument to the int() and long() constructors 
would be messy, though.  How about:

n = long(s, 256) #unsigned
n = long(s, -256) #signed

n.tounsignedstring()
n.tosignedstring()

The "-256" thing is a hack, I admit..  but it kinda grows on 
you, if you stare it at awhile :-)...






----------------------------------------------------------------------

Comment By: Trevor Perrin (trevp)
Date: 2004-03-26 22:45

Message:
Logged In: YES 
user_id=973611

You're right, we should support unsigned strings somehow.  
Adding another argument to the int() and long() constructors 
would be messy, though.  How about:

n = long(s, 256) #unsigned
n = long(s, -256) #signed

n.tounsignedstring()
n.tosignedstring()

The "-256" thing is a hack, I admit..  but it kinda grows on 
you, if you stare it at awhile :-)...






----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-25 19:53

Message:
Logged In: YES 
user_id=72053

I think those funcs should take an optional extra arg to say
you want unsigned.  That's cleaner than prepending '0'.  In
cryptography you usually do want unsigned.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=923643&group_id=5470



More information about the Patches mailing list