Talk:Tiny Encryption Algorithm

From Wikipedia, the free encyclopedia

This article is part of WikiProject Cryptography, an attempt to build a comprehensive and detailed guide to cryptography on Wikipedia. If you would like to participate, you can choose to edit the article attached to this page, or visit the project page, where you can join the project and see a list of open tasks.

[edit] Efficiency versus simplicity

I'm pondering whether it's better to replace the current version, which is tuned for efficiency, with the simplest possible version, which is probably this:

void encrypt(unsigned long* v, unsigned long* k) {
    unsigned long delta=0x9e3779b9, sum=0, i;           /* a key schedule constant */
    for (i=0; i < 32; i++) {                            /* basic cycle start */
        sum += delta;
        v[0] += (v[1]<<4)+k[0] ^ v[1]+sum ^ (v[1]>>5)+k[1];
        v[1] += (v[0]<<4)+k[2] ^ v[0]+sum ^ (v[0]>>5)+k[3];    /* end cycle */
    }
}

Since storing array entries in registers is a very difficult optimization to perform safely, I suspect compilers will tend to produce slow code for this. On the other hand, I just killed another 3 lines, and it's nicer to look at. Thoughts on this? Derrick Coetzee 01:53, 24 Sep 2004 (UTC)

I've verified that gcc produces much worse code for this version on both RISC and CISC platforms. I think the version on the page should probably stay. Derrick Coetzee 01:58, 24 Sep 2004 (UTC)

Do this will not change anything ..

I would expect part of the slow down to be from alias analysis; gcc has no way of knowing from the above code that v and k don't point to overlapping memory addresses, so it can't just store v[0] and v[1] in registers. Try using the restricted flag for the arguments. 198.205.32.93 17:11, 22 November 2006 (UTC)

I would prefer to see this in the article. As the lead section says "[...] a block cipher notable for its simplicity of description and implementation", I think we should have the simplest possible example for illustrative purposes, to demonstrate its simplicty. We can just add a note saying "for a more efficient implementation, refer to ...". -- intgr 19:26, 22 November 2006 (UTC)

[edit] Endianness?

TEA, XTEA, and XXTEA appear to be sensitive to endianness. They take blocks of (presumably 32-bit) longs; however, most messages in practice are defined as a stream of bytes, not longs. Have the authors specified an ordering for bytes within 32-bit units, or have they left it unspecified on purpose? And what happens to the reference code on a platform where longs are 64-bit? --Damian Yerrick (talk | stalk) 01:15, 6 July 2007 (UTC)

This is indeed something that the article should answer; I've been wondering the same. -- intgr [talk] 14:56, 21 October 2007 (UTC)

[edit] Completely public domain

What does "completely in the public domain" mean? What is difference between AES and TEA in this matter? --89.172.45.103 12:35, 21 October 2007 (UTC)

There is no difference; there are various implementations of AES in the public domain and neither are subject to patents. In fact, nearly all popular ciphers are unencumbered these days. This looks like a silly attempt to promote TEA; I have toned down this statement. -- intgr [talk] 14:55, 21 October 2007 (UTC)

[edit] Broken Reference Code

I had to implement TEA a while ago and remember that the reference code (as provided here) was broken. :( Further poking around lead me to this page ( http://www.thescripts.com/forum/thread215505.html ) which says:

"Okay, Ben, I've done my homework now, and I can safely say that

you've been misled by sloppy academic types. :-) The original paper

on TEA, by Wheeler & Needham, is WRONG WRONG WRONG with respect to

the reference implementation they provide. They left out several

crucial pairs of parentheses, and both you and I were confused by

that. Rightly so."

My (tested, working version) has the following for encoding and decoding respectively (with extra parentheses for fixed operator precedence):

encode:

for (int i=0; i<kNumRounds; ++i)
{
        s += kDelta;
        y += (z << 4) + (k0 ^ z) + (s ^ (z >> 5)) + k1;
        z += (y << 4) + (k2 ^ y) + (s ^ (y >> 5)) + k3;
}

decode:

for (int i=0; i<kNumRounds; ++i)
{
        z -= (y << 4) + (k2 ^ y) + (s ^ (y >> 5)) + k3;
        y -= (z << 4) + (k0 ^ z) + (s ^ (z >> 5)) + k1;
                s -= kDelta;
}

However I have no test data to confirm that this is actually TEA, rather than just something similar to it (the reference code doesn't even encrypt and decrypt to the same result). It looks like someone has already fixed up the XTEA page since theres a comment about "It is also important to note that some modern programming languages have a slightly different operators order of precedence. Therefore, the interpretation of the original code will lead to different results, making different implementations of the encryption incompatible. This can be corrected with the use of a few parenthesis to enforce precedence order."

Can someone confirm my results before changing the code in the article? 217.18.21.2 14:22, 12 November 2007 (UTC)