add notes about filecap length limits

[Imported from Trac: page NewCapDesign, version 8]

NewCapDesign.md

@@ -48,12 +48,14 @@ established sense). To make them real, we need to:
 
 ## other features
 
- * Short and not so ugly. This is important to enable cut-and-paste (see 
-   below), but also just because people are suspicious and averse to long
-   and ugly URLs.  See #217 for notes in which dozens of people have 
-   spontaneously complained about the current URLs.  By contrast, tiny
-   URLs such as tinyurl.com, bit.ly, etc. are ubiquitous nowadays; users
-   have no problem with those -- see Twitter.
+ * Short and not so ugly. This is important to enable
+   cut-and-paste (see below), but also just because people are
+   suspicious and averse to long and ugly URLs. See #217 for
+   notes in which dozens of people have spontaneously complained
+   about the current URLs. By contrast, tiny URLs such as
+   tinyurl.com, bit.ly, etc. are ubiquitous nowadays; users have
+   no problem with those -- see Twitter. See below for notes on
+   cap length.
  * Enable convenient cut-and-paste. If caps are too long they'll wrap in
    email. If they contain lots of word-breaking characters then you have to
    drag after you've double clicked (this is probably ok). If the word-broken
@@ -128,4 +130,33 @@ established sense). To make them real, we need to:
  * #102 and #217 have notes on dircaps
  * #678 (converge same file, same K, different M)
 
+## filecap length
+
+We want filecaps to be as possible, but no shorter. There are
+several lower bounds on the length:
+
+ * confidentiality: A large computing effort should not be able
+   to obtain the plaintext of a tahoe file without knowing the
+   readcap. We require reasonable margin against improvements in
+   hardware speed and organization efficiency/motivation of
+   distributed efforts (e.g. could a million PS3 owners break a
+   filecap?). This currently implies a 128 bit confidentiality
+   parameter.
+ * integrity: a large computing effort should not be able to
+   produce shares which will be accepted by the readcap holder
+   but which do not result in the same file as created the
+   original uploader (and retrieved by other downloaders). We
+   desire all three of the standard hash properties (collision
+   resistance, first-pre-image resistance, second-pre-image
+   resistance) to also apply to tahoe immutable files and their
+   filecaps. This currently implies a 128bit (or 256bit?) integrity
+   parameter.
+ * storage collision resistance (#753): a Tahoe grid should be
+   able to store trillions of files and still have a vanishingly
+   small chance of two files using the same storage-index (and
+   thus confusing each other's shares). The storage-index is
+   generally compressed out of the filecap, by deriving it with
+   various hashing stages on the other filecap parameters. The
+   shortest value in this derivation chain must be at least
+   128bits long, and preferably about 192bits long.