[tahoe-dev] [tahoe-lafs] #217: Ed25519-based mutable files -- fast file creation, possibly smaller URLs

[tahoe-lafs]

#217: Ed25519-based mutable files -- fast file creation, possibly smaller URLs
-------------------------+-------------------------------------------------
     Reporter:  zooko    |      Owner:  zooko
         Type:           |     Status:  assigned
  enhancement            |  Milestone:  2.0.0
     Priority:  major    |    Version:  0.7.0
    Component:  code-    |   Keywords:  mutable crypto newcaps performance
  mutable                |  research
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------
Changes (by zooko):

 * keywords:  mutable crypto newcaps performance => mutable crypto newcaps
     performance research


Old description:

> Mole2 and The_8472 and I had a conversation on IRC which leads to the
> following ideas.  These are late-night-sleepy and fresh ideas, so they
> may be holey.
>
> To create a new mutable file choose a random seed ''r'', and use it to
> produce a public/private key pair (for concreteness, think
> [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm DSA], so your
> private key is a just the random 256-bit number ''r'' and the public key
> is just ''g''^''r''^ mod a big prime, let's say maybe 4096-bits).
>
> Now let the symmetric encryption key ''k'' be the secure hash of the
> public key!
>
> Now encrypt the file and upload it.  Now encrypt the public key and
> upload it.  Now if you give someone ''k'' they can read and verify.  If
> you give them ''r'' they can read and write (sign).
>
> Let the "location index" be derived from the read-capability.
>

> To squeeze ''r'' you can pick a smaller random number for ''r'', maybe
> 128-bits and use a secure hash to expand it to 256-bits.  This is
> cryptographically questionable, but it may be worth asking those
> questions in order to get really nice "printable capability" lengths, as
> well as a pleasing simplicity of crypto structure.

New description:

 Mole2 and The_8472 and I had a conversation on IRC which leads to the
 following ideas.  These are late-night-sleepy and fresh ideas, so they may
 be holey.

 To create a new mutable file choose a random seed ''r'', and use it to
 produce a public/private key pair (for concreteness, think
 [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm DSA], so your
 private key is a just the random 256-bit number ''r'' and the public key
 is just ''g''^''r''^ mod a big prime, let's say maybe 4096-bits).

 Now let the symmetric encryption key ''k'' be the secure hash of the
 public key!

 Now encrypt the file and upload it.  Now encrypt the public key and upload
 it.  Now if you give someone ''k'' they can read and verify.  If you give
 them ''r'' they can read and write (sign).

 Let the "location index" be derived from the read-capability.


 To squeeze ''r'' you can pick a smaller random number for ''r'', maybe
 128-bits and use a secure hash to expand it to 256-bits.  This is
 cryptographically questionable, but it may be worth asking those questions
 in order to get really nice "printable capability" lengths, as well as a
 pleasing simplicity of crypto structure.

--

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/217#comment:69>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage