cr.yp.to update

diff -ru .old-crypto/qmail/guarantee.html cr.yp.to/qmail/guarantee.html
--- .old-crypto/qmail/guarantee.html	2001-02-02 13:57:23.000000000 -0500
+++ cr.yp.to/qmail/guarantee.html	2005-05-29 05:11:27.000000000 -0400
@@ -33,6 +33,15 @@
 A group of qmail users offered a $1000 prize for one year under similar rules.
 The prize was not claimed;
 the money was donated to the Free Software Foundation.
+<p>
+In May 2005,
+Georgi Guninski
+claimed that some potential 64-bit portability problems
+allowed a ``remote exploit in qmail-smtpd.''
+This claim is denied.
+Nobody gives gigabytes of memory to each qmail-smtpd process,
+so there is no problem with qmail's assumption
+that allocated array lengths fit comfortably into 32 bits.
 <h2>Why is qmail secure?</h2>
 The reason I started the qmail project was that
 I was sick of the security holes in sendmail and other MTAs.
diff -ru .old-crypto/streamciphers.html cr.yp.to/streamciphers.html
--- .old-crypto/streamciphers.html	2005-05-28 06:11:23.000000000 -0400
+++ cr.yp.to/streamciphers.html	2005-05-28 12:23:37.000000000 -0400
@@ -97,6 +97,13 @@
 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 impressions:
+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 Phelix</h2>
 Authors report,
 for a Pentium M,
@@ -120,10 +127,20 @@
 Each Phelix block feeds the input through
 13 adds, 11 xors, and 20 rotations
 to produce a 4-byte block of output.
-Overall 11 operations per byte.
+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,
+For comparison, Salsa20 performs 15 operations per byte
+(5 adds, 5 xors, 5 rotations),
 plus final xoring, plus the cost of authentication.
+<p>
+Initial impressions:
+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.
 <h2>Notes on SOSEMANUK</h2>
 Key length between 16 bytes and 32 bytes.
 Nonce length: 16 bytes.
@@ -158,7 +175,12 @@
 11149 cycles to load a key;
 693 cycles to load a nonce;
 314 cycles per block (39.25 cycles/byte, I believe) to encrypt a big block.
-I think that the same function could be computed at considerably higher speed.
+<p>
+Initial impressions:
+This function sounds awfully slow,
+so it won't attract much interest.
+On the other hand,
+I think it could be computed at considerably higher speed.
 <h2>Notes on Py</h2>
 Authors report, for a Pentium III,
 2727 cycles to load a key;
@@ -173,8 +195,8 @@
 5003 cycles to load a nonce;
 4.1 cycles/byte to encrypt a big block.
 <p>
-The secret indices bother me:
-surely Py is vulnerable to timing attacks.
+Initial impression:
+Py looks like a disaster from a timing-attack perspective.
 The large message-setup time also bothers me:
 low-overhead ciphers such as Salsa20
 will already have finished encrypting an average-size Internet packet
@@ -187,10 +209,13 @@
 <p>
 The paper's speed results are about 58 cycles per byte
 on a 1400MHz Pentium 4, plus about 800 cycles for setup.
-In what fantasy world is this even remotely comparable to RC4 speed?
 <p>
-Low-level operations: kitchen sink.
-Many opportunities for timing attacks.
+Initial impression:
+The cycles-per-byte count isn't even on the same scale as RC4;
+the authors are wildly misrepresenting RC4 speed.
+Furthermore,
+Polar Bear is a kitchen sink,
+with all sorts of opportunities for timing attacks.
 <h2>Notes on YAMB</h2>
 Key as large as 32 bytes.
 Nonce as large as 16 bytes.
@@ -201,7 +226,8 @@
 Specifically, extracts 320 bits from each AES encryption;
 about 2.5 times faster than AES.
 <p>
-Will be vulnerable to timing attacks for the same reason that AES is.
+Initial impression:
+Will be a disaster from a timing-attack perspective, just like AES.
 <h2>Notes on Fubuki</h2>
 Authors report, for a Pentium M,
 489662 cycles for setup,
@@ -221,8 +247,10 @@
 Every 4 bytes of output have one dot product and several other operations.
 <p>
 The reported speed of ABC relies on computing the dot product
-by secret-index table lookups,
-exposing ABC to timing attacks.
+by secret-index table lookups.
+<p>
+Initial impression:
+Timing attacks will be a big problem here.
 <h2>Notes on DICING</h2>
 Author reports, for an 1800MHz Athlon XP,
 918 cycles to load a 16-byte key;