| 51 | | * Short and not so ugly. This is important to enable cut-and-paste (see |
| 52 | | below), but also just because people are suspicious and averse to long |
| 53 | | and ugly URLs. See #217 for notes in which dozens of people have |
| 54 | | spontaneously complained about the current URLs. By contrast, tiny |
| 55 | | URLs such as tinyurl.com, bit.ly, etc. are ubiquitous nowadays; users |
| 56 | | have no problem with those -- see Twitter. |
| | 51 | * Short and not so ugly. This is important to enable |
| | 52 | cut-and-paste (see below), but also just because people are |
| | 53 | suspicious and averse to long and ugly URLs. See #217 for |
| | 54 | notes in which dozens of people have spontaneously complained |
| | 55 | about the current URLs. By contrast, tiny URLs such as |
| | 56 | tinyurl.com, bit.ly, etc. are ubiquitous nowadays; users have |
| | 57 | no problem with those -- see Twitter. See below for notes on |
| | 58 | cap length. |
| | 135 | We want filecaps to be as possible, but no shorter. There are |
| | 136 | several lower bounds on the length: |
| | 137 | |
| | 138 | * confidentiality: A large computing effort should not be able |
| | 139 | to obtain the plaintext of a tahoe file without knowing the |
| | 140 | readcap. We require reasonable margin against improvements in |
| | 141 | hardware speed and organization efficiency/motivation of |
| | 142 | distributed efforts (e.g. could a million PS3 owners break a |
| | 143 | filecap?). This currently implies a 128 bit confidentiality |
| | 144 | parameter. |
| | 145 | * integrity: a large computing effort should not be able to |
| | 146 | produce shares which will be accepted by the readcap holder |
| | 147 | but which do not result in the same file as created the |
| | 148 | original uploader (and retrieved by other downloaders). We |
| | 149 | desire all three of the standard hash properties (collision |
| | 150 | resistance, first-pre-image resistance, second-pre-image |
| | 151 | resistance) to also apply to tahoe immutable files and their |
| | 152 | filecaps. This currently implies a 128bit (or 256bit?) integrity |
| | 153 | parameter. |
| | 154 | * storage collision resistance (#753): a Tahoe grid should be |
| | 155 | able to store trillions of files and still have a vanishingly |
| | 156 | small chance of two files using the same storage-index (and |
| | 157 | thus confusing each other's shares). The storage-index is |
| | 158 | generally compressed out of the filecap, by deriving it with |
| | 159 | various hashing stages on the other filecap parameters. The |
| | 160 | shortest value in this derivation chain must be at least |
| | 161 | 128bits long, and preferably about 192bits long. |
| | 162 | |
