Talk:Tiny Encryption Algorithm

Cryptography: Computer science Unassessed

	This article is within the scope of WikiProject Cryptography, a collaborative effort to improve the coverage of Cryptography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.CryptographyWikipedia:WikiProject CryptographyTemplate:WikiProject CryptographyCryptography
???	This article has not yet received a rating on Wikipedia's content assessment scale.
???	This article has not yet received a rating on the importance scale.
	This article is supported by WikiProject Computer science.

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]