How Do We Create Encrypted Read-Only Peers In 2.0?

[el_milagro]

topic says it all, i can't figure out how to do it. i thought we weren't going to lose any functionality?

[el_milagro]

Whether or not there's a new and improved 2.0 way to do this that's just incredibly well-hidden, it looks like sync 2.0's backward compatibility includes 1.4-style ERO peers. Probably existing ones work, the problem is creating new ones, since i scrapped and redid pretty much my whole btsync deploy to try the 2.0 stuff on my non-ERO stuff (which is most of it, and the important stuff), i was kind of in a pickle as there's no way to generate new 1.4-style keys in the 2.0 UI.

 

Building off this post and combining it with the "fun facts" from this one, after some trial and error my process to generate new 1.4 style keys on my macbook (probably the same on linux) was:

 

1. in terminal: dd if=/dev/urandom bs=32 count=1 | base64 | tr “[a-z]” “[A-Z]”

 

2. trim the result to 32 alphanumeric characters

 

3. replace all digits that are not 2-7 inclusive, i.e. all 0s, 1s, 8s, and 9s with the result of an online dice roll that does fall between 2-7 (this is very annoying and probably not the best way to do this, feel free to improve on it with terminal wizardry, i'm a noob, but i only had to worry about doing it once so i sucked it up)

 

4. prepend 'A' for normal key, or in my case since i wanted to have ERO peers, 'D' for a key that enables you to get an ERO key out of the UI, to bring total key length to 33 characters

 

5. on my main host in sync 2.0 click gear icon, manual connection, paste key, pick folder

 

6. on folder that now shows up as 1.4 folder in sync ui, right click, preferences, view key, copy encrypted key (or whichever if you made a normal 'A' key)

 

7. on my ERO peer (note that it must have a separate btsync "identity" from the host) in sync 2.0 click gear icon, manual connection, paste encrypted key

 

8. breathe sigh of relief

 

hopefully sync 2.0 resolves all the horrible problems i was having with syncing a large number of photos to an ERO peer like a support person told me it would, even though you apparently have to use 1.4 methods to even do it, but i won't be able to really put it through its paces until next week. for now i'm at least glad it's still kind of feasible. 

 

here is an example of my key generation process matching the steps from before:

 

1. UOWAWOXTTZQGYVPLMTF8K0C/IYX3TGDFUZYU3ZZ5UPG=

2. UOWAWOXTTZQGYVPLMTF8K0CIYX3TGDFU

3. UOWAWOXTTZQGYVPLMTF6K5CIYX3TGDFU

4. DUOWAWOXTTZQGYVPLMTF6K5CIYX3TGDFU

 

if this looks horribly wrong to anyone please let me know. for example, i thought i saw some talk one time about allowing keys longer that 33 characters, but the UI didn't seem to like it when i tried. 

[Alek]

I did the exact same thing and now regret it. Permissions should be set independently for each sync (top level folder), not assigned because of some arbitrary 'identity' or 'ownership'. Just because you 'linked' two 'devices' doesn't mean you want everything read-write between them. To get the permissions functionality back I am creating separate identities as a quick and easy fix to this problem. Hopefully this will be rectified in a future release.

[ICE]

@el_milagro

Have a look here ( http://forum.bittorrent.com/topic/33249-encrypted-folders/ ), espacially 

 

New certificate-based model is flexible enough to support encrypted shares, though I can't share exact plans regarding encrypted shares at the moment - sorry.

 

[iswrong]

1. in terminal: dd if=/dev/urandom bs=32 count=1 | base64 | tr “[a-z]” “[A-Z]”

 

Note: it seems to me that this approach weakens the key, since you are you are squeezing a certain range non-uniformly into another space.

 

 

 

3. replace all digits that are not 2-7 inclusive, i.e. all 0s, 1s, 8s, and 9s with the result of an online dice roll that does fall between 2-7

 

Just use Base32 .

dd if=/dev/urandom bs=20 count=1 | /usr/bin/python -c "import sys;import base64; sys.stdout.write(base64.b32encode(sys.stdin.read()))" | sed 's/^/D/'

There is probably a Perl module as well .

[Moe]

@all "just" create a read only key and take the first 32 bits. Change the first character to an F and there you have your encrypted key for that specific share.

[iswrong]

@all "just" create a read only key and take the first 32 bits. Change the first character to an F and there you have your encrypted key for that specific share.

 

That shouldn't work. If you have an encrypted read-only node, the read-only key is longer. From the spec:

 

Note that there is one exception: an encrypted-read-only secret is nearly twice as long (65 symbols), its body consisting of 2 keys - Data access key and Data encryption / decryption key, each of 20 bytes Base32 encoded value.

 

http://sync-help.bittorrent.com/customer/portal/articles/1628254-key-structure-and-flow

 

Such a key is only generated when the read-write key starts with a 'D', which is what this topic is about. When you do what you suggest, you just get a share with no peers (because the keys don't match up).

 

---

 

So, the procedure is, create an 'A' key (read-write) and re-add it, changing the initial 'A' with an 'D'. Or using a command such as the one that I posted to generate a 'D' key directly. After that, the interface will show the correct (double-length) read-only key and even the encrypted read-only key.

 

(I thing you looked at an existing share which already had the encrypted read-only secrets, and copied/trimmed the read-only key from there. Try it with a new share which has an 'A' key.)

[Moe]

I think you misunderstood my post

 

The way the encrypted key is created is basically "just" the first 33 bits of the read only key and that the first character is a F.

 

It is NOT a read only key - since it starts with F it is a normal encrypted key for that share.

This procedure that I describe is known to work. (See this post)

 

This way it is easy for scripts. You have the API create a share with keys not links and then take the read only key and modify it according to my description or the post I have linked and you then have the proper encrypted key for that share.

 

This also works for already existing folders, for example if you want to add one device to that share but you don't know the encrypted secret.

[iswrong]

The way the encrypted key is created is basically "just" the first 33 bits of the read only key and that the first character is a F.

[...]

 

I know that it's the first 33 characters (!) (not bits, the keys are log2(32) * 32 = 160 bits).

 

This also works for already existing folders, for example if you want to add one device to that share but you don't know the encrypted secret.

 

Yes, but you always know it, since current versions of BTSync list it (Preferences for the relevant share -> View keys, and it's there). No need to count the 33 characters anymore or using 'head -c' or whatever . (Of course, only when you use a 'D' or 'E' key.) If you do this programmatically, of course, then just taking the first base32-encoded characters of the read-only key is the most sensible approach (but ensure that you created a 'D' key, or you are just distributing the read-only key.)