Read-Only Encrypted Peers

[MSch]

The latest version of btsync supports read-only encrypted peers, but this feature is only available through the API.

 

Does anyone have an idea why? It seems like it's something that's useful for anyone, not just developers.

 

For example lots of companies provide hosted btsync and I'd prefer if they couldn't read my data. Same with renting a cheap VPS somewhere.

[Harold Feit]

The generation and indexing of shares that support encrypted is actually significantly higher than that of normal shares.

[lolcat]

The generation and indexing of shares that support encrypted is actually significantly higher than that of normal shares.

 

Interesting. Any idea why? I would imagine that it would increase the load only for a peer that is an encrypted peer. I imagine the only thing that could make it harder is that you would need to create two databases (one for normal peers with the file lists and one for encrypted peers with the encrypted file names).

The method used for secret v2 is to create a sqlite database containing all the files. It has two tables with two fields, one is the location of the file in plain text, and the other is various attributes bencoded in a BLOB (owner, timestamps, something that looks like a torrent info hash, size, type, sig64, and so on). Each folder appears to be encrypted with its own key that is obtained from the swarm, exactly how this is done is unclear. Each file is also its own torrent.

 

For the encrypted read-only key I assume you need another table, one where you don't leak all the information. If the encrypted read-only node could see the owner, that would be unfortunate. Maintaining these two different databases would add overhead.

 

 

The latest version of btsync supports read-only encrypted peers, but this feature is only available through the API.

 

Does anyone have an idea why? It seems like it's something that's useful for anyone, not just developers.

 

For example lots of companies provide hosted btsync and I'd prefer if they couldn't read my data. Same with renting a cheap VPS somewhere.

 

This blog lists the format of new keys, and creates them as you visit the page. I thought I could make my own secret using the information gathered there. I was wrong. If the new key-scheme were like the old one (A+base32(sha(whatever)) I could just copy the first letter and add it into the client. I was able to add the new keys into the client, and the new read-only secret was the same format as on his site. But I was not able to remove the extra characters from the read-only secret and get a valid encrypted read only secret.

 

FU7BUKNYINCPE3I32Q2UTNCFJ6OS4M7TV <- Encrypted read only, the first part is the same as the read-only secret

EU7BUKNYINCPE3I32Q2UTNCFJ6OS4M7TV5YP5C5ZMT767D3BV4C5NVMQ6BE <- read-only secret

D6EY5DKO3EWCRIWM2XFTJLCAJMWD63A6X <- read-write secret

 

Now if someone were to figure out how the read-write secret is generated, we could create our own secrets. Replacing the A in a secret v2 with a D, will let your client create a read-only secret with the same length, but the client won't accept the first part as an encrypted read-only secret.

 

DJRLNSE3QUUQO6SU5ZTTIQGH5MRILCAG7

EZ3NCAAPT43XF7LPQQLE75RCWJKALAVCXTLJAUBSDXNAUNVZHGVBDV2LXLA

 

Using the first secret (a secret v2 with the a replaced with d) to create a read-only key results in this. I haven't tested if the secrets actually works, but I am able to add them to the client. Figure out how to make a valid read-write secret, and the feature is unlocked.

 

I think the rationale behind blocking users from using this feature is weak, simply add a warning that that kind of keys isn't suitable for mobile devices and warn them to use caution. That way daring users can play around with it.

[Harold Feit]

Interesting. Any idea why? I would imagine that it would increase the load only for a peer that is an encrypted peer. I imagine the only thing that could make it harder is that you would need to create two databases (one for normal peers with the file lists and one for encrypted peers with the encrypted file names).

Because you need to generate additional encryption information on a per-file basis for the encrypted keys rather than the read only ones.

 

Read-only and read-write keys have access to the files unencrypted.

The Encrypted read-only keys do NOT have unencrypted access to the files, so separate encryption information needs to be generated for them.

[lolcat]

Because you need to generate additional encryption information on a per-file basis for the encrypted keys rather than the read only ones.

 

Read-only and read-write keys have access to the files unencrypted.

The Encrypted read-only keys do NOT have unencrypted access to the files, so separate encryption information needs to be generated for them.

 

I assume you are using keys as a synonym for secrets, is that correct? What additional "encryption information" are you referring to? If I want to send you one file, then I need to encrypt it. If the torrent is made using unencrypted files, and then before the hash checking the file is decrypted, then I would be able to share a massive folder with no more overhead than the hashing for the torrents. For the encrypted read-only this approach obviously won't work, as it would have no way to check the files integrity, because it can't be decrypted. Is this the problem? If that is the case, you could have to encrypt every file and folder name, and then make the torrents. But still, to transfer the files the aes-256ing of the files would use the same amount of cpu cycles. The only problem would be for a large amount of files where you can't store the encrypted versions (so you would be forced to first encrypt all your files, and then encrypt them again when someone wants to download them).

 

The second part of your post makes no sense. I understand they don't have access to the encryption keys, but that is as simple as not providing them with the encryption keys. The files are encrypted to be sent (aes256) and encrypted to be stored by the encrypted read-only nodes. Is the performance issues just seeding, creating or downloading shares? For seeding there should be no additional overhead, other than maybe some meta data when you create a share (to get torrent hash of the encrypted file). Seeding or downloading would be no different, simply seed the torrents without giving up the encryption keys.