Over the next several months, a huge number of stream ciphers were submitted to ECRYPT. ECRYPT has several web pages describing the ciphers:
| eSTREAM status | Name | Key bits | Security conjecture | Authors; policy | Documents |
|---|---|---|---|---|---|
| SW focus; HW | LEX: version 1; version 2 | 256 | 256 | Alex Biryukov | paper |
| SW focus; HW | Salsa20 (Snuffle 2005) | 256 | 256 | Daniel J. Bernstein; ``My policy is that Salsa20 is free for everyone to use'' | C spec security design speed robustness IP link |
| SW focus | Dragon | 256 | 256 | Ed Dawson, Kevin Chen, Matt Henricksen, William Millan, Leonie Simpson, HoonJae Lee, SangJae Moon | C paper |
| SW focus | HC-256 | 256 | 256 | Hongjun Wu; ``HC-256 is not covered by any patent and it is freely available'' | paper |
| SW focus | Py (limited to 2^64 bytes per key), Py6 (limited to 2^64 bytes per key), PyPy, PyPy6 | 256 | 256 | Eli Biham, Jennifer Seberry; ``No royalty will be necessary for use of Py'' | C paper |
| SW; HW | YAMB | 256 | 256 | Anatoly N. Lebedev, Alexander Ivanov, Sergey Starodubtzev, Alexey Kolchkov | C paper |
| SW | CryptMT: version 1; version 2 | 256 | 256 | Makoto Matsumoto, Hagita Mariko, Takuji Nishimura, Matsuo Saito; patented | paper |
| HW | VEST | 256 | 256 | Claude Bigeard, Sean O'Neil, Benjamin Gittins, Howard Landman; patented | paper |
| Fubuki | 256 | 256 | Makoto Matsumoto, Hagita Mariko, Takuji Nishimura, Matsuo Saito; patented | paper | |
| MAG: version 1 withdrawn; version 2; version 3 | 256 | 256 | Rade Vuckovac | paper | |
| SW focus | SOSEMANUK | 256 | 224 | Come Berbain, Olivier Billet, Anne Canteaut, Nicolas Courtois, Henri Gilbert, Louis Goubin, Aline Gouget, Louis Granboulan, Cedric Lauradoux, Marine Minier, Thomas Pornin, Herve Sibert; ``Permission is granted to anyone to use this software for any purpose, including commercial applications'' | C paper |
| SW focus; HW focus | Phelix | 256 | 128 | Doug Whiting, Bruce Schneier, Stefan Lucks, Frederic Muller; ``We hereby explicitly release any intellectual property rights to Phelix into the public domain'' | C paper link |
| HW focus | MICKEY | 128 | 128 | Steve Babbage, Matthew Dodd | paper |
| SW; HW | Non-Linear SOBER (NLS): version 1 withdrawn; version 2 | 128 | 128 | Gregory Rose, Philip Hawkes, Michael Paddon, Miriam Wiggers de Vries; ``QUALCOMM Incorporated allows free and unrestricted use of any of its intellectual property required to exercise the primitive'' | C paper link |
| SW; HW | Rabbit | 128 | 128 | Martin Boesgaard, Mette Vesterager, Thomas Christensen, Erik Zenner; patented | C paper link |
| SW | DICING: version 0 withdrawn; version 1; version 2 | 128 | 128 | Li An-Ping | paper v1 |
| HW | Hermes8 | 128 | 128 | Ulrich Kaiser | paper |
| HW | POMARANCH (CJCSG) version 1 withdrawn; version 2 | 128 | 128 | Cees Jansen, Tor Helleseth, Alexander Kholosha | paper; paper; v2 |
| HW | WG: version 1 withdrawn; version 2 | 128 | 128 | Guang Gong, Yassir Nawaz | paper; subsequent corrections; v2 |
| HW | ZK-Crypt: version 1 withdrawn; version 2 | 128 | 128 | Carmi Gressel, Ran Granot, Gabi Vago; patented | |
| F-FCSR-8: version 1 withdrawn; version 2 | 128 | 128 | Thierry Berger, Francois Arnault, Cedric Lauradoux | paper v2 | |
| HW focus | Grain: version 1 withdrawn; version 2 | 80 | 80 | Martin Hell, Thomas Johansson, Willi Meier | paper; subsequent corrections |
| HW focus | Trivium | 80 | 80 | Christophe De Canniere, Bart Preneel | paper |
| HW | DECIM: version 1 withdrawn; version 2 | 80 | 80 | Come Berbain, Olivier Billet, Anne Canteaut, Nicolas Courtois, Blandine Debraize, Henri Gilbert, Louis Goubin, Aline Gouget, Louis Granboulan, Cedric Lauradoux, Marine Minier, Thomas Pornin, Herve Sibert; patented | paper |
| HW | Edon80 | 80 | 80 | Danilo Gligoroski, Smile Markovski, Ljupco Kocarev, Marjan Gusev | desc robustness security advantages design speed impl |
| HW | F-FCSR-H: version 1 withdrawn; version 2 | 80 | 80 | Thierry Berger, Francois Arnault, Cedric Lauradoux | paper v2 |
| HW | SFINKS | 80 | 80 | An Braeken, Joseph Lano, Nele Mentens, Bart Preneel, Ingrid Verbauwhede | paper |
| SW; HW | Polar Bear withdrawn | 128 | low | Johan Haastad, Mats Naeslund | paper |
| SW | ABC: version 1 withdrawn; version 2 withdrawn | 128 | low | Vladimir Anashin, Andrey Bogdanov, Ilya Kizhvatov, Sandeep Kumar | C paper v2 |
| HW | Mosquito withdrawn | 96 | low | Joan Daemen, Paris Kitsos | paper; subsequent corrections |
| HW | TSC-3 withdrawn | 80 | low | Jin Hong, Dong Hoon Lee, Yongjin Yeom, Daewan Han, Seongtaek Chee | paper |
| HW | Achterbahn: version 1 withdrawn; version 2 | 80 | low | Berndt Gammel, Rainer Goettfert, Oliver Kniffler | paper v2 |
| Frogbit | 128 | low | Thierry Moreau; patented | paper | |
| Mir-1 | 128 | low | Alexander Maximov | paper; subsequent asm | |
| Self-Synchronous SOBER (SSS) withdrawn | 128 | low | Gregory Rose, Philip Hawkes, Michael Paddon, Miriam Wiggers de Vries; ``QUALCOMM Incorporated allows free and unrestricted use of any of its intellectual property required to exercise the primitive'' | paper link | |
| TRBDK3 YAEA | Timothy Brigham | paper | |||
To figure out the encryption+authentication speed of a pure-encryption stream cipher, one must select an authentication mechanism, and add the authentication time to the encryption time. Here's a quick summary of authentication speeds:
Among the stream-cipher submissions, Frogbit, NLS, Phelix, SFINKS, SSS, and VEST are labelled as incorporating authentication mechanisms. My impression is that NLS, SFINKS, and VEST are actually pure-encryption stream ciphers attached to separate authenticators; in all three cases, the separate authenticators are slower than (e.g.) Poly1305, so they should be ignored, and the underlying pure-encryption stream cipher should be evaluated on its own merits. Phelix, on the other hand, can't be separated in this way.
wget http://cr.yp.to/streamciphers/timings/trunk-20060302-163.tar.gz
tar -xzf trunk-20060302-163.tar.gz
mv trunk trunk-20060302-163
cd trunk-20060302-163
chmod +x start scripts/*
(echo '';echo '';echo '';echo '';echo '') | scripts/configure
cd reports-`hostname`
(../scripts/run; echo ''|../scripts/collect) > run.log 2>&1
The collection is much better than most timing efforts I've seen,
but it can use some further improvements.
More CPUs. I've run the timing tools on several CPUs beyond the official list. Here are all the timing results I'm aware of:
Better output format for computer processing. My timings256 file contains the latest speed reports in a documented format suitable for further processing. This file was produced by my timings256.do script using my machines file as input. The script downloads the latest speed reports for 256-bit ciphers and converts them from HTML into the documented format.
The timings256 format has four columns separated by spaces. The first column is a type of encryption: for example, cipher576 for setting up a nonce and encrypting 576 bytes. The second column is a machine name: alpha, amd64, etc. The third column is a cipher name: Py6, for example, or HC256. The fourth column is cycles per byte. For example,
cipherlong powerbookg4 Salsa20 4.2
indicates that encrypting a long stream on the machine named powerbookg4
takes 4.2 cycles per byte using Salsa20.
My chipspeed file is a list of machine names sorted by the geometric average of cycles per byte. This file was produced by feeding timings256 through chipspeed.do.
Better output formats for human processing. I have a paper comparing the speeds (and other features) of the 256-bit ciphers:
At the SASC 2006 workshop I used an interactive tool to move around graphs similar to the graphs in the paper. Here's how to download and use the tool:
wget http://cr.yp.to/streamciphers/estreamdraw.c.20060205
wget http://cr.yp.to/streamciphers/machines-uptodate
wget http://cr.yp.to/streamciphers/ciphers
wget http://cr.yp.to/streamciphers/timingsall
cp estreamdraw.c.20060205 estreamdraw.c
gcc -o estreamdraw estreamdraw.c \
-I/usr/X11R6/include -L/usr/X11R6/lib -lXm -lX11 -lm
cat machines-uptodate ciphers timingsall | ./estreamdraw
Keyboard commands: q to quit,
h and l to move x positions,
j and k to select other ciphers,
= and - to select or deselect a second cipher,
o and O to add or subtract overhead,
[ and ] and space to switch among graphs.
You may want to replace the ciphers file by a shorter file
to focus on a smaller set of ciphers.
Portability issue: Ulrich Kaiser reports having to change
iso10646 to iso8859 in estreamdraw.c to avoid a
``BadName (named color or font does not exist)'' error.
Better portability. The timing tools are Linux-specific and to some extent x86-specific:
More security. Different levels of brute-force protection (80 bits, 128 bits, 256 bits) are timed separately, but different levels of timing-attack protection (protected, unprotected) are not. This is important: it's clear that protected Py code, for example, will be much slower than unprotected Py code.
More message lengths. Different message lengths aren't systematically timed. The current spread of 40, 576, etc. doesn't capture the fact that, for example, Salsa20 takes as long to encrypt 1 byte as to encrypt 64 bytes.
More levels of instruction-cache competition. Different amounts of competition for instruction-cache space aren't systematically timed. Instruction-cache misses are expensive; a cipher that doesn't leave room in cache for the rest of the network stack might do well on benchmarks but will do badly in real-world tests.
More levels of parallelism. Different numbers of simultaneous keys aren't systematically timed. Different numbers of simultaneous messages aren't systematically timed.
More than just software. Cipher cost should also be measured in various hardware contexts.
An-Ping made two claims, with no computer verification, of attacks on Salsa20: [PDF]. In my paper ``Disproof of Li An-Ping's claims regarding Salsa20,'' I reported computer experiments disproving the claims, and I explained two fatal flaws in An-Ping's ``analysis'': [PDF]. An-Ping eventually admitted one flaw and withdrew the first two claims. An-Ping then issued a third claim, again without computer verification: [PDF]. An-Ping's ``analysis'' again contains the fatal flaw discussed in Section 5 of my paper; one could use a similar ``analysis'' to make false claims of bias in any combination of output bits in any cipher. Current consensus is that An-Ping is obliged to stop making cryptanalytic claims without computer verification.
Crowley reports a 2^165-operation distinguishing attack on a 5-round variant of Salsa20: [PDF].
Dragon-256. Initial impression: Timing-attack problems, like AES.
Englund and Maximov state an attack on Dragon-256 using 2^155 words of keystream and 2^32 blocks of memory. Paper: [PDF]. Authors respond that the Dragon-256 documentation had already recommended generating no more than 2^64 bits per key, making the attack impossible. Paper: [PDF].
Py. Py is reminiscent of RC4. Its state modifications are somewhat more complicated, but it gains speed in two ways: using 32-bit words instead of 8-bit words, and producing 2 words of output each round instead of 1.
Py6 is a scaled-down version of Py. Smaller key-loading time and nonce-loading time; same cycles/byte to encrypt a big block. I find Py6 considerably more interesting than Py, because its state size is much more reasonable.
The table lookups in Py take variable time. I don't see any obstacles to a cache-timing attack obtaining the entire Py expanded key. Specifically, the first lookup indices appear to be extremely simple functions of the nonce and a few expanded-key bytes, exposing those expanded-key bytes to a cache-timing attack; the next few lookup indices appear to be extremely simple functions of the nonce, the known expanded-key bytes, and a few more expanded-key bytes, exposing those expanded-key bytes to a cache-timing attack; etc.
Aside from timing attacks, a huge state seems like a good idea from a security perspective. The simplest update functions, as in RC4, allow attacks, but something marginally more complicated seems fine.
A huge state is a bad idea from the perspective of hardware performance, and from the perspective of small-packet performance. Low-overhead ciphers such as Salsa20 will already have finished encrypting an average-size Internet packet before Py has finished loading a nonce.
Sekar, Paul, and Preneel appear to claim that the first 24 bytes of Py output for 2^83.82 nonces are quickly distinguishable from uniform. Paper: [PDF]. Crowley reports a reduction to 2^73 nonces. The authors respond that Py and Py6 must not be used for more than 2^64 bytes per key.
HC-256. HC-256 converts the key and nonce into two huge 10-bit-to-32-bit tables. It sweeps sequentially through one table, updating that table using random accesses to the other table, and generating output at the same time; it then sweeps sequentially through the other table, updating that table using random accesses to the first table, and generating output at the same time. The alternating-table approach allows some parallelism.
The table lookups in HC-256 take variable time. I don't see how to carry out a cache-timing attack that uses solely the total HC-256 time: the array indices in HC-256 are extremely complicated, and not visibly related, functions of the nonce. But it should be easy to carry out a cache-timing attack on HC-256 using the time for individual operations: e.g., a hyperthreading attack or a process-interruption attack.
HC-256 is even worse than Py from the perspective of small-packet performance. Low-overhead ciphers such as Salsa20 will already have finished encrypting thousands of bytes before HC-256 has finished loading a nonce.
YAMB. Initial impression: Timing-attack problems, like RC4.
Hongjun Wu writes: ``There is a distinguishing attack on Yamb. It requires about $2^{58}$ outputs and about $2^{55}$ simple operations (32-bit addition or subtraction).'' Paper: [PDF].
The authors finally responded several months later, disputing the attack.
Phelix. Each Phelix block feeds the input through 13 adds, 11 xors, and 20 constant-distance rotations to produce a 4-byte block of output. Overall 11 operations per byte (3.25 adds, 2.75 xors, 5 rotations). Key expansion takes a few additional operations per block. For comparison, Salsa20 performs 15 operations per byte (5 adds, 5 xors, 5 rotations), plus final xoring, plus the cost of authentication.
Initial impression: Phelix, like Salsa20, follows TEA in using a long chain of simple operations. It's fine from a timing-attack perspective. Phelix is less conservative than Salsa20 but is usually faster. Exceptions: Salsa20 is faster than Phelix when the hardware offers more parallelism, and (in conjunction with Poly1305) is faster at rejecting forged packets.
SOSEMANUK. Inspired by SNOW 2.0 and SERPENT.
Initial impression: The reported speed of SOSEMANUK relies on performing computations in F_{2^32} by secret-index table lookups, creating timing-attack problems.
Ahmadi, Eghlidos, and Khazaei report an attack on SOSEMANUK taking ``2^226 basic operations.'' Paper: [PDF]. Authors respond that SOSEMANUK never claimed more than a 128-bit security level.
NLS. Low-level operations (page 18): addition, xor, constant-distance shift, table lookups.
Initial impression: Timing-attack problems. The designers claim, incorrectly, that table lookup takes constant time.
Cho and Pieprzyk presented a paper at the SASC 2006 workshop titled ``Linear distinguishing attack on NLS.'' My impression is that the NLS authors agree with the attack, but there hasn't been a written response.
LEX. ``Leak extraction'' from AES. Specifically, extracts 40 bytes from each AES encryption; about 2.5 times faster than AES.
Initial impression: Timing-attack problems, like AES. Also looks like a great target for algebraic attacks.
Wu and Preneel write: ``If a key is used with about 2^61 random IVs, and 20,000 keystream bytes are generated from each IV, then the key could be recovered easily.'' Paper: [PDF]. Author's response is that this does not have better price-performance ratio than brute force.
Mir-1. 16-byte key, 8-byte nonce, 48-byte ``internal state size.''
Low-level operations: xor, and, or, addition mod 2^64, multiplication mod 2^64. Also uses the Rijndael S-boxes in initialization.
Tsunoo, Saito, Kubo, Shigero, and Tsujii presented a paper at the SASC 2006 workshop titled ``Cryptanalysis of Mir-1.'' No response from the authors.
MICKEY-128. 16-byte key. 16-byte nonce. Apparently too slow in software to be interesting. (Authors report approximately 1500 cycles/byte on a 3400MHz Pentium 4, and call this ``reasonably efficient.'')
Hermes8-128. 16-byte key. Apparently too slow in software to be interesting. Initial impression: Timing-attack problems.
TRBDK3 YAEA. Author says: ``It requires approximately 423 cycles per byte in operation, which is quite similar to AES based on what I have read. ... Key creation for this system is definitely slow compared to AES, taking approximately 26,000,000 cycles.''
Trivium. Seems quite fast, so I'm unhappy it hasn't been scaled up to a reasonable key size.
Khazaei and Hassanzadeh show that Trivium is immune to certain classes of attacks. Paper: [PDF].
SFINKS. SFINKS follows one of the traditional stream-cipher constructions: feeding a low-complexity LFSR (consecutive powers of a finite field element with sparse minimal polynomial, starting from a secret exponent) through a low-complexity Boolean function. There are many attacks on these constructions when the complexity is too low; SFINKS scales the complexity up far enough that none of the known attacks are faster than brute force. ``We believe that LFSR-based designs are ... a good choice for hardware applications, provided we can prove the resistance of the design to a whole set of cryptanalytic attacks,'' the authors write.
Courtois writes: ``Sfinks broken by fast algebraic attacks.'' I disagree; Courtois's attack is slower than brute force. No response from the authors.
Edon80. There has been some discussion of the Edon80 period: Hong paper [PDF], response [PDF].
MICKEY. Hong and Kim ask how much entropy is lost by the MICKEY state update. Paper: [PDF]. Hong also comments that MICKEY, like most ciphers, allows ``BSW sampling''; this doesn't change the price-performance ratio of an attack, but it means that the attacker can build a ridiculously insanely large attack machine rather than merely an insanely large attack machine.
Hermes8-80. Initial impression: Timing-attack problems.
Steve Babbage writes: ``... if we assume known plaintext ... it's clear that we can deduce the entire contents of Key Register very efficiently.''
Author writes: ``I've closed this `backdoor'... Please, have a look on the improved version.''
``Since June 13th 2005 ... ECRYPT has refused any changes to the primitives available for download,'' said the ECRYPT web site. ``It is possible that the submitter of [a broken] algorithm might be invited to try and repair their submission,'' said the eSTREAM Update 1 document. Some implementations of tweaked algorithms (such as DICING v1, which replaced DICING v0 in May 2005, and ABC v2, which replaced ABC v1 in July 2005) have been allowed into the eSTREAM benchmark suite.
I previously wrote ``I can understand the annoyance of a cryptanalyst faced with an apparently neverending series of breakable tweaks. On the other hand, ABC version 2 is very fast, so I'd like to see it remain under consideration unless and until it's broken.'' Apparently ABC version 2 has also been broken now (February 2006). eSTREAM is a limited-time project, so presumably it won't allow ABC version 3.
ABC version 1 (withdrawn). Berbain and Gilbert write: ``We present an attack against ABC ... The attack requires 2^95 operations and 2^32 32-bit keystream words.'' Paper: [PDF]. Authors write: ``We sent the ECRYPT stream cipher project committee an update. ... We would like the cryptographical community to regard the updated version of ABC as the basic one.''
Khazaei reports another attack. Paper: [PDF].
ABC version 2 (withdrawn). Key length: 16 bytes. Nonce length: 16 bytes.
Low-level operations: addition, xor, and, or, constant-distance shift, dot product. The dot product takes bits b_0,b_1,...,b_{31} and 32-bit integers e_0,e_1,...,e_{31} and computes the sum e_0 b_0 + e_1 b_1 + ... + e_{31} b_{31}. Every 4 bytes of output have one dot product and several other operations.
Initial impression: The reported speed of ABC relies on computing the dot product by secret-index table lookups, creating timing-attack problems.
Khazaei and Kiaei wrote: ``we ... mount a distinguishing attack on both versions of ABC with data, time and memory complexities of O(2^32).'' Paper: [PDF]. After the authors disputed the attack, Khazaei and Kiaei withdrew their claim and apologized.
Wu and Preneel report an (experimentally confirmed) attack that finds a key with probability 2^-32, given about 2^32 bytes of output. Paper: [PDF]. Authors write: ``We would like to thank the authors for the nice attack.''
Achterbahn version 1 (withdrawn). Johansson, Meier, and Muller write: ``We present several attacks which break the cipher faster than a brute force attack.'' Paper: [PDF]. I disagree: the attack uses 2^73 steps on a machine with 2^40 bits of memory, so it is much slower than a brute-force machine of the same size. Authors have nevertheless withdrawn Achterbahn version 1 in favor of Achterbahn version 2.
Achterbahn version 2. 10-byte key.
Hell and Johansson report an attack using 2^60 bits of keystream and a relatively small amount of processing. No response yet from the authors.
DECIM version 1 (patented) (withdrawn). 10-byte key. 8-byte nonce.
Wu and Preneel write: ``We point out two serious flaws in DECIM. ... DECIM is insecure.'' Paper: [PDF]. Gouget writes: ``H. Wu and B. Preneel showed two serious flaws in the stream cipher DECIM. The main serious flaw is in the keystream generation mechanism of DECIM. ... We will post as soon as possible the "new" version.''
DICING version 0 (withdrawn). Piret writes: ``We describe practical distinguishing and key recovery attacks ... a keystream of about 128 words ... 2^22 hash table lookups.'' Paper: [PDF].
DICING version 1. Initial impression: What advantages is DICING supposed to have over AES? The paper says ``DICING is faster than AES about two times''; in fact, even if we ignore nonce-load costs, 24 cycles/byte is slower than AES.
F-FCSR-8 (withdrawn). 16-byte key.
Jaulmes and Muller report several attacks, such as a distinguishing attack using 2^34 nonces. Paper: [PS]. Authors have withdrawn F-FCSR-8: ``These attacks pointed out three weaknesses on the algorithms. The first one is a bottleneck effect due to a big mistake in our design.''
F-FCSR-H. 10-byte key.
Grain (withdrawn). 10-byte key.
Berbain and Gilbert write: ``We have found an attack on Grain, which requires about 2^40 keystream bits and 2^44 operations to recover the secret key.'' Khazaei, Hassanzadeh, and Kiaei report another attack: [PDF]. Authors have withdrawn Grain: ``We have now specified a tweaked version by changing the output function. ... The old version ... is not to be considered.''
MAG (withdrawn). Kuenzli and Meier write: ``We present a very simple distinguishing attack ... on MAG, requiring only 129 successive bytes of known keystream, computation and memory are negligible.'' Paper: [PDF]. Author's writing is fairly incoherent but appears to admit that the attack works: ``DA shows how MAG secure stream can be differentiated from a random stream. ... From the equation no 3 it appears that the next unknown byte can be predicted with 1/2 probability.''
Mosquito (withdrawn). ``More of a research object than a standard proposal,'' Daemen said in his SKEW 2005 presentation. ``Broken,'' Daemen said in his SASC 2006 presentation.
Polar Bear (withdrawn). John Mattsson writes: ``I have found a weakness in the cipher Polar Bear. Under the assumption of a known plaintext a certain stepping and sequence of alphas opens up for a state recovery in O(2^79) time. ... The weakness has been confirmed by the algorithm's submitters.''
Hasanzadeh, Shakour, and Khazaei report ``an improved attack with computational complexity of O(2^57.4).''
POMARANCH (CJCSG) version 1 (withdrawn). Cid, Gilbert, and Johansson write: ``We show how to mount a chosen IV attack to recover the secret key of Pomaranch with complexity much lower than the one expected with 128-bit keys.'' Paper: [PDF].
Khazaei also reports an attack, exploiting the stream generation rather than the use of the nonce. Paper: [PDF].
Hasanzadeh, Khazaei, and Kholosha report an attack. Paper: [PDF]. Thanks to a profusion of confusing cipher revision names, I can't tell whether this attack also applies to POMARANCH version 2.
SSS (withdrawn). Daemen writes: ``Below a simple key-retrieval on SSS encryption requiring about 3100 bytes of chosen ciphertext and computational complexity 2^24. I did not experimentally verify whether it actually works so it may contain errors.'' Paper: [PDF].
Author writes: ``A neat attack, thanks. I confess that trying a self-synchronous stream cipher was a departure from anything that we really knew how to do...''
TSC-3 (withdrawn). Muller writes: ``We just posted a paper that describes distinguishing and key recovery attacks against TSC-3. The distinguishing attack costs 2^42 time and data. The key recovery attack costs 2^66 time and 2^34 data.'' Paper: [PS]. Author writes: ``I have quickly read through the paper and believe the attacks to be valid.''
WG version 1 (withdrawn). Wu and Preneel report various attacks on WG version 1. Paper: [PDF]. Authors write: ``We admit that 22 clock cycles for key/IV setup phased as suggested by us in the original WG paper was too optimistic. ... We therefore recommend the key/IV setup phase of the WG cipher to be 88 clock cycles. No design changes are required.''
WG version 2. Authors report insanely slow software speeds.
ZK-Crypt version 1 (patented) (withdrawn). Lubkin and Ryabko appear to state that ZK-Crypt output is compressible by a standard move-to-front-plus-Huffman algorithm applied to 4-byte words. Paper: [PDF].
Turan, Doganaksoy, and Calik state (in a SASC 2006 paper) that ZK-Crypt output flunks a simple IV-diffusion test. Saarinen independently states (in another SASC 2006 paper) that ZK-Crypt output flunks another IV test.
At SASC 2006, the ZK-Crypt authors questioned the Lubkin-Ryabko result but did not dispute the other results. In the documentation for ZK-Crypt version 2, the ZK-Crypt authors again questioned the Lubkin-Ryabko result. I wrote a paper confirming and simplifying the Lubkin-Ryabko result:
ZK-Crypt version 2. Claims good hardware performance.
Matthew Dempsky writes: ``Why would anyone choose to license a cipher they can't efficiently implement instead of use one like AES?''
``Cryptowatch'' writes: ``If we determined to ignore the value and potential in patented ECRYPT submissions then we would be certainly placing ourselves at odds with practically every other area of scientific endeavour.''
``Ruptor'' writes: ``I also see no reason to discard such ciphers as VEST or Frogbit or any other patented cipher until and unless they are broken ... Why don't people use free stuff? Probably because you always get what you pay for?''
``Matt Crypto'' writes: ``I think a pay-to-use patented stream cipher would have to be significantly better than the opposition to justify being chosen over unpatented/freely-useable alternatives.''
Most of the unpatented submissions, like most of the patented ones, seem to be withstanding cryptanalysis. I don't think a patented submission will attract serious interest unless it offers truly outstanding performance.
Rabbit (patented). Low-level operations: addition; addition with carry; squaring of a 4-byte input, with the 8-byte output folded by xor into a 4-byte result; rotation by multiples of 8 bits; and some other byte shuffling as part of key setup.
Each 16-byte output block involves 8 squarings and various other operations.
Initial impression: The multiplier means large price-performance ratio for hardware, but Rabbit's software speed is quite attractive. From a timing-attack perspective, I'm concerned about Rabbit's use of integer squaring on, e.g., the Motorola PowerPC G4e 7450, which takes a cycle less if the input is between -131072 and 131071. How much speed does Rabbit lose if this timing leak is eliminated?
Frogbit (patented) (unsafe). Turan, Doganaksoy, and Calik state (in a SASC 2006 paper) that Frogbit output flunks a simple IV-diffusion test. Saarinen independently states (in another SASC 2006 paper) that Frogbit output flunks another IV test.
Even if this cipher were safe, I would have no idea what's supposed to be interesting about it.
Fubuki (patented). Initial impression: So slow that nobody will look at it. What advantages is Fubuki supposed to have over AES?
CryptMT (patented). Same paper as Fubuki but considerably faster.
Khazaei and Shakour write: ``The LSB's ... of every two conseuctive output bytes are equal with probability (1/2)(1+2^(-24)).'' Paper: [PDF]. Authors respond: ``This seems mathematically wrong.'' Khazaei and Shakour write: ``We confess that we made a terrible blunder.''
VEST (patented). According to the paper, VEST-32 returns ``32 bits of output per clock cycle'' using about 20000 gates. Loading a 64-bit IV ``takes 40 rounds,'' which I guess means 40 clock cycles. Expanding a key takes 320 clock cycles; an expanded key occupies 768 bits.
This hardware performance seems considerably worse than, e.g., Salsa20.