From db28fb60804c7ac02579294e0a7e36010aea53a7 Mon Sep 17 00:00:00 2001 From: zooko <> Date: Tue, 10 Jan 2012 17:24:36 +0000 Subject: [PATCH] update from ECDSA to Ed25519 [Imported from Trac: page NewMutableEncodingDesign, version 20] --- NewMutableEncodingDesign.md | 45 +++++++++++-------------------------- 1 file changed, 13 insertions(+), 32 deletions(-) diff --git a/NewMutableEncodingDesign.md b/NewMutableEncodingDesign.md index bfa8496..7ed2fad 100644 --- a/NewMutableEncodingDesign.md +++ b/NewMutableEncodingDesign.md @@ -1,5 +1,5 @@ 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. * #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 * #308 is about deep-traversal dircaps, which will require support from the 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 - * [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-July/002345.html this tahoe-dev message] and its neighbors have some good discussion about cap design for mutable files + * [//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 @@ -21,12 +21,12 @@ into account so that attacks against integrity also require p * 2^K^ work factor for 2^T^ target files. -# Yay ECDSA +# Yay Ed25519 -Once we have ECDSA (#331), we'll have a general-purpose signing primitive -with short fields (K=kappa bits for the signing key, 2K for the verifying -key, and 4K for the signature, with an expected K=128bits, so 16-byte signing -keys, 32-byte verifying keys, and 64-byte signatures). Our current RSA-based +Once we have Ed25519 (), we'll have a general-purpose signing primitive +with short fields (K+T bits for the signing key, 2K for the verifying +key, and 2K for the signature, with an expected K=128bits and T=64 bits, so 24-byte signing +keys, 64-byte verifying keys, and 64-byte signatures). Our current RSA-based signatures use 1216-*byte* signing keys, 292-byte verifying keys, and 256-byte signatures. @@ -57,44 +57,25 @@ relative to using a hash truncated to K+T bits. ## Filecap Length -A likely security parameter K (=kappa) would be 96, 128, or 160 bits. -[96 bits is too short IMHO --David-Sarah] +A likely security parameter K (=kappa) would be 128 bits. Assuming a `lafs:` prefix and no additional metadata, here's what various lengths of base62-encoded filecaps would look like: - * 1*K: - * 96 `lafs:14efs6T5YNim0vDVV` - * 128 `lafs:4V2uIYVX0PcHu9fQrJ3GSH` - * 160 `lafs:8gdR7Epld72UvkF6Pe9hhT8NQx3` + * K+T: + * 128+50 `lafs:3zusfONRfEOp17B0ad2TDDSJxtBpvH` * 2*K: - * 192 `lafs:072Og6e75IOP9ZZsbR1Twjs6X5xXJnBAF` * 256 `lafs:fZeioazoWrO62reiAjzUAyV0uz3ssh6Hnanv8cKMClY` - * 320 `lafs:j6Re0BbWp7DqJtgd9fUXl4pWiD5kr1mjT9DtudJ72o0vhPen83Utza` * 3*K: - * 288 `lafs:11DriaxD9nipA10ueBvv5uoMoehvxgPerpQiXyvMPeiUUdtf6` * 384 `lafs:3a31SqUbf8fpWE1opRCT3coDhRqTU7bDU2AvC3RQJBu6ZNFhVscyxA9slYtPVT79x` - * 480 `lafs:P6rGeI6CwlG4i8W2l6haSoC9rfPjw0KHBi8xAk4F8vdhnRhL8nwE27CitJ9Rld06HuKt8VucypJRcbGFo` Adding 2 metadata characters and a clear separator gives us: - * 96: `lafs:MW-14efs6T5YNim0vDVV` - * 128: `lafs:DW-4V2uIYVX0PcHu9fQrJ3GSH` - * 160: `lafs:DW-8gdR7Epld72UvkF6Pe9hhT8NQx3` - * 192: `lafs:MR-072Og6e75IOP9ZZsbR1Twjs6X5xXJnBAF` + * 128+50 `lafs:DW-3zusfONRfEOp17B0ad2TDDSJxtBpvH` * 256: `lafs:DR-fZeioazoWrO62reiAjzUAyV0uz3ssh6Hnanv8cKMClY` - * 288: `lafs:MV-11DriaxD9nipA10ueBvv5uoMoehvxgPerpQiXyvMPeiUUdtf6` - * 320: `lafs:MR-j6Re0BbWp7DqJtgd9fUXl4pWiD5kr1mjT9DtudJ72o0vhPen83Utza` * 384: `lafs:DV-3a31SqUbf8fpWE1opRCT3coDhRqTU7bDU2AvC3RQJBu6ZNFhVscyxA9slYtPVT79x` - * 480: `lafs:MV-P6rGeI6CwlG4i8W2l6haSoC9rfPjw0KHBi8xAk4F8vdhnRhL8nwE27CitJ9Rld06HuKt8VucypJRcbGFo` -[#217:c44](http://allmydata.org/trac/tahoe/ticket/217#comment:44) 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](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. +[#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. # Design Proposals