[tahoe-lafs-trac-stream] [Tahoe-LAFS] #510: use plain HTTP for storage server protocol

Tahoe-LAFS trac at tahoe-lafs.org
Thu Mar 19 00:54:55 UTC 2015


#510: use plain HTTP for storage server protocol
------------------------------+---------------------------------
     Reporter:  warner        |      Owner:  zooko
         Type:  enhancement   |     Status:  new
     Priority:  major         |  Milestone:  2.0.0
    Component:  code-storage  |    Version:  1.2.0
   Resolution:                |   Keywords:  standards gsoc http
Launchpad Bug:                |
------------------------------+---------------------------------

Comment (by warner):

 I was thinking about this again yesterday, and re-invented the MAC-with-WE
 scheme from comment:11 . But this time, since Curve25519 is so cheap these
 days, I figured we could stick with the same WE as before (derived from
 the writecap and the server ID), and encrypt it with the create-mutable-
 slot message, instead of retaining any connection-like state between the
 client and each server. Something like:

 * all reads are just GETs
 * immutable write is an account-signed netstring-encoded POSTs
 * mutable create-slot puts a Curve25519/ElGamal-encrypted WE into the
 account-signed netstring-encoded POST
 * mutable modify uses the WE to HMAC the netstring-encoded modification
 message. The HMACed message is then account-signed.

 Moreover, I think the server's (signed) introducer announcement can be
 hosted over HTTP too, at a well-known URL. Then the server can be
 correctly described with the server's !Ed25519 pubkey (the same one that
 signs announcements), and the URL where it lives. These two pieces of
 information could be put in a client-side statically-configured "known-
 servers" file, and the rest (including the Curve25519 pubkey for this
 encrypted-WE thing) gets fetched when the node starts up.

 If we use the same writecap-derived WE (instead of switching to an
 !ed25519 pubkey), we don't need the WE-migration process.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/510#comment:38>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage


More information about the tahoe-lafs-trac-stream mailing list