`Oh, and by the way the way that TahoeLAFS uses public key`

`cryptography highlights some of the weaknesses of current public key`

`techniques and some of the strengths of possible future techniques`

`such as hyperelliptic curves. (I know that Tanja Lange has done a`

`lot of work on those.)`

`TahoeLAFS generates a unique public-private key pair for each mutable`

`file and each directory. (Immutable files don't use public key`

`cryptography at all -- they are secured solely with a stream cipher`

`and secure hashes.) The "file handle" or "capability" to a mutable`

`file or directory contains the actual public key (if it is a read-`

`only capability) or the actual private key (if it is a read-write`

`capability). Therefore some of our most important measures of`

`performance are public key size and keypair generation time.`

`Unfortunately, we blundered into using one of the worst possible`

`public key signature algorithms for such requirements: RSA! Our`

`current project is replacing RSA with ECDSA. TahoeLAFS v2.0 will`

`support ECDSA-based capabilities (in addition to RSA-based ones for`

`backward compatibility).`

`TahoeLAFS also requires more than two levels of privilege. With`

`traditional public/private keys there are exactly two levels: you`

`either know the private key or you don't. We need to have an`

`intermediate level of privilege -- someone who doesn't know the`

`private key but who does know something that not everyone knows.`

`(Everyone knows the public key.) We use these three levels of`

`privilege to create read-write capabilities, read-only capabilities`

`and verify capabilities. (A verify capability gives the ability to`

`check integrity of the ciphertext, which everyone has, because`

`everyone knows the public key). If this doesn't make sense to you`

`then see if my longer explanation in lafs.pdf makes any more sense.`

`Anyway, if it is true that hyperelliptic curves have a security level`

`commensurate with the number of bits in the public key, then`

`hyperelliptic curves with semi-private keys would be the ideal public`

`key crypto signature scheme for TahoeLAFS. Unfortunately, semi-`

`private keys aren't proven secure nor properly peer-reviewed, and`

`hyperelliptic curves aren't well implemented or widely appreciated.`

`Hopefully someday TahoeLAFS v3.0 will support semi-private-`

`hyperelliptic-curve-based capabilities (in addition to RSA and ECDSA`

`for backward compatibility).`

Regards, Zooko Wilcox-O'Hearn

`P.S. Oh, I told a lie in the interests of brevity when I said that`

`file handles contain actual public keys or actual private keys. RSA`

`keys are way too big for that. So instead we go through interesting`

`contortions to make a "surrogate" value which can be used to check`

`the correctness of the RSA key (i.e. the surrogate value is derived`

`from the RSA key by secure hashing) as well as can be used to control`

`access to the RSA key (the RSA key is encrypted with a stream cipher`

`using the surrogate value as the symmetric encryption key). The`

`surrogate value therefore offers the same integrity and access`

`control properties as the RSA key itself (when the user also has`

`access to the encrypted RSA key itself), but it is sufficiently short`

`to embed directly into the file handles a.k.a. capabilities. This`

`too is explained more fully in lafs.pdf.`

[1] http://allmydata.org/~zooko/lafs.pdf [2] http://allmydata.org/trac/tahoe/ticket/217#comment:50 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com