python number handling - tiny encryption algorithm

[Kinsley Turner]

Hey-ho,

I'm getting a bit out of my depth porting the 'tiny encryption algorithm'
from C to python.

Ref:
http://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm
http://www.simonshepherd.supanet.com...e.htm#new_ansi

Specifically I don;t know how to handle a C-long block and perform the
mathmatical manipulations in python syntax. I played with pack and unpack
(from struct module) but that didn't seem to buy me anything.

In my version, I end up with hugely long integers, which have obviously
not be constrained into the 4-byte unsigned longs that TEA is expecting.

This is the C function:

/* v is 64-bits input, w is 64-bits output, k is the 128-bit key */
void decipher(const unsigned long *const v,unsigned long *const w, const
unsigned long * const k)
{
register unsigned long
y=v[0],z=v[1],sum=0xC6EF3720,delta=0x9E3779B9,n=32;

while(n-->0)
{
z -= (y << 4 ^ y >> 5) + y ^ sum + k[sum>>11 & 3];
sum -= delta;
y -= (z << 4 ^ z >> 5) + z ^ sum + k[sum&3];
}
w[0]=y; w[1]=z;
}
Which gives me a (broken) python version:

def teaDecipher(input,key):
y = input[0]
z = input[1]
n = 32
sum = 0xC6EF3720
delta=0x9E3779B9

while (n > 0):
n -= 1
z -= (y << 4 ^ y >> 5) + y ^ sum + key[sum>>11 & 3];
sum -= delta;
y -= (z << 4 ^ z >> 5) + z ^ sum + key[sum&3];
return y,z

That seems to return hugely-long integers (around 30? digits), whereas I'd
expect
them to max-out at 2^32.

Perhaps I'm not packing the input or the key properly. My inputs are
just strings which I put into an integer with the ordinal value of each
character
shifted into the correct position to make the C-long.

Something like:
input[0] = ord(encrypted[i])<<24 + ord(encrypted[i+1])<<16 +
ord(encrypted[i+2])<<8 + ord(encrypted[i+3])
input[1] = ord(encrypted[i+4])<<24 + ord(encrypted[i+5])<<16 +
ord(encrypted[i+6])<<8 + ord(encrypted[i+7])

The key is created as an array of numbers, each the ord() of the key
character...
Anyway, that's about it.
Any help much appreciated.
thanks,
-kt







(non-removable disclaimer below... *sigh*)
--

Please consider our environment before printing this email.

WARNING - This email and any attachments may be confidential. If received in error, please delete and inform us by return email. Because emails and attachments may be interfered with, may contain computer viruses or other defects and may not be successfully replicated on other systems, you must be cautious. Westpac cannot guarantee that what you receive is what we sent. If you have any doubts about the authenticity of an email by Westpac, please contact us immediately.

It is also important to check for viruses and defects before opening or using attachments. Westpac's liability is limited to resupplying any affected attachments.
This email and its attachments are not intended to constitute any form of financial advice or recommendation of, or an offer to buy or offer to sell, any security or other financial product. We recommend that you seek your own independent legal or financial advice before proceeding with any investment decision.

Westpac Institutional Bank is a division of Westpac Banking Corporation, a company registered in New South Wales in Australia under the Corporations Act 2001 (Cth). Westpac is authorised and regulated in the United Kingdom by the Financial Services Authority and is registered at Cardiff in the United Kingdom as Branch No. BR 106. Westpac operates in the United States of America as a federally chartered branch, regulated by the Office of the Comptroller of the Currency.

Westpac Banking Corporation ABN 33 007 457 141.

[Paul Rubin]

Kinsley Turner <ki************@westpac.com.au> writes:

In my version, I end up with hugely long integers, which have obviously
not be constrained into the 4-byte unsigned longs that TEA is expecting.

Yeah, Python promotes to long int now. The simplest way to do the
32-bit arithmetic you need is probably with the array module.

[Scott David Daniels]

Kinsley Turner wrote:

I'm getting a bit out of my depth porting the 'tiny encryption algorithm'
from C to python....
In my version, I end up with hugely long integers, which have obviously
not be constrained into the 4-byte unsigned longs that TEA is expecting.
...
def teaDecipher(input,key):
y = input[0]
z = input[1]
n = 32
sum = 0xC6EF3720
delta=0x9E3779B9
while (n > 0):
n -= 1
z -= (y << 4 ^ y >> 5) + y ^ sum + key[sum>>11 & 3];
sum -= delta;
y -= (z << 4 ^ z >> 5) + z ^ sum + key[sum&3];
return y,z

That seems to return hugely-long integers (around 30? digits), whereas
I'd expect them to max-out at 2^32.

If you really want 32-bit arithmetic, you need to specify it.
Do you have to rewrite the C for 64-bit machines?
For example:

MASK = (1 << 32) - 1
def teaDecipher(input, key):
y = input[0]
z = input[1]
sum = 0xC6EF3720
delta = 0x9E3779B9
for n in range(32):
z = MASK & (z - (y << 4 ^ y >> 5) - y ^ sum - key[sum>>11 & 3])
sum = MASK & (sum - delta)
y = MASK & (y - (z << 4 ^ z >> 5) - z ^ sum - key[sum&3])
return y, z

--Scott David Daniels
sc***********@acm.org

[Bernhard Mulder]

One systematic, if maybe clumsy way, is to mimic the C arithmetic
operations more closely in Python. If you do, for example, a left shift
in C, the result is always returned in a certain precision, 64 bits in
the example below. In python, no bits are lost, so you have to force the
result into the 64 bits back to obtain the same result.

Instead of (y << 4) you can write something like (untested!) (y << 4) &
0xFF...FF.

Once you understand what the algorithm is doing, you may want to go back
and express the algorithm in a more pythonic way (not by programming C
in Python).

Kinsley Turner wrote:

Hey-ho,

I'm getting a bit out of my depth porting the 'tiny encryption algorithm'
from C to python.

Ref:
http://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm
http://www.simonshepherd.supanet.com...e.htm#new_ansi

Specifically I don;t know how to handle a C-long block and perform the
mathmatical manipulations in python syntax. I played with pack and unpack
(from struct module) but that didn't seem to buy me anything.

In my version, I end up with hugely long integers, which have obviously
not be constrained into the 4-byte unsigned longs that TEA is expecting.

This is the C function:

/* v is 64-bits input, w is 64-bits output, k is the 128-bit key */
void decipher(const unsigned long *const v,unsigned long *const w, const
unsigned long * const k)
{
register unsigned long
y=v[0],z=v[1],sum=0xC6EF3720,delta=0x9E3779B9,n=32;

while(n-->0)
{
z -= (y << 4 ^ y >> 5) + y ^ sum + k[sum>>11 & 3];
sum -= delta;
y -= (z << 4 ^ z >> 5) + z ^ sum + k[sum&3];
}
w[0]=y; w[1]=z;
}
Which gives me a (broken) python version:

def teaDecipher(input,key):
y = input[0]
z = input[1]
n = 32
sum = 0xC6EF3720
delta=0x9E3779B9

while (n > 0):
n -= 1
z -= (y << 4 ^ y >> 5) + y ^ sum + key[sum>>11 & 3];
sum -= delta;
y -= (z << 4 ^ z >> 5) + z ^ sum + key[sum&3];
return y,z

That seems to return hugely-long integers (around 30? digits), whereas I'd
expect
them to max-out at 2^32.

Perhaps I'm not packing the input or the key properly. My inputs are
just strings which I put into an integer with the ordinal value of each
character
shifted into the correct position to make the C-long.

Something like:
input[0] = ord(encrypted[i])<<24 + ord(encrypted[i+1])<<16 +
ord(encrypted[i+2])<<8 + ord(encrypted[i+3])
input[1] = ord(encrypted[i+4])<<24 + ord(encrypted[i+5])<<16 +
ord(encrypted[i+6])<<8 + ord(encrypted[i+7])

The key is created as an array of numbers, each the ord() of the key
character...
Anyway, that's about it.
Any help much appreciated.
thanks,
-kt







(non-removable disclaimer below... *sigh*)
--

Please consider our environment before printing this email.

WARNING - This email and any attachments may be confidential. If received in error, please delete and inform us by return email. Because emails and attachments may be interfered with, may contain computer viruses or other defects and may not be successfully replicated on other systems, you must be cautious. Westpac cannot guarantee that what you receive is what we sent. If you have any doubts about the authenticity of an email by Westpac, please contact us immediately.

It is also important to check for viruses and defects before opening or using attachments. Westpac's liability is limited to resupplying any affected attachments.
This email and its attachments are not intended to constitute any form of financial advice or recommendation of, or an offer to buy or offer to sell, any security or other financial product. We recommend that you seek your own independent legal or financial advice before proceeding with any investment decision.

Westpac Institutional Bank is a division of Westpac Banking Corporation, a company registered in New South Wales in Australia under the Corporations Act 2001 (Cth). Westpac is authorised and regulated in the United Kingdom by the Financial Services Authority and is registered at Cardiff in the United Kingdom as Branch No. BR 106. Westpac operates in the United States of America as a federally chartered branch, regulated by the Office of the Comptroller of the Currency.

Westpac Banking Corporation ABN 33 007 457 141.

[Bernhard Mulder]

One systematic, if maybe clumsy way, is to mimic the C arithmetic
operations more closely in Python. If you do, for example, a left shift
in C, the result is always returned in a certain precision, 64 bits in
the example below. In python, no bits are lost, so you have to force the
result into the 64 bits back to obtain the same result.

Instead of (y << 4) you can write something like (untested!) (y << 4) &
0xFF...FF.

Once you understand what the algorithm is doing, you may want to go back
and express the algorithm in a more pythonic way (not by programming C
in Python).

Kinsley Turner wrote:

Hey-ho,

I'm getting a bit out of my depth porting the 'tiny encryption algorithm'
from C to python.

Ref:
http://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm
http://www.simonshepherd.supanet.com...e.htm#new_ansi

Specifically I don;t know how to handle a C-long block and perform the
mathmatical manipulations in python syntax. I played with pack and unpack
(from struct module) but that didn't seem to buy me anything.

In my version, I end up with hugely long integers, which have obviously
not be constrained into the 4-byte unsigned longs that TEA is expecting.

This is the C function:

/* v is 64-bits input, w is 64-bits output, k is the 128-bit key */
void decipher(const unsigned long *const v,unsigned long *const w, const
unsigned long * const k)
{
register unsigned long
y=v[0],z=v[1],sum=0xC6EF3720,delta=0x9E3779B9,n=32;

while(n-->0)
{
z -= (y << 4 ^ y >> 5) + y ^ sum + k[sum>>11 & 3];
sum -= delta;
y -= (z << 4 ^ z >> 5) + z ^ sum + k[sum&3];
}
w[0]=y; w[1]=z;
}
Which gives me a (broken) python version:

def teaDecipher(input,key):
y = input[0]
z = input[1]
n = 32
sum = 0xC6EF3720
delta=0x9E3779B9

while (n > 0):
n -= 1
z -= (y << 4 ^ y >> 5) + y ^ sum + key[sum>>11 & 3];
sum -= delta;
y -= (z << 4 ^ z >> 5) + z ^ sum + key[sum&3];
return y,z

That seems to return hugely-long integers (around 30? digits), whereas I'd
expect
them to max-out at 2^32.

Perhaps I'm not packing the input or the key properly. My inputs are
just strings which I put into an integer with the ordinal value of each
character
shifted into the correct position to make the C-long.

Something like:
input[0] = ord(encrypted[i])<<24 + ord(encrypted[i+1])<<16 +
ord(encrypted[i+2])<<8 + ord(encrypted[i+3])
input[1] = ord(encrypted[i+4])<<24 + ord(encrypted[i+5])<<16 +
ord(encrypted[i+6])<<8 + ord(encrypted[i+7])

The key is created as an array of numbers, each the ord() of the key
character...
Anyway, that's about it.
Any help much appreciated.
thanks,
-kt







(non-removable disclaimer below... *sigh*)
--

Please consider our environment before printing this email.

WARNING - This email and any attachments may be confidential. If received in error, please delete and inform us by return email. Because emails and attachments may be interfered with, may contain computer viruses or other defects and may not be successfully replicated on other systems, you must be cautious. Westpac cannot guarantee that what you receive is what we sent. If you have any doubts about the authenticity of an email by Westpac, please contact us immediately.

It is also important to check for viruses and defects before opening or using attachments. Westpac's liability is limited to resupplying any affected attachments.
This email and its attachments are not intended to constitute any form of financial advice or recommendation of, or an offer to buy or offer to sell, any security or other financial product. We recommend that you seek your own independent legal or financial advice before proceeding with any investment decision.

Westpac Institutional Bank is a division of Westpac Banking Corporation, a company registered in New South Wales in Australia under the Corporations Act 2001 (Cth). Westpac is authorised and regulated in the United Kingdom by the Financial Services Authority and is registered at Cardiff in the United Kingdom as Branch No. BR 106. Westpac operates in the United States of America as a federally chartered branch, regulated by the Office of the Comptroller of the Currency.

Westpac Banking Corporation ABN 33 007 457 141.