Changes between Version 19 and Version 20 of NewMutableEncodingDesign


Ignore:
Timestamp:
2012-01-10T17:24:36Z (13 years ago)
Author:
zooko
Comment:

update from ECDSA to Ed25519

Legend:

Unmodified
Added
Removed
Modified
  • NewMutableEncodingDesign

    v19 v20  
    11This page is for notes and design considerations for the next version of
    2 tahoe's mutable files. NewCapDesign includes a lot of desired features, this
     2tahoe-lafs's mutable files. NewCapDesign includes a lot of desired features, this
    33page is about the backend layout that would make those features possible.
    44
     
    99 * #308 is about deep-traversal dircaps, which will require support from the
    1010   underlying mutable files
    11  * [http://allmydata.org/pipermail/tahoe-dev/2009-July/002345.html this tahoe-dev message] and its neighbors have some good discussion about cap design for mutable files
    12  * [http://allmydata.org/pipermail/tahoe-dev/2009-September/002848.html The Elk Point design] is very interesting, and has not yet been transcribed into this wiki page.
     11 * [//tahoe-dev/2009-July/002345.html this tahoe-dev message] and its neighbors have some good discussion about cap design for mutable files
     12 * [//tahoe-dev/2009-September/002848.html The Elk Point design] is very interesting, and has not yet been transcribed into this wiki page.
    1313
    1414= Parameters K and T =
     
    2222for 2^T^ target files.
    2323
    24 = Yay ECDSA =
    25 
    26 Once we have ECDSA (#331), we'll have a general-purpose signing primitive
    27 with short fields (K=kappa bits for the signing key, 2K for the verifying
    28 key, and 4K for the signature, with an expected K=128bits, so 16-byte signing
    29 keys, 32-byte verifying keys, and 64-byte signatures). Our current RSA-based
     24= Yay Ed25519 =
     25
     26Once we have Ed25519 (https://tahoe-lafs.org/trac/pycryptopp/ticket/75), we'll have a general-purpose signing primitive
     27with short fields (K+T bits for the signing key, 2K for the verifying
     28key, and 2K for the signature, with an expected K=128bits and T=64 bits, so 24-byte signing
     29keys, 64-byte verifying keys, and 64-byte signatures). Our current RSA-based
    3030signatures use 1216-*byte* signing keys, 292-byte verifying keys, and
    3131256-byte signatures.
     
    5858== Filecap Length ==
    5959
    60 A likely security parameter K (=kappa) would be 96, 128, or 160 bits.
    61 [96 bits is too short IMHO --David-Sarah]
     60A likely security parameter K (=kappa) would be 128 bits.
    6261
    6362Assuming a {{{lafs:}}} prefix and no additional metadata, here's what
    6463various lengths of base62-encoded filecaps would look like:
    6564
    66  * 1*K:
    67   * 96 {{{lafs:14efs6T5YNim0vDVV}}}
    68   * 128 {{{lafs:4V2uIYVX0PcHu9fQrJ3GSH}}}
    69   * 160 {{{lafs:8gdR7Epld72UvkF6Pe9hhT8NQx3}}}
     65 * K+T:
     66  * 128+50 {{{lafs:3zusfONRfEOp17B0ad2TDDSJxtBpvH}}}
    7067 * 2*K:
    71   * 192 {{{lafs:072Og6e75IOP9ZZsbR1Twjs6X5xXJnBAF}}}
    7268  * 256 {{{lafs:fZeioazoWrO62reiAjzUAyV0uz3ssh6Hnanv8cKMClY}}}
    73   * 320 {{{lafs:j6Re0BbWp7DqJtgd9fUXl4pWiD5kr1mjT9DtudJ72o0vhPen83Utza}}}
    7469 * 3*K:
    75   * 288 {{{lafs:11DriaxD9nipA10ueBvv5uoMoehvxgPerpQiXyvMPeiUUdtf6}}}
    7670  * 384 {{{lafs:3a31SqUbf8fpWE1opRCT3coDhRqTU7bDU2AvC3RQJBu6ZNFhVscyxA9slYtPVT79x}}}
    77   * 480 {{{lafs:P6rGeI6CwlG4i8W2l6haSoC9rfPjw0KHBi8xAk4F8vdhnRhL8nwE27CitJ9Rld06HuKt8VucypJRcbGFo}}}
    7871
    7972Adding 2 metadata characters and a clear separator gives us:
    8073
    81  * 96: {{{lafs:MW-14efs6T5YNim0vDVV}}}
    82  * 128: {{{lafs:DW-4V2uIYVX0PcHu9fQrJ3GSH}}}
    83  * 160: {{{lafs:DW-8gdR7Epld72UvkF6Pe9hhT8NQx3}}}
    84  * 192: {{{lafs:MR-072Og6e75IOP9ZZsbR1Twjs6X5xXJnBAF}}}
     74 * 128+50 {{{lafs:DW-3zusfONRfEOp17B0ad2TDDSJxtBpvH}}}
    8575 * 256: {{{lafs:DR-fZeioazoWrO62reiAjzUAyV0uz3ssh6Hnanv8cKMClY}}}
    86  * 288: {{{lafs:MV-11DriaxD9nipA10ueBvv5uoMoehvxgPerpQiXyvMPeiUUdtf6}}}
    87  * 320: {{{lafs:MR-j6Re0BbWp7DqJtgd9fUXl4pWiD5kr1mjT9DtudJ72o0vhPen83Utza}}}
    8876 * 384: {{{lafs:DV-3a31SqUbf8fpWE1opRCT3coDhRqTU7bDU2AvC3RQJBu6ZNFhVscyxA9slYtPVT79x}}}
    89  * 480: {{{lafs:MV-P6rGeI6CwlG4i8W2l6haSoC9rfPjw0KHBi8xAk4F8vdhnRhL8nwE27CitJ9Rld06HuKt8VucypJRcbGFo}}}
    90 
    91 [http://allmydata.org/trac/tahoe/ticket/217#comment:44 #217:c44] says that,
    92 if we don't need to prevent collisions, then we can use a K-bit hash for
    93 K-bit second-pre-image resistance. However, see
    94 [http://allmydata.org/trac/tahoe/ticket/882#comment:6 #882:c6] for a
    95 counterargument saying that 50 extra bits or so are needed to be secure
    96 against multi-target attacks (i.e. T = 50). This page has now been updated
    97 assuming the counterargument is correct.
     77
     78[comment:44:ticket:217 #217:c44] says that, if we don't need to prevent collisions, then we can use a K-bit hash for K-bit second-pre-image resistance. However, see [comment:6:ticket:882 #882:c6] for a counterargument saying that 50 extra bits or so are needed to be secure against multi-target attacks (i.e. T = 50). This page has now been updated assuming the counterargument is correct.
    9879
    9980= Design Proposals =