Changes between Version 19 and Version 20 of NewMutableEncodingDesign
- Timestamp:
- 2012-01-10T17:24:36Z (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
NewMutableEncodingDesign
v19 v20 1 1 This page is for notes and design considerations for the next version of 2 tahoe 's mutable files. NewCapDesign includes a lot of desired features, this2 tahoe-lafs's mutable files. NewCapDesign includes a lot of desired features, this 3 3 page is about the backend layout that would make those features possible. 4 4 … … 9 9 * #308 is about deep-traversal dircaps, which will require support from the 10 10 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 files12 * [ 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. 13 13 14 14 = Parameters K and T = … … 22 22 for 2^T^ target files. 23 23 24 = Yay E CDSA=25 26 Once we have E CDSA (#331), we'll have a general-purpose signing primitive27 with short fields (K =kappabits for the signing key, 2K for the verifying28 key, and 4K for the signature, with an expected K=128bits, so 16-byte signing29 keys, 32-byte verifying keys, and 64-byte signatures). Our current RSA-based24 = Yay Ed25519 = 25 26 Once we have Ed25519 (https://tahoe-lafs.org/trac/pycryptopp/ticket/75), we'll have a general-purpose signing primitive 27 with short fields (K+T bits for the signing key, 2K for the verifying 28 key, and 2K for the signature, with an expected K=128bits and T=64 bits, so 24-byte signing 29 keys, 64-byte verifying keys, and 64-byte signatures). Our current RSA-based 30 30 signatures use 1216-*byte* signing keys, 292-byte verifying keys, and 31 31 256-byte signatures. … … 58 58 == Filecap Length == 59 59 60 A likely security parameter K (=kappa) would be 96, 128, or 160 bits. 61 [96 bits is too short IMHO --David-Sarah] 60 A likely security parameter K (=kappa) would be 128 bits. 62 61 63 62 Assuming a {{{lafs:}}} prefix and no additional metadata, here's what 64 63 various lengths of base62-encoded filecaps would look like: 65 64 66 * 1*K: 67 * 96 {{{lafs:14efs6T5YNim0vDVV}}} 68 * 128 {{{lafs:4V2uIYVX0PcHu9fQrJ3GSH}}} 69 * 160 {{{lafs:8gdR7Epld72UvkF6Pe9hhT8NQx3}}} 65 * K+T: 66 * 128+50 {{{lafs:3zusfONRfEOp17B0ad2TDDSJxtBpvH}}} 70 67 * 2*K: 71 * 192 {{{lafs:072Og6e75IOP9ZZsbR1Twjs6X5xXJnBAF}}}72 68 * 256 {{{lafs:fZeioazoWrO62reiAjzUAyV0uz3ssh6Hnanv8cKMClY}}} 73 * 320 {{{lafs:j6Re0BbWp7DqJtgd9fUXl4pWiD5kr1mjT9DtudJ72o0vhPen83Utza}}}74 69 * 3*K: 75 * 288 {{{lafs:11DriaxD9nipA10ueBvv5uoMoehvxgPerpQiXyvMPeiUUdtf6}}}76 70 * 384 {{{lafs:3a31SqUbf8fpWE1opRCT3coDhRqTU7bDU2AvC3RQJBu6ZNFhVscyxA9slYtPVT79x}}} 77 * 480 {{{lafs:P6rGeI6CwlG4i8W2l6haSoC9rfPjw0KHBi8xAk4F8vdhnRhL8nwE27CitJ9Rld06HuKt8VucypJRcbGFo}}}78 71 79 72 Adding 2 metadata characters and a clear separator gives us: 80 73 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}}} 85 75 * 256: {{{lafs:DR-fZeioazoWrO62reiAjzUAyV0uz3ssh6Hnanv8cKMClY}}} 86 * 288: {{{lafs:MV-11DriaxD9nipA10ueBvv5uoMoehvxgPerpQiXyvMPeiUUdtf6}}}87 * 320: {{{lafs:MR-j6Re0BbWp7DqJtgd9fUXl4pWiD5kr1mjT9DtudJ72o0vhPen83Utza}}}88 76 * 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. 98 79 99 80 = Design Proposals =