kappa-db/multifeed

Re-enable encryption

telamon opened this issue · 0 comments

I've been digging a bit into the multifeed, trying to create a 'personal-multi-feed' module on top that Is wholly encrypted and only replicated among devices that I control.

In order to do that ....

I've exposed setting the fake-feed key as an option,
limiting replication to multifeeds that use the same bootstrap key.

@@ -39,6 +41,7 @@ function Multifeed (hypercore, storage, opts) {
     // Private key-less constant hypercore to bootstrap hypercore-protocol
     // replication.
     var publicKey = new Buffer('bee80ff3a4ee5e727dc44197cb9d25bf8f19d50b0f3ad2984cfe5b7d14e75de7', 'hex')
+    if (opts && opts.swarmKey) publicKey = new Buffer(opts.swarmKey, 'hex')
     var feed = hypercore(self._storage('fake'), publicKey)
     feed.ready(function () {
       self._fake = feed

And re-enabled encryption using opts:

@@ -149,7 +152,8 @@ Multifeed.prototype.replicate = function (opts) {
   opts.expectedFeeds = Object.keys(this._feeds).length + 1
   var expectedFeeds = opts.expectedFeeds
 
-  opts.encrypt = false
+  // Why was encryption hardcoded to false?
+  opts.encrypt = !!opts.encrypt
   opts.stream = protocol(opts)
 
   function addMissingKeys (keys, cb) {

So the effect is pretty much what I was after except that the multifeed header is still sent completely unencrypted since it's sent before hyper-protocol bootstraps it's xor-channel, which in turn causes the header.keys array to be exposed over the network.

So my question is, what would be the cleanest way to achieve header-encryption, encrypt it separately inside multifeed module (forcing additional buffer-alloc-unsafe and sodium-universal dependencies)
or try and refactor the header-exchange to take place after hyper-protocol encryption initiation, enabling us to piggy-back on the hyper-protocol private-api's xor-stream opts.stream._xor and opts.stream._remote_xor?

While writing this it makes me realize both proposals sound pretty ugly...