I guess the easiest way to understand and implement EnRUPT32 as a block cipher would be something like this:

#define er1(k) (rotr(2*x[(r-1)%xw]^x[(r+1)%xw]^k^r,8)*9^k)

enRUPT (u32 *x, const u32 xw, u32 *key, const u32 kw)
{
    u32 r, s=4, n=s*(2*xw+kw);
    for (r=1; r<=n; r++) x[r%xw] ^= er1(key[r%kw]);
}

unRUPT (u32 *x, const u32 xw, u32 *key, const u32 kw)
{
    u32 r, s=4, n=s*(2*xw+kw);
    for (r=n; r   ; r--) x[r%xw] ^= er1(key[r%kw]);
}

Yes. This is it. A complete block cipher. There is nothing more to it. If it is used with arbitrary but constant 2ⁿ block sizes, it should be almost as fast as an unrolled implementation, almost as fast as the AES for 4-word blocks and 4-word keys.

Another cycle of life has brought to everyone’s attention once again the fact that RAM is not erased instantly on power down, that its contents can be read by the attacker and that the pre-computed key schedules are sitting ducks.

What can I say? Yet another reason to use ciphers without pre-computed key schedules such as XTEA, XXTEA or EnRUPT. Random keys are hard to recognize in memory, but the key schedules with their well-known internal dependencies can be easily identified and recovered even after a major data loss caused by cutting the power. It got proven once again and is not going to change any time soon.

Without a pre-computed key schedule, most block ciphers including Twofish and the AES will be horribly slow and stream ciphers are not a good choice for disk encryption for a lot of other reasons. Out of all the block ciphers only XTEA, XXTEA and EnRUPT are fast without a pre-computed key schedule. They do not waste any time on the key schedule at all. Zero clock cycles, no additional memory and no help to the attacker in finding or recovering the secret keys in RAM after a cold boot.

I totally disagree with the authors of the paper on the countermeasures. Hashing memory or increasing complexity of the key schedule to prevent these attacks is insanity. I do not see why it is so hard to erase the encryption key and especially the pre-computed key schedule when the screen saver kicks in, since the user will have to re-authenticate anyway.

512-byte disk sectors encrypted with EnRUPT with an arbitrarily large random key are safe against cold boot attacks without any additional countermeasures. Loss of 16 bits of a 512-bit key for instance (3.1%) means natural 100-bit security against cold boot attacks even if the attacker knows precisely where the key is stored in memory, otherwise add roughly 30 bits on top of that. Yes. Simpler is better.

It is official, lads! The first specification of EnRUPT32 has been published at SASC-2008.

Download EnRUPT32 Specification PDF
View EnRUPT32 Specification in HTML
Download the latest C source code ZIP

Looks like there is still a lot of work to do before it can be submitted to the NIST competition – fast software implementations, basic cryptanalysis, ambiguities to fix, open questions to answer… But I doubt that I will change anything in the design unless someone points out a flaw in it or a way to improve its performance without sacrificing its simplicity or its flexibility or its scalability.

Suggestions and contributions are very welcome of course.