Changes between Version 8 and Version 9 of NewCapDesign


Ignore:
Timestamp:
2009-08-25T10:26:54Z (15 years ago)
Author:
warner
Comment:

reorg, copy relevant notes from referenced tickets (unrolling the loops, so to speak)

Legend:

Unmodified
Added
Removed
Modified

  • NewCapDesign

    v8 v9  
    77list.
    88
    9 There will be a related pair of new encoding designs. The NewImmutableEncodingDesign
    10 and NewMutableEncodingDesign pages will hold those design discussions.
     9There will be a related pair of new encoding designs. The
     10NewImmutableEncodingDesign and NewMutableEncodingDesign pages will hold those
     11design discussions.
    1112
    1213Ticket #432 was the starting point: it contained a list of features.
    … …  
    2627   have a URI and somebody pointed you at a file, you could confidently tell
    2728   them whether or not it was the right file, but if you only have the URI,
    28    then you might not be able to find the file without additional information). If
    29    the cap has both identifying and location information, it's called a URL.
     29   then you might not be able to find the file without additional
     30   information). If the cap has both identifying and location information,
     31   it's called a URL.
    3032 * Tahoe filecaps are meant to be URLs (they are intended to provide location
    3133   information), but to really make that work, you also need to define which
    … …  
    4648    a gateway HTTP URL, and ending with the contents of the file.
    4749
    48 
    49 == other features ==
     50== make them shorter, prettier, and easier to use ==
    5051
    5152 * Short and not so ugly. This is important to enable
    … …  
    5556   about the current URLs. By contrast, tiny URLs such as
    5657   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.
     58   no problem with those -- see Twitter.
     59  * I (warner) am curious about where the suspicion comes from. Do long URLs
     60    make people think they're being attacked, some sort of browser buffer
     61    overrun thing? Or that they're being phished, with a URL that a human
     62    would evaluate differently than their browser? I agree that people
     63    (including me) don't like long URLs, but I've never pushed anyone to
     64    explain the "suspicion" aspect. One comment in #217 says "smells a bit
     65    spammy", and a later one says "Spooks me every time".
    5966 * Enable convenient cut-and-paste. If caps are too long they'll wrap in
    6067   email. If they contain lots of word-breaking characters then you have to
    … …  
    7885   launched with {{{tahoe:foo}}}, and that in turn launches your web browser
    7986   with {{{http://localhost:8123/foo}}}). (#52)
     87
     88== make them long enough to be secure ==
     89
     90We want filecaps to be as possible, but no shorter. There are
     91several lower bounds on the length:
     92
     93 * confidentiality: A large computing effort should not be able
     94   to obtain the plaintext of a tahoe file without knowing the
     95   readcap. We require reasonable margin against improvements in
     96   hardware speed and organization efficiency/motivation of
     97   distributed efforts (e.g. could a million PS3 owners break a
     98   filecap?). This currently implies a 128 bit confidentiality
     99   field.
     100 * integrity: a large computing effort should not be able to
     101   produce shares which will be accepted by the readcap holder
     102   but which do not result in the same file as created the
     103   original uploader (and retrieved by other downloaders). We
     104   desire all three of the standard hash properties (collision
     105   resistance, first-pre-image resistance, second-pre-image
     106   resistance) to also apply to tahoe immutable files and their
     107   filecaps. This currently implies a 128bit (or 256bit?)
     108   integrity field.
     109  * variable-length integrity field (#102, comment 16+17),
     110    allowing users to decide between short caps and strong
     111    integrity guarantees
     112 * storage collision resistance (#753): a Tahoe grid should be
     113   able to store trillions of files and still have a vanishingly
     114   small chance of two files using the same storage-index (and
     115   thus confusing each other's shares). The storage-index is
     116   generally compressed out of the filecap, by deriving it with
     117   various hashing stages on the other filecap parameters. The
     118   shortest value in this derivation chain must be at least
     119   128bits long, and preferably about 192bits long.
     120
     121
     122== other features ==
     123
    80124 * Self-identifying. It should be visually clear what sort of filecap the
    81125   string represents: read-write or read-only, mutable-or-immutable,
    … …  
    84128   user to tell whether they're giving away readonly access or read-write
    85129   access. We've considered prefixes like {{{DWM..}}} for "Directory
    86    Writeable Mutable" and {{{FRI..}}} for "File Readonly Immutable". If these
    87    are jammed against the (base62) crypto bits it may be difficult to tell
    88    where the prefix ends and the crypto bits begin, especially because the
    89    crypto bits will be using the same character set ({{{FRIDWM...}}}). It
    90    might be a good idea to separate the type prefix from the cryptobits:
    91    {{{FRI-cryptobits}}} or {{{FRI/cryptobits}}}.
     130   Writeable Mutable" and {{{FRI..}}} for "File Readonly Immutable" (#102
     131   comment 12). If these are jammed against the (base62) crypto bits it may
     132   be difficult to tell where the prefix ends and the crypto bits begin,
     133   especially because the crypto bits will be using the same character set
     134   ({{{FRIDWM...}}}). It might be a good idea to separate the type prefix
     135   from the cryptobits: {{{FRI-cryptobits}}} or {{{FRI/cryptobits}}}.
    92136  * in addition, tahoe URIs should be distinguishable from local filenames by
    93137    a CLI tool, so that {{{tahoe cp $CAP local/foo.txt}}} is unambiguous.
    … …  
    111155    verbose s-expressions, these caps could be expressed as "(readonly
    112156    (mutable cryptobits))" and "(directory (readonly (mutable cryptobits)))".
    113  * provide for verifycaps, repaircaps, and traversalcaps. Repaircaps in
    114    particular may require a grant of storage authority, which might entail a
    115    cap format that can accept arbitrary extra non-hierarchical fields.
    116    Appendcaps or "drop-box" writecaps might fall into this same space. But
    117    remember that URIs should identify objects, not the action that you want
    118    to do on it: a webapi scheme may use a POST/PUT/DELETE method, or append a
    119    t=json adverb, or alternatively encode the verb/adverb into the HTTP url
    120    (think {{{GET .../filecap/json}}} or {{{PUT unlinked/ciphertext}}}), but
    121    these are independent of the underlying filecap.
     157 * provide for verifycaps, repaircaps, and traversalcaps (#308, #217).
     158   Repaircaps in particular may require a grant of storage authority, which
     159   might entail a cap format that can accept arbitrary extra non-hierarchical
     160   fields. Appendcaps or "drop-box" writecaps might fall into this same
     161   space. But remember that URIs should identify objects, not the action that
     162   you want to do on it: a webapi scheme may use a POST/PUT/DELETE method, or
     163   append a t=json adverb, or alternatively encode the verb/adverb into the
     164   HTTP url (think {{{GET .../filecap/json}}} or {{{PUT
     165   unlinked/ciphertext}}}), but these are independent of the underlying
     166   filecap.
    122167 * provide ciphertext access. Reading from a verifycap should give you
    123168   ciphertext. It should be possible to upload ciphertext directly.
    … …  
    128173   {{{tahoe://grid1234/D/MR/cryptobits}}} should reference
    129174   {{{tahoe://grid1234/MR/cryptobits}}}. (#403)
    130  * #102 and #217 have notes on dircaps
    131  * #678 (converge same file, same K, different M)
    132 
    133 == filecap length ==
    134 
    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 
     175 * permit multiple encodings of the same file (same k, different N) to use
     176   each other's shares (#678)