The updated specification paper includes EnRUPT64 since its automated cryptanalysis has been completed and revealed no significant differences comparing to the originally proposed EnRUPT32. Both variants have roughly the same security properties. Unfortunately, there is no way to keep them simple yet compatible with each other. They can only be used separately.

While originally EnRUPT specification only proposed a variant operating on 32-bit words, it was designed to support variable word length. The difference in word length only affects the rotation operation. It is w/4 (a quarter of the word length), not simply 8. Other word sizes have not been fully analysed yet and may require a different number of rounds to be secure as it is affected nonlinearly. While larger word sizes can be made secure, 16-bit words demonstrate significant weakness and cannot be used efficiently.

Performance of EnRUPT64 is much better than EnRUPT32 on 64-bit processors but much worse on 32-bit processors (about 2 times slower than EnRUPT32). Both perform equally well on 8-bit microprocessors except for small 64-bit blocks [minimum block size of EnRUPT64 is 128 bits], while EnRUPT64 is slightly faster on 16-bit microprocessors due to the absence of rotations.

EnRUPT specification has been updated to reflect a change to one of the recommended modes of operation. We have found the new unkeyed unrandomised stream hashing mode proposed in the original paper to be insecure and therefore not suitable for irRUPT. This weakness is purely structural. It does not depend on the underlying round function or structure of the underlying authenticated stream cipher. A paper describing the vulnerability of this mode is on the way. In the mean time EnRUPT specification was updated with the most optimal solution we see. No other modes of operation are affected.

There are two ways to construct stream hashing using (ir1) round function, which would make irRUPT resistant against the attack we have discovered. One is to keep it as it is while re-sealing the state as soon as a half of it is filled with data, not after all of it is filled [i.e. between every xw/2 words of input]. This solution unfortunately comes at a high cost: irRUPT would be 5 times slower than mcRUPT or RUPT stream cipher. The second solution is simply to slow down the hashing process 3 times, which most probably no longer requires the frequent sealing stages at all.

“Most probably” because there is simply no cryptologic theory to rely on, but only our best judgement and our own attempts to analyse it. Stream hashing is a new research area and should not be used without caution and thorough cryptanalysis. We cannot guarantee with as much certainty as for the rest of EnRUPT that this new hashing mode is secure. Nobody can. Digital cryptology is a new and highly under-researched area. There are currently no guaranteed well-studied secure hashing modes. Therefore any applications requiring secure hashing should either use randomisation or rely on the better-studied block hashing modes such as the strengthened Merkle-Damgård used for mdRUPT.

Unkeyed irRUPT mode with a random IV [same as mcRUPT] is as fast as RUPT stream cipher and thanks to its final secure sealing process [as secure as RUPT stream cipher], it can provide sufficient preimage resistance, while all the applications that can rely on random nonces in their hashing processes [either providing them themselves or relying on trusted third parties calculating and digitally signing those hashes] can benefit from the high speed and high collision resistance with much shorter hash values and 3 times faster hashing also requiring less memory. For instance, a 96-bit IV combined with a 96-bit randomised hash value provides the same 96-bit secure collision resistance as a 192-bit hash and 96-bit secure preimage resistance. The only limitation is that it can be used only in the applications providing a trusted digital signature.