cr.yp.to update
[email protected] 6 Sep 2005 06:15:34 -0000
| Newsgroups | gmane.comp.djb.announce |
|---|---|
| Message-ID | <[email protected]> |
hash.html | 2
streamciphers.html | 354 ++++++++++++++++++++++++++++++-----------------------
2 files changed, 205 insertions(+), 151 deletions(-)
diff -ru .old-crypto/hash.html cr.yp.to/hash.html
--- .old-crypto/hash.html 2005-05-05 21:53:45.000000000 -0400
+++ cr.yp.to/hash.html 2005-09-02 13:01:49.000000000 -0400
@@ -7,7 +7,7 @@
<p>
<a href="salsa20.html">The Salsa20 hash function</a>
<p>
-<a href="streamciphers.html">Notes on the ECRYPT Stream Cipher project</a>
+<a href="streamciphers.html">Notes on the ECRYPT Stream Cipher project (eSTREAM)</a>
<h2>Older designs</h2>
These aren't as fast as Salsa20
for the same conjectured security level.
New: snuffle/anping-disproof.pdf
diff -ru .old-crypto/streamciphers.html cr.yp.to/streamciphers.html
--- .old-crypto/streamciphers.html 2005-08-05 19:28:37.000000000 -0400
+++ cr.yp.to/streamciphers.html 2005-09-05 18:13:51.000000000 -0400
@@ -1,11 +1,11 @@
<html>
<head>
-<title>Notes on the ECRYPT Stream Cipher project</title>
+<title>Notes on the ECRYPT Stream Cipher project (eSTREAM)</title>
</head>
<body>
<a href="djb.html">D. J. Bernstein</a>
<br><a href="hash.html">Hash functions and ciphers</a>
-<h1>Notes on the ECRYPT Stream Cipher project</h1>
+<h1>Notes on the ECRYPT Stream Cipher project (eSTREAM)</h1>
<a href="streamciphers/20050614-abbreviations.txt">Abbreviating the stream-cipher discussions</a>
<hr>
ECRYPT
@@ -30,27 +30,27 @@
<tr><th>Name</th><th>Key size</th><th>Authors; policy</th><th>Documents</th></tr>
<tr><td>ABC version 1 <b>withdrawn</b></td><td>16 bytes</td><td>Vladimir Anashin, Andrey Bogdanov, Ilya Kizhvatov, Sandeep Kumar</td><td><a href="streamciphers/abc/abc.c">C</a> <a href="streamciphers/abc/desc.pdf">paper</a></td></tr>
<tr><td>ABC version 2</td><td>16 bytes</td><td>Vladimir Anashin, Andrey Bogdanov, Ilya Kizhvatov, Sandeep Kumar</td><td></td></tr>
-<tr><td>Achterbahn</td><td>10 bytes</td><td>Berndt Gammel, Rainer Goettfert, Oliver Kniffler</td><td><a href="streamciphers/achterbahn/desc.pdf">paper</a></td></tr>
-<tr><td>DECIM</td><td>10 bytes</td><td>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; <b>patented</b></td><td><a href="streamciphers/decim/desc.pdf">paper</a></td></tr>
+<tr><td>Achterbahn</td><td><b>10 bytes</b></td><td>Berndt Gammel, Rainer Goettfert, Oliver Kniffler</td><td><a href="streamciphers/achterbahn/desc.pdf">paper</a></td></tr>
+<tr><td>DECIM version 1 <b>withdrawn</b></td><td><b>10 bytes</b></td><td>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; <b>patented</b></td><td><a href="streamciphers/decim/desc.pdf">paper</a></td></tr>
<tr><td>DICING version 0 <b>withdrawn</b></td><td>16 bytes</td><td>Li An-Ping</td><td><a href="streamciphers/dicing/desc0.pdf">paper</a></td></tr>
<tr><td>DICING version 1</td><td>16 bytes</td><td>Li An-Ping</td><td><a href="streamciphers/dicing/desc2.pdf">paper</a></td></tr>
<tr><td>Dragon-128</td><td>16 bytes</td><td>Ed Dawson, Kevin Chen, Matt Henricksen, William Millan, Leonie Simpson, HoonJae Lee, SangJae Moon</td><td><a href="streamciphers/dragon-128/dragon-ref.c">C</a> <a href="streamciphers/dragon-128/desc.pdf">paper</a></td></tr>
<tr><td>Dragon-256</td><td>32 bytes</td><td>Ed Dawson, Kevin Chen, Matt Henricksen, William Millan, Leonie Simpson, HoonJae Lee, SangJae Moon</td><td><a href="streamciphers/dragon-128/dragon-ref.c">C</a> <a href="streamciphers/dragon-128/desc.pdf">paper</a></td></tr>
-<tr><td>Edon80</td><td>10 bytes</td><td>Danilo Gligoroski, Smile Markovski, Ljupco Kocarev, Marjan Gusev</td><td><a href="streamciphers/edon80/PartB1.pdf">desc</a> <a href="streamciphers/edon80/PartB2.pdf">robustness</a> <a href="streamciphers/edon80/PartB3.pdf">security</a> <a href="streamciphers/edon80/PartB4.pdf">advantages</a> <a href="streamciphers/edon80/PartB5.pdf">design</a> <a href="streamciphers/edon80/PartB6.pdf">speed</a> <a href="streamciphers/edon80/PartB7.pdf">impl</a></td></tr>
-<tr><td>F-FCSR-H</td><td>10 bytes</td><td>Thierry Berger, Francois Arnault, Cedric Lauradoux</td><td><a href="streamciphers/f-fcsr-8/B_SPECIF.PDF">paper</a></td></tr>
+<tr><td>Edon80</td><td><b>10 bytes</b></td><td>Danilo Gligoroski, Smile Markovski, Ljupco Kocarev, Marjan Gusev</td><td><a href="streamciphers/edon80/PartB1.pdf">desc</a> <a href="streamciphers/edon80/PartB2.pdf">robustness</a> <a href="streamciphers/edon80/PartB3.pdf">security</a> <a href="streamciphers/edon80/PartB4.pdf">advantages</a> <a href="streamciphers/edon80/PartB5.pdf">design</a> <a href="streamciphers/edon80/PartB6.pdf">speed</a> <a href="streamciphers/edon80/PartB7.pdf">impl</a></td></tr>
+<tr><td>F-FCSR-H</td><td><b>10 bytes</b></td><td>Thierry Berger, Francois Arnault, Cedric Lauradoux</td><td><a href="streamciphers/f-fcsr-8/B_SPECIF.PDF">paper</a></td></tr>
<tr><td>F-FCSR-8</td><td>16 bytes</td><td>Thierry Berger, Francois Arnault, Cedric Lauradoux</td><td><a href="streamciphers/f-fcsr-8/B_SPECIF.PDF">paper</a></td></tr>
<tr><td>Frogbit</td><td>16 bytes</td><td>Thierry Moreau; <b>patented</b></td><td><a href="streamciphers/frogbit/frogbit.pdf">paper</a></td></tr>
<tr><td>Fubuki</td><td>16? bytes</td><td>Makoto Matsumoto, Hagita Mariko, Takuji Nishimura, Matsuo Saito; <b>patented</b></td><td><a href="streamciphers/fubuki/desc.pdf">paper</a></td></tr>
-<tr><td>Grain</td><td>10 bytes</td><td>Martin Hell, Thomas Johansson, Willi Meier</td><td><a href="streamciphers/grain/desc.pdf">paper</a>; subsequent corrections</td></tr>
+<tr><td>Grain</td><td><b>10 bytes</b></td><td>Martin Hell, Thomas Johansson, Willi Meier</td><td><a href="streamciphers/grain/desc.pdf">paper</a>; subsequent corrections</td></tr>
<tr><td>HC-256</td><td>32 bytes</td><td>Hongjun Wu; ``HC-256 is not covered by any patent and it is freely available''</td><td><a href="streamciphers/hc-256/desc.pdf">paper</a></td></tr>
-<tr><td>Hermes8-80</td><td>10 bytes</td><td>Ulrich Kaiser</td><td><a href="streamciphers/hermes8-128/desc.pdf">paper</a></td></tr>
+<tr><td>Hermes8-80</td><td><b>10 bytes</b></td><td>Ulrich Kaiser</td><td><a href="streamciphers/hermes8-128/desc.pdf">paper</a></td></tr>
<tr><td>Hermes8-128</td><td>16 bytes</td><td>Ulrich Kaiser</td><td><a href="streamciphers/hermes8-128/desc.pdf">paper</a></td></tr>
<tr><td>LEX</td><td>16 bytes</td><td>Alex Biryukov</td><td><a href="streamciphers/lex/desc.pdf">paper</a></td></tr>
<tr><td>MAG</td><td></td><td>Rade Vuckovac</td><td><a href="streamciphers/mag/desc.pdf">paper</a></td></tr>
-<tr><td>MICKEY</td><td>10 bytes</td><td>Steve Babbage, Matthew Dodd</td><td><a href="streamciphers/mickey/desc.pdf">paper</a></td></tr>
+<tr><td>MICKEY</td><td><b>10 bytes</b></td><td>Steve Babbage, Matthew Dodd</td><td><a href="streamciphers/mickey/desc.pdf">paper</a></td></tr>
<tr><td>MICKEY-128</td><td>16 bytes</td><td>Steve Babbage, Matthew Dodd</td><td><a href="streamciphers/mickey/desc.pdf">paper</a></td></tr>
<tr><td>Mir-1</td><td>16 bytes</td><td>Alexander Maximov</td><td><a href="streamciphers/mir-1/desc.pdf">paper</a>; subsequent asm</td></tr>
-<tr><td>Mosquito</td><td>12 bytes</td><td>Joan Daemen, Paris Kitsos</td><td><a href="streamciphers/mosquito/desc.pdf">paper</a>; subsequent corrections</td></tr>
+<tr><td>Mosquito</td><td><b>12 bytes</b></td><td>Joan Daemen, Paris Kitsos</td><td><a href="streamciphers/mosquito/desc.pdf">paper</a>; subsequent corrections</td></tr>
<tr><td>Non-Linear SOBER (NLS)</td><td>16 bytes</td><td>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''</td><td><a href="streamciphers/nls/nlsref.c">C</a> <a href="streamciphers/nls/desc.pdf">paper</a> <a href="http://people.qualcomm.com/ggr/NLS-SSS.html">link</a></td></tr>
<tr><td>Phelix</td><td>32 bytes</td><td>Doug Whiting, Bruce Schneier, Stephan Lucks, Frederic Muller; ``We hereby explicitly release any intellectual property rights to Phelix into the public domain''</td><td><a href="streamciphers/phelix/phelix.c">C</a> <a href="streamciphers/phelix/desc.pdf">paper</a> <a href="http://www.schneier.com/paper-phelix.html">link</a></td></tr>
<tr><td>Polar Bear</td><td>16? bytes</td><td>Johan Haastad, Mats Naeslund</td><td><a href="streamciphers/polar-bear/desc.pdf">paper</a></td></tr>
@@ -60,13 +60,13 @@
<tr><td>Rabbit</td><td>16 bytes</td><td>Martin Boesgaard, Mette Vesterager, Thomas Christensen, Erik Zenner; <b>patented</b></td><td><a href="streamciphers/rabbit/rabbit.c">C</a> <a href="streamciphers/rabbit/desc.pdf">paper</a> <a href="http://www.cryptico.com/Default.asp?ID=10">link</a></td>
<tr><td>Salsa20 (Snuffle 2005)</td><td>32 bytes</td><td>Daniel J. Bernstein; ``My policy is that Salsa20 is free for everyone to use''</td><td><a href="snuffle/ecrypt.c">C</a> <a href="snuffle/spec.pdf">spec</a> <a href="snuffle/security.pdf">security</a> <a href="snuffle/design.pdf">design</a> <a href="snuffle/speed.pdf">speed</a> <a href="snuffle/robustness.pdf">robustness</a> <a href="snuffle/ip.pdf">IP</a> <a href="snuffle.html">link</a></td></tr>
<tr><td>Self-Synchronous SOBER (SSS) <b>withdrawn</b></td><td>16 bytes</td><td>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''</td><td><a href="streamciphers/sss/desc.pdf">paper</a> <a href="http://people.qualcomm.com/ggr/NLS-SSS.html">link</a></td></tr>
-<tr><td>SFINKS</td><td>10 bytes</td><td>An Braeken, Joseph Lano, Nele Mentens, Bart Preneel, Ingrid Verbauwhede</td><td><a href="streamciphers/sfinks/desc.pdf">paper</a></td></tr>
+<tr><td>SFINKS</td><td><b>10 bytes</b></td><td>An Braeken, Joseph Lano, Nele Mentens, Bart Preneel, Ingrid Verbauwhede</td><td><a href="streamciphers/sfinks/desc.pdf">paper</a></td></tr>
<tr><td>SOSEMANUK</td><td>32 bytes</td><td>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''</td><td><a href="streamciphers/sosemanuk/SOSEMANUK.C">C</a> <a href="streamciphers/sosemanuk/desc.pdf">paper</a></td></tr>
<tr><td>TRBDK3 YAEA</td><td></td><td>Timothy Brigham</td><td><a href="streamciphers/trbdk3-yaea/desc.ps">paper</a></td></tr>
-<tr><td>Trivium</td><td>10 bytes</td><td>Christophe De Canniere, Bart Preneel</td><td><a href="streamciphers/trivium/desc.pdf">paper</a></td></tr>
-<tr><td>TSC-3 <b>withdrawn</b></td><td>10 bytes</td><td>Jin Hong, Dong Hoon Lee, Yongjin Yeom, Daewan Han, Seongtaek Chee</td><td><a href="streamciphers/tsc-3/desc.pdf">paper</a></td></tr>
-<tr><td>VEST-4</td><td>10 bytes</td><td>Claude Bigeard, Sean O'Neil, Benjamin Gittins, Howard Landman; <b>patented</b></td><td><a href="streamciphers/vest-16/desc.pdf">paper</a></td></tr>
-<tr><td>VEST-16</td><td>16 bytes</td><td>Claude Bigeard, Sean O'Neil, Benjamin Gittins, Howard Landman; <b>patented</b></td><td><a href="streamciphers/vest-16/desc.pdf">paper</a></td></tr>
+<tr><td>Trivium</td><td><b>10 bytes</b></td><td>Christophe De Canniere, Bart Preneel</td><td><a href="streamciphers/trivium/desc.pdf">paper</a></td></tr>
+<tr><td>TSC-3 <b>withdrawn</b></td><td><b>10 bytes</b></td><td>Jin Hong, Dong Hoon Lee, Yongjin Yeom, Daewan Han, Seongtaek Chee</td><td><a href="streamciphers/tsc-3/desc.pdf">paper</a></td></tr>
+<tr><td>VEST-4</td><td><b>10 bytes</b></td><td>Claude Bigeard, Sean O'Neil, Benjamin Gittins, Howard Landman; <b>patented</b></td><td><a href="streamciphers/vest-16/desc.pdf">paper</a></td></tr>
+<tr><td>VEST-16</td><td>20 bytes</td><td>Claude Bigeard, Sean O'Neil, Benjamin Gittins, Howard Landman; <b>patented</b></td><td><a href="streamciphers/vest-16/desc.pdf">paper</a></td></tr>
<tr><td>VEST-32</td><td>32 bytes</td><td>Claude Bigeard, Sean O'Neil, Benjamin Gittins, Howard Landman; <b>patented</b></td><td><a href="streamciphers/vest-16/desc.pdf">paper</a></td></tr>
<tr><td>WG version 1 <b>withdrawn</b></td><td>16 bytes</td><td>Guang Gong, Yassir Nawaz</td><td><a href="streamciphers/wg/desc.pdf">paper</a>; subsequent corrections</td></tr>
<tr><td>WG version 2</td><td>16 bytes</td><td>Guang Gong, Yassir Nawaz</td><td></td></tr>
@@ -127,12 +127,47 @@
Among the stream-cipher submissions,
Frogbit, NLS, Phelix, SFINKS, SSS, and VEST
are labelled as incorporating authentication mechanisms.
-My impression is that both NLS and SFINKS are actually
+My impression is that NLS, SFINKS, and VEST are actually
pure-encryption stream ciphers attached to separate authenticators;
in both 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.
+<h2>Notes on patented submissions</h2>
+DECIM, Frogbit, Fubuki, Rabbit, VEST, and ZK-Crypt
+are patented.
+<p>
+Jin Hong writes:
+``As for patent issues,
+I personaly would not vote for a cipher that intends to use patent rights
+for money unless it is truely an extrodinary work.''
+<p>
+Matthew Dempsky writes:
+``Why would anyone choose to license a cipher
+they can't efficiently implement instead of use one like AES?''
+<p>
+``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.''
+<p>
+``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?''
+<p>
+``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.''
+<p>
+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.
<hr>
<h2>Notes on Salsa20</h2>
My own submission.
@@ -170,60 +205,6 @@
Exceptions:
Salsa20 is faster than Phelix when the hardware offers more parallelism,
and (in conjunction with Poly1305) is faster at rejecting forged packets.
-<h2>Notes on Rabbit (patented)</h2>
-Authors report, for a Pentium III-1000,
-278 cycles to load a 16-byte key;
-plus 253 cycles to load a nonce;
-plus 3.7 cycles/byte to encrypt a big block.
-For a Pentium 4,
-468 cycles to load a 16-byte key;
-plus 420 cycles to load a nonce;
-plus 5.1 cycles/byte to encrypt a big block.
-Also speed reports for ARM7 and MIPS.
-<p>
-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.
-<p>
-Each 16-byte output block involves 8 squarings and various other operations.
-<p>
-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 7450 (G4e),
-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?
-<h2>Notes on ABC version 1 (withdrawn)</h2>
-Berbain and Gilbert write:
-``We present an attack against ABC ... The attack requires
-2^95 operations and 2^32 32-bit keystream words.''
-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.''
-<h2>Notes on ABC version 2</h2>
-Key length: 16 bytes.
-Nonce length: 16 bytes.
-Authors report Pentium 4 speeds
-under 4 cycles per byte.
-<p>
-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.
-<p>
-Initial impression:
-The reported speed of ABC relies on computing the dot product
-by secret-index table lookups,
-creating timing-attack problems.
<h2>Notes on SOSEMANUK</h2>
Key length between 16 bytes and 32 bytes.
Nonce length: 16 bytes.
@@ -299,6 +280,7 @@
``There is a distinguishing attack on Yamb.
It requires about $2^{58}$ outputs
and about $2^{55}$ simple operations (32-bit addition or subtraction).''
+No response from the authors.
<h2>Notes on Py</h2>
Authors report, for a Pentium III,
2727 cycles to load a key;
@@ -332,27 +314,6 @@
Initial impression:
Timing-attack problems, like RC4.
<hr>
-<h2>Notes on DICING version 0 (withdrawn)</h2>
-Author reports, for an 1800MHz Athlon XP,
-918 cycles to load a 16-byte key;
-plus 57600 cycles to load a nonce;
-plus 24 cycles/byte to encrypt a big block.
-<p>
-Gilles Piret writes:
-``We describe practical distinguishing and key recovery
-attacks ... a keystream of about 128 words ...
-2^22 hash table lookups.''
-<h2>Notes on DICING version 1</h2>
-Author reports, for an 1800MHz Athlon XP,
-918 cycles to load a 16-byte key;
-plus 57600 cycles to load a nonce;
-plus 24 cycles/byte to encrypt a big block.
-<p>
-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.
<h2>Notes on Mir-1</h2>
16-byte key,
8-byte nonce,
@@ -386,14 +347,6 @@
The cycles-per-byte count isn't even on the same scale as RC4;
the authors are wildly misrepresenting RC4 speed.
What advantages is Polar Bear supposed to have over AES?
-<h2>Notes on Fubuki (patented)</h2>
-Authors report, for a Pentium M,
-489662 cycles for setup,
-plus 133 cycles/byte to encrypt a big block.
-Uses Mersenne Twister, by Matsumoto and Nishimura.
-<p>
-Initial impression: So slow that nobody will look at it.
-What advantages is Fubuki supposed to have over AES?
<h2>Notes on F-FCSR-8</h2>
16-byte key.
Authors report,
@@ -405,24 +358,12 @@
<p>
Jaulmes and Muller report several attacks,
such as a distinguishing attack using 2^34 nonces.
+No response from the authors.
<h2>Notes on F-FCSR-H</h2>
10-byte key.
<h2>Notes on Mosquito</h2>
``More of a research object than a standard proposal,''
Daemen said in his SKEW presentation.
-<h2>Notes on TSC-3 (withdrawn)</h2>
-10-byte key.
-Authors report, for a Pentium 4,
-1500 cycles to load a key and nonce,
-plus 50 cycles/byte to encrypt a big block.
-<p>
-Frederic 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.''
-Author writes:
-``I have quickly read through the paper and believe the attacks to be valid.''
<h2>Notes on Achterbahn</h2>
10-byte key.
Authors don't report software speeds.
@@ -432,16 +373,7 @@
<p>
Courtois writes: ``Sfinks broken by fast algebraic attacks.''
I disagree; Courtois's attack is slower than brute force.
-<h2>Notes on WG version 1 (withdrawn)</h2>
-Hongjun Wu and Bart Preneel report various attacks on WG version 1.
-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.''
-<h2>Notes on WG version 2</h2>
-Authors report insanely slow software speeds.
+No response from the authors.
<h2>Notes on Edon80</h2>
10-byte key.
10-byte nonce.
@@ -451,26 +383,23 @@
16-byte key.
14-byte nonce.
Authors report approximately 1400 cycles/byte on a 2800MHz Pentium 4.
-<h2>Notes on DECIM (patented)</h2>
-10-byte key.
-8-byte nonce.
-<p>
-Hongjun Wu and Bart Preneel write:
-``We point out two serious flaws in DECIM. ... DECIM is insecure.''
<h2>Notes on MICKEY</h2>
10-byte key.
10-byte nonce.
Authors report approximately 1400 cycles/byte on a 3400MHz Pentium 4,
and call this ``reasonably efficient.''
<p>
-Jin Hong asks how much entropy is lost by the MICKEY state update.
+Hong asks how much entropy is lost by the MICKEY state update.
+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.
<h2>Notes on MICKEY-128</h2>
16-byte key.
16-byte nonce.
Authors report approximately 1500 cycles/byte on a 3400MHz Pentium 4,
and call this ``reasonably efficient.''
-<h2>Notes on Frogbit (patented)</h2>
-No speed reports.
<h2>Notes on Grain</h2>
10-byte key.
No software speed reports.
@@ -491,25 +420,6 @@
<p>
Initial impression:
Timing-attack problems.
-<h2>Notes on SSS (withdrawn)</h2>
-Joan 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.''
-<p>
-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...''
-<h2>Notes on VEST-4 (patented)</h2>
-10-byte key.
-No software speed reports.
-<h2>Notes on VEST-16 (patented)</h2>
-16-byte key.
-No software speed reports.
-<h2>Notes on VEST-32 (patented)</h2>
-32-byte key.
-No software speed reports.
<h2>Notes on TRBDK3 YAEA</h2>
Author says:
``It requires approximately 423 cycles per byte in operation,
@@ -525,7 +435,151 @@
``We present a very simple distinguishing attack ... on MAG,
requiring only 129 successive bytes of known keystream,
computation and memory are negligible.''
+No response from the author.
+<hr>
+<h2>Notes on Rabbit (patented)</h2>
+Authors report, for a Pentium III-1000,
+278 cycles to load a 16-byte key;
+plus 253 cycles to load a nonce;
+plus 3.7 cycles/byte to encrypt a big block.
+For a Pentium 4,
+468 cycles to load a 16-byte key;
+plus 420 cycles to load a nonce;
+plus 5.1 cycles/byte to encrypt a big block.
+Also speed reports for ARM7 and MIPS.
+<p>
+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.
+<p>
+Each 16-byte output block involves 8 squarings and various other operations.
+<p>
+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 7450 (G4e),
+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?
+<h2>Notes on Frogbit (patented)</h2>
+No speed reports.
+<h2>Notes on Fubuki (patented)</h2>
+Authors report, for a Pentium M,
+489662 cycles for setup,
+plus 133 cycles/byte to encrypt a big block.
+Uses Mersenne Twister, by Matsumoto and Nishimura.
+<p>
+Initial impression: So slow that nobody will look at it.
+What advantages is Fubuki supposed to have over AES?
+<h2>Notes on VEST-4 (patented)</h2>
+10-byte key.
+No software speed reports.
+<h2>Notes on VEST-16 (patented)</h2>
+20-byte key.
+No software speed reports.
+<h2>Notes on VEST-32 (patented)</h2>
+32-byte key.
+No software speed reports.
<h2>Notes on ZK-Crypt (patented)</h2>
No software speed reports.
+<hr>
+<h2>Notes on ABC version 1 (withdrawn)</h2>
+Berbain and Gilbert write:
+``We present an attack against ABC ... The attack requires
+2^95 operations and 2^32 32-bit keystream words.''
+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.''
+<h2>Notes on ABC version 2</h2>
+Key length: 16 bytes.
+Nonce length: 16 bytes.
+Authors report Pentium 4 speeds
+under 4 cycles per byte.
+<p>
+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.
+<p>
+Initial impression:
+The reported speed of ABC relies on computing the dot product
+by secret-index table lookups,
+creating timing-attack problems.
+<p>
+Khazaei writes: ``... a distinguishing attack
+with data, time and memory complexities of O(2^32) could be applied.''
+No response from the authors.
+<h2>Notes on DECIM version 1 (patented) (withdrawn)</h2>
+10-byte key.
+8-byte nonce.
+<p>
+Hongjun Wu and Bart Preneel write:
+``We point out two serious flaws in DECIM. ... DECIM is insecure.''
+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.''
+<h2>Notes on DICING version 0 (withdrawn)</h2>
+Author reports, for an 1800MHz Athlon XP,
+918 cycles to load a 16-byte key;
+plus 57600 cycles to load a nonce;
+plus 24 cycles/byte to encrypt a big block.
+<p>
+Gilles Piret writes:
+``We describe practical distinguishing and key recovery
+attacks ... a keystream of about 128 words ...
+2^22 hash table lookups.''
+<h2>Notes on DICING version 1</h2>
+Author reports, for an 1800MHz Athlon XP,
+918 cycles to load a 16-byte key;
+plus 57600 cycles to load a nonce;
+plus 24 cycles/byte to encrypt a big block.
+<p>
+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.
+<h2>Notes on SSS (withdrawn)</h2>
+Joan 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.''
+<p>
+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...''
+<h2>Notes on TSC-3 (withdrawn)</h2>
+10-byte key.
+Authors report, for a Pentium 4,
+1500 cycles to load a key and nonce,
+plus 50 cycles/byte to encrypt a big block.
+<p>
+Frederic 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.''
+Author writes:
+``I have quickly read through the paper and believe the attacks to be valid.''
+<h2>Notes on WG version 1 (withdrawn)</h2>
+Hongjun Wu and Bart Preneel report various attacks on WG version 1.
+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.''
+<h2>Notes on WG version 2</h2>
+Authors report insanely slow software speeds.
</body>
</html>