add notes about filecap length limits
[Imported from Trac: page NewCapDesign, version 8]
parent
e3b573a59e
commit
7fb81cf2ab
|
@ -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.
|
||||
|
||||
|
|
Loading…
Reference in a new issue