BEP-0041 Draft: Volunteer Peer Partial Replication & Balancing

[preston]

New BEP for volunteer storage networks with limited capabilities, using BEP-0027 and BEP-0036. Will also post a note on the mailing list!

[the8472]

Not speaking for the project managers, but I consider the following parts to be a design flaw:

• MUST enforce BEP-0027, when appropriately enabled by a metainfo file.
• SHOULD make all network communications, including all tracker and P2P interaction, over SSL.

If strong security and privacy are a concern then the private flag is of no use here and bittorrent-over-SSL is a non-standard (albeit implemented in some projects) approach that doesn't layer well with other parts of bittorrent (e.g. µTP).

Instead I would suggest using storage-layer encryption, either by encrypting the files directly / using a overlay filesystem that encrypts/decrypts file contents or by implementing transparent encryption on the client layer.

Bittorrent essentially does not care how data is represented on disk. So the translation between on-disk-representation <-> data sent over the wire can be enhanced by an encryption layer.

A post by @arvidn on stack overflow suggests that µTorrent supports such an approach: http://stackoverflow.com/a/29884311/1362755

The advantage of storage-layer encryption are manifold:

1. clients without the key can still volunteer storage/bandwidth resources by storing it in encrypted form locally
2. the transport protocol does not have to be modified or encapsulated
3. it does not matter whether public peer discovery mechanisms (DHT, PEX) are used since anyone joining the swarm through those will not have the key
4. even feeds would not have to be encrypted in this proposal as long as the keys are not included in a public version of the torrent (those who should be allowed to decrypt the data simply need a different version of the torrent file embedding the key outside the info dictionary)