cr.yp.to update
[email protected] 9 Sep 2005 06:17:43 -0000
| Newsgroups | gmane.comp.djb.announce |
|---|---|
| Message-ID | <[email protected]> |
snuffle.html | 64 +++++++++++++++++++++++++++++++++--------------------
streamciphers.html | 5 ++--
2 files changed, 44 insertions(+), 25 deletions(-)
diff -ru .old-crypto/snuffle.html cr.yp.to/snuffle.html
--- .old-crypto/snuffle.html 2005-08-27 23:46:58.000000000 -0400
+++ cr.yp.to/snuffle.html 2005-09-06 04:52:50.000000000 -0400
@@ -12,30 +12,9 @@
uses the
<a href="salsa20.html">Salsa20 hash function</a>
to encrypt data.
-<p>
-At the end of 2005
-I will award a $1000 prize
-for the public Salsa20 cryptanalysis
-that I consider most interesting.
-Cryptanalysts are encouraged to
-measure their attacks by carefully measuring the price and performance
-of the attacks against
-<ol>
-<li>Salsa20 reduced to 2 rounds,
-<li>Salsa20 reduced to 4 rounds,
-<li>Salsa20 reduced to 6 rounds,
-</ol>
-etc.;
-and, furthermore, to verify these measurements
-using computer experiments with various reduced word sizes.
-It's easy to break some initial rounds of Salsa20,
-but the difficulty grows with the number of rounds,
-so I'd guess (although I don't promise)
-that the most interesting attack will be the attack
-that breaks the largest number of rounds.
-<p>
+<h2>Salsa20 documentation</h2>
I've submitted Salsa20 to the
-<a href="streamciphers.html">ECRYPT Stream Cipher project</a>.
+<a href="streamciphers.html">ECRYPT Stream Cipher project (eSTREAM)</a>.
This submission consists of
four formalities,
four core documents,
@@ -113,5 +92,44 @@
It discusses the tremendous power
of a parallel brute-force key-search machine,
and corrects several related errors in the literature.
+<h2>Salsa20 prizes</h2>
+At the end of 2005
+I will award a $1000 prize
+for the public Salsa20 cryptanalysis
+that I consider most interesting.
+Cryptanalysts are strongly encouraged
+<ul>
+<li>to generalize their attacks
+from 32-bit words to w-bit words for every w in {2,4,6,8,...,32};
+<li>to generalize their attacks
+from 20 rounds to r rounds for every r in {2,4,6,8,...,20};
+<li>to state the success probability of the attack
+for all pairs (w,r);
+<li>to state the time taken by the attack
+for all pairs (w,r);
+<li>to state the price of the attack machine (memory, etc.)
+for all pairs (w,r); and
+<li>to publish software verifying these statements
+for as many pairs (w,r) as possible.
+</ul>
+Every attack should be fast when w and r are small;
+and there is no excuse
+for failing to have a computer verify that a fast attack works.
+The importance of computer verification
+is illustrated by my paper
+``<a href="snuffle/anping-disproof.pdf">Disproof of Li An-Ping's
+claims regarding Salsa20</a>.''
+<p>
+I won't make any promises regarding what I'll find interesting,
+but experience suggests the following guidelines:
+<ul>
+<li>Breaking larger r's wins bonus points.
+``Breaking'' is defined by being faster than brute force
+<i>for the same cost of cryptanalytic hardware</i>.
+<li>Extra speed wins bonus points.
+<li>Early publication wins bonus points.
+Don't hold back!
+<li>New ideas win bonus points.
+</ul>
</body>
</html>
diff -ru .old-crypto/streamciphers.html cr.yp.to/streamciphers.html
--- .old-crypto/streamciphers.html 2005-09-05 18:13:51.000000000 -0400
+++ cr.yp.to/streamciphers.html 2005-09-06 03:17:52.000000000 -0400
@@ -129,7 +129,8 @@
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 both cases, the separate authenticators are slower than (e.g.) Poly1305,
+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.
@@ -523,7 +524,7 @@
<p>
Hongjun Wu and Bart Preneel write:
``We point out two serious flaws in DECIM. ... DECIM is insecure.''
-Gouget writes:
+Aline 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.''