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...