Talk:Tiny Encryption Algorithm

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]