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
|
## other features
|
||||||
|
|
||||||
* Short and not so ugly. This is important to enable cut-and-paste (see
|
* Short and not so ugly. This is important to enable
|
||||||
below), but also just because people are suspicious and averse to long
|
cut-and-paste (see below), but also just because people are
|
||||||
and ugly URLs. See #217 for notes in which dozens of people have
|
suspicious and averse to long and ugly URLs. See #217 for
|
||||||
spontaneously complained about the current URLs. By contrast, tiny
|
notes in which dozens of people have spontaneously complained
|
||||||
URLs such as tinyurl.com, bit.ly, etc. are ubiquitous nowadays; users
|
about the current URLs. By contrast, tiny URLs such as
|
||||||
have no problem with those -- see Twitter.
|
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
|
* 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
|
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
|
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
|
* #102 and #217 have notes on dircaps
|
||||||
* #678 (converge same file, same K, different M)
|
* #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