Streaming file encryption

[feross]

No description provided.

[feross]

Going to punt on this feature for now. I want to get the basics of webtorrent/instant.io as quickly as possible and this feature is a distraction.

The WebRTC transport is already encrypted, and if users really want they can encrypt their files before sending them with instant.io.

[feross]

Re-opening, since this feature is a requirement for #18.

[rugk]

FYI there is a lib developed, which uses NaCl encryption on top of WebRTC (which is already quite secure) to encrypt files end-to-end in a secure way (so the signalling servers cannot do MITM attacks): https://github.com/saltyrtc

[dominictarr]

hey, just saw this - I have a module that would be suitable,
https://github.com/dominictarr/pull-box-stream

but ideally, we might want to modify that a little bit, so that encrypted blocks are a) aligned to bit torrent blocks, and seekable. currently pull-box-stream can just encrypts streaming blocks, but makes them whatever length the source provides the buffers as. That means you could still seek from the beginning, but it would be much more neat to be able to seek from any point.

what we'd have is some size block that was nice for eg video, so that you can start streaming, that aligned with the bit torrent block size, because you need to jump to the encrypted blocks to decrypt them.

Hmm, actually, since fixed sized blocks work best with bit torrent, you can have something simpler than box-stream. Anyway, happy to help with this if you decide it's time.

[feross]

@dominictarr I don't have time at the moment for this, but thanks for sharing the link to pull-box-stream. I didn't know that there was a way to run libsodium in the browser via chloride, so that's good to know!

[dominictarr]

cool, I think the question is just: is there a way to predict the blocks that will be requested? if yes, then this is easy.

[dominictarr]

the block boundries, i mean