Encrypted Torrents

[the8472]

Users/Developers often bring up the private flag when discussing the distribution of non-public data. I think it's ill-suited for that purpose and encrypted torrents would be a better choice to use public infrastructure (pex/trackers/dht) and simply keep the data confidential.

@arvidn mentioned µT's encrypted torrent feature on SO but there's no spec for it. And I couldn't even find a feature description or information on its security properties.

It would be nice if at least a bare-bones sketch of how it works could be provided so we can derive a spec from it. I want to avoid reverse-engineering it.

---

Now, disregarding existing implementations, the following is what I would want to put into a spec:

obvious must-haves:

• storage layer encryption
• seekable cipher
• encryption of file names

kinda important:

• storing the files list as an opaque, encrypted block so individual file sizes can't be discerned. For backwards compatibility / storing data in encrypted form there can still be one flat file spanning the full length.
  while file sizes aren't totally unique they could still allow an observer to infer what files are being shared if multiple files/their metadata are also publicly available. privacy-conscious users could even include length-padding files once the lengths are obscured in the metadata.
• suggestion for client devs to strip all non-essential parts from the torrent on creation

nice to have:

• a separate file name encryption key derived from root key so that webpages could list encrypted file names and client-side decryption (e.g. javascript or browser extension) could decrypt the names without leaking the actual contents in case the file name key gets compromised by the website
• optional password derivation + per torrent salt instead of random key so users can use a single password for multiple torrents

[arvidn]

Here's my recollection (from memory). perhaps @xercesblue can be convinced to fill in some details.

The data layer encryption is AES. Each 16 kiB chunk/block is encrypted individually. The low 64 bits (or maybe 32 bits) of the initialization vector contains the block index (the piece index is not used, blocks are just numbered sequentially). The key can be both 128 bits or 256 bits.

The "name" field is encrypted with the same mechanism (but I don't remember which "block" it is considered to be, presumably the IV is unique) and base64 encoded (or possibly base32).

The value of the "files" dictionary (if it's a multi-file torrent) is encrypted (verbatim in its bencoded form), base64 (or base32) encoded and put in an "encrypted_files" string. This makes the torrents fully backwards compatible. Encrypted torrents will just look like single file torrents with strange names.

The actual IVs is an important detail that I believe is hardcoded (with the block index overlaid).

In hindsight, it would probably be a better idea to use crypto_box() instead.

[arvidn]

right, I forgot to mention that in order to make multi-file torrents backwards compatible, the total size field has to be added as well. I recall considering obfuscating the size as well, by inserting random padded files, but I can't recall if I ever ended up doing that. In either case, that would be orthogonal to the encryption layer.

[the8472]

Ok, i'm trying to piece things together and testing against µT. I generated a test-torrent and obtained the magnet containing the following key argument "010000002400000003000000010000001CEE1800D8ED18000000000000009100"

Doesn't look like 128bit worth of entropy to me, let alone 256.

[the8472]

Also, you mention the 16KiB-block indices being part of the IV. But that only makes sense if a cipher mode like CBC is used for individual blocks. After all bittorrent-blocks are larger than AES-blocks.

If on the other hand a streaming mode like CTR is used then it should be the AES-block counter.

[the8472]

Well, I've started drafting my own spec:

https://github.com/bittorrent/bittorrent.org/compare/master...the8472:encrypted_torrents

Feedback welcome

[ssiloti]

I think it would be worthwhile to define a mac key in the bepXX dict which holds a MAC computed over the info dict (sans the mac key obviously) using the shadow key. This is a little awkward but not difficult to implement and authentication is desirable for many use cases.

[the8472]

good idea. rolled the probe field into that too.

Any opinion on the hash/ciphers? I considered using SHA3 and ChaCha20 but have no strong opinion in either direction. Maybe beneficial for embedded clients?

[ssiloti]

I wouldn't bother with SHA-3. There's no bulk hashing going on here so performance isn't a big enough concern to justify using such a new an not yet widely supported hash function.

For the symmetric cipher I don't think it makes a big difference either way. ChaCha20 is faster in software but AES has hardware support on x86 and ARMv8. One plus with ChaCha20 is that, unlike AES-256, it is provided by libsodium which is a common source of the Ed25519 functions required to implement BEP 44, so it could cut down on the number of dependencies a client has. The reputation extension I'm working on also uses ChaCha20[1].

[1] https://github.com/ssiloti/bep-persistent-credit/blob/master/one-hop-rep.rst#identify

[the8472]

Replaced it with ChaCha20. For high throughput clients can simply store/cache the ciphertext anyway.

Now all I need is some extra eyeballs.

[SoniEx2]

How is this coming along? Also what about merkle torrents? Also we should call them "corporate-grade torrents" to identify them as being suitable for use with sensitive corporate data.

[SoniEx2]

Any updates on this? How about interoperability with Wormhole? https://wormhole.app/ @feross why not just add keys to magnet links?

[trymeouteh]

This feature will make bittorrent perfect for sharing files privately between friends. Bittorrent is good for sharing small and large files but it is designed to share files to anyone publicly. This feature will allow bittorrent to be a file sharing protocol for sharing files privately also.

And to have a standard for storing the encrypted key (password) within the .torrent file and within magent links will be very useful also but will be optional when creating a torrent. If some creates an encrypted torrent and generated a .torrent file or magnet link with the encryption key inside the .torrent file or magnet link, all they need to do is the share the magnet link to their friends or send the .torrent file to their friend and their friends can download the torrent without needed to enter the encryption key. Similar to how many centralised file sharing services work like Send. If the person who created the encrypted torrent does not include the encryption key in the .torrent file or the magnet link, when their friends go to download the torrent, they will need to do an additional step by entering the encryption key which the creator of the torrent will need to provider separately.

However with encrypted torrents, it will allow for private file sharing just like that is offered on centralised services like Send but in a decentralised/P2P way! No need to trust these centralised services or be limited to their upload limits and it is easy to use for the sender and receiver to use. No need to add Peers and know the IP addresses of those your sharing files with which is what you need to do when sharing private torrents currently.

Encryption of file names and folders will be essential