update from ECDSA to Ed25519

[Imported from Trac: page NewMutableEncodingDesign, version 20]
zooko 2012-01-10 17:24:36 +00:00
parent 4d6166196c
commit db28fb6080

@ -1,5 +1,5 @@
This page is for notes and design considerations for the next version of This page is for notes and design considerations for the next version of
tahoe's mutable files. [NewCapDesign](NewCapDesign) includes a lot of desired features, this tahoe-lafs's mutable files. [NewCapDesign](NewCapDesign) includes a lot of desired features, this
page is about the backend layout that would make those features possible. page is about the backend layout that would make those features possible.
* #217 contains a lot of the original notes. * #217 contains a lot of the original notes.
@ -8,8 +8,8 @@ page is about the backend layout that would make those features possible.
* #795 is about append-only filecaps, #796 is closely related * #795 is about append-only filecaps, #796 is closely related
* #308 is about deep-traversal dircaps, which will require support from the * #308 is about deep-traversal dircaps, which will require support from the
underlying mutable files underlying mutable files
* [this tahoe-dev message](http://allmydata.org/pipermail/tahoe-dev/2009-July/002345.html) and its neighbors have some good discussion about cap design for mutable files * [//tahoe-dev/2009-July/002345.html this tahoe-dev message] and its neighbors have some good discussion about cap design for mutable files
* [The Elk Point design](http://allmydata.org/pipermail/tahoe-dev/2009-September/002848.html) is very interesting, and has not yet been transcribed into this wiki page. * [//tahoe-dev/2009-September/002848.html The Elk Point design] is very interesting, and has not yet been transcribed into this wiki page.
# Parameters K and T # Parameters K and T
@ -21,12 +21,12 @@ into account
so that attacks against integrity also require p * 2^K^ work factor so that attacks against integrity also require p * 2^K^ work factor
for 2^T^ target files. for 2^T^ target files.
# Yay ECDSA # Yay Ed25519
Once we have ECDSA (#331), we'll have a general-purpose signing primitive Once we have Ed25519 (<https://tahoe-lafs.org/trac/pycryptopp/ticket/75>), we'll have a general-purpose signing primitive
with short fields (K=kappa bits for the signing key, 2K for the verifying with short fields (K+T bits for the signing key, 2K for the verifying
key, and 4K for the signature, with an expected K=128bits, so 16-byte signing key, and 2K for the signature, with an expected K=128bits and T=64 bits, so 24-byte signing
keys, 32-byte verifying keys, and 64-byte signatures). Our current RSA-based keys, 64-byte verifying keys, and 64-byte signatures). Our current RSA-based
signatures use 1216-*byte* signing keys, 292-byte verifying keys, and signatures use 1216-*byte* signing keys, 292-byte verifying keys, and
256-byte signatures. 256-byte signatures.
@ -57,44 +57,25 @@ relative to using a hash truncated to K+T bits.
## Filecap Length ## Filecap Length
A likely security parameter K (=kappa) would be 96, 128, or 160 bits. A likely security parameter K (=kappa) would be 128 bits.
[96 bits is too short IMHO --David-Sarah]
Assuming a `lafs:` prefix and no additional metadata, here's what Assuming a `lafs:` prefix and no additional metadata, here's what
various lengths of base62-encoded filecaps would look like: various lengths of base62-encoded filecaps would look like:
* 1*K: * K+T:
* 96 `lafs:14efs6T5YNim0vDVV` * 128+50 `lafs:3zusfONRfEOp17B0ad2TDDSJxtBpvH`
* 128 `lafs:4V2uIYVX0PcHu9fQrJ3GSH`
* 160 `lafs:8gdR7Epld72UvkF6Pe9hhT8NQx3`
* 2*K: * 2*K:
* 192 `lafs:072Og6e75IOP9ZZsbR1Twjs6X5xXJnBAF`
* 256 `lafs:fZeioazoWrO62reiAjzUAyV0uz3ssh6Hnanv8cKMClY` * 256 `lafs:fZeioazoWrO62reiAjzUAyV0uz3ssh6Hnanv8cKMClY`
* 320 `lafs:j6Re0BbWp7DqJtgd9fUXl4pWiD5kr1mjT9DtudJ72o0vhPen83Utza`
* 3*K: * 3*K:
* 288 `lafs:11DriaxD9nipA10ueBvv5uoMoehvxgPerpQiXyvMPeiUUdtf6`
* 384 `lafs:3a31SqUbf8fpWE1opRCT3coDhRqTU7bDU2AvC3RQJBu6ZNFhVscyxA9slYtPVT79x` * 384 `lafs:3a31SqUbf8fpWE1opRCT3coDhRqTU7bDU2AvC3RQJBu6ZNFhVscyxA9slYtPVT79x`
* 480 `lafs:P6rGeI6CwlG4i8W2l6haSoC9rfPjw0KHBi8xAk4F8vdhnRhL8nwE27CitJ9Rld06HuKt8VucypJRcbGFo`
Adding 2 metadata characters and a clear separator gives us: Adding 2 metadata characters and a clear separator gives us:
* 96: `lafs:MW-14efs6T5YNim0vDVV` * 128+50 `lafs:DW-3zusfONRfEOp17B0ad2TDDSJxtBpvH`
* 128: `lafs:DW-4V2uIYVX0PcHu9fQrJ3GSH`
* 160: `lafs:DW-8gdR7Epld72UvkF6Pe9hhT8NQx3`
* 192: `lafs:MR-072Og6e75IOP9ZZsbR1Twjs6X5xXJnBAF`
* 256: `lafs:DR-fZeioazoWrO62reiAjzUAyV0uz3ssh6Hnanv8cKMClY` * 256: `lafs:DR-fZeioazoWrO62reiAjzUAyV0uz3ssh6Hnanv8cKMClY`
* 288: `lafs:MV-11DriaxD9nipA10ueBvv5uoMoehvxgPerpQiXyvMPeiUUdtf6`
* 320: `lafs:MR-j6Re0BbWp7DqJtgd9fUXl4pWiD5kr1mjT9DtudJ72o0vhPen83Utza`
* 384: `lafs:DV-3a31SqUbf8fpWE1opRCT3coDhRqTU7bDU2AvC3RQJBu6ZNFhVscyxA9slYtPVT79x` * 384: `lafs:DV-3a31SqUbf8fpWE1opRCT3coDhRqTU7bDU2AvC3RQJBu6ZNFhVscyxA9slYtPVT79x`
* 480: `lafs:MV-P6rGeI6CwlG4i8W2l6haSoC9rfPjw0KHBi8xAk4F8vdhnRhL8nwE27CitJ9Rld06HuKt8VucypJRcbGFo`
[#217:c44](http://allmydata.org/trac/tahoe/ticket/217#comment:44) says that, [#217:c44]comment:44:[/tahoe-lafs/trac-2024-07-25/issues/7722](/tahoe-lafs/trac-2024-07-25/issues/7722) 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 [#882:c6]comment:6:[/tahoe-lafs/trac-2024-07-25/issues/8387](/tahoe-lafs/trac-2024-07-25/issues/8387) 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.
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
[#882:c6](http://allmydata.org/trac/tahoe/ticket/882#comment:6) 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.
# Design Proposals # Design Proposals