lolcat

Generate Encrypted Read-Only Secret Without Api Key

Recommended Posts

Is there any way I can generate encrypted read-only secrets without having an API key? Would anyone consider packaging an executable that would allow me to create them?

Share this post


Link to post
Share on other sites

You can go to http://www.usesync.com -- get a sync space, and use the encryption-secret.

 

You don't need an API key as our server has one. Our server will also become a peer for that folder to help you sync.

 

Just make sure you add an email to the sync, otherwise syncing will stop after some days.

 

Feedback would be appreciated.

 

Omid 

Share this post


Link to post
Share on other sites

You can go to http://www.usesync.com -- get a sync space, and use the encryption-secret.

 

You don't need an API key as our server has one. Our server will also become a peer for that folder to help you sync.

 

Just make sure you add an email to the sync, otherwise syncing will stop after some days.

 

Feedback would be appreciated.

 

Omid 

Appart from the obvious issues with letting a third party generate my encryption keys it would be completly unacceptable to send it in plaintext. Then I may as well send my files to dropbox, with the secrets sent in plaintext anyone could intercept and decrypt my files.

Share this post


Link to post
Share on other sites
You can generate encrypted read-only secrets using the normal btsync client without any API key.

 

 Do the normal "Add a Sync Folder",

 click "Generate", but change the first letter of the "Folder sercet" from "A" to "D",

 set the "Folder to sync", click "OK",

 right click on that folder from the list,

 click "Show Folder Preferences",

 copy the "Read only secret",

 paste it into Notepad(or other text editor),

 change the first letter from a "E" to "F"

 "Encrypted Read-Only Secret" is the first 33 char of that string.

 

 like this

 

 EEFVEEEUQXH6EAIHUN5RGTU2WYCGRYMRVEJUTSYEXT3XMA4FLKFF6BXSS4E  <--- "Read only secret"

 FEFVEEEUQXH6EAIHUN5RGTU2WYCGRY <--- "Encrypted Read-Only Secret"

Share this post


Link to post
Share on other sites




Updated Instruction

==================

 

You can generate encrypted read-only secrets using the normal btsync client without any API key.

 

Do the normal "Add a Sync Folder",

click "Generate", but change the first letter of the "Folder sercet" from "A" to "D" (see 1 and 2),

set the "Folder to sync", click "OK",

right click on that folder from the list,

click "Show Folder Preferences",

copy the "Read only secret" (see 3),

paste it into Notepad(or other text editor),

"Encrypted Read-Only Secret" is the first 33 char of that string with the first letter changed from a "E" to "F" (see 3 and 4)

 

real example this time.

 

1) AR7GC6JIVCTKG2XNPM7GGOSV3FI5BDDNH

 

2) DR7GC6JIVCTKG2XNPM7GGOSV3FI5BDDNH

 

3) EYF7Y3OOYZEZALVLFDQDAARXQTV2HO7IZCO2V2ZRZEAN32VY7RFH7HGOKRI

 

4) FYF7Y3OOYZEZALVLFDQDAARXQTV2HO7IZ

 

 

Important

=========

You can not have same folder more then once per machine even if it is in a different mode(RW,RO,encrypted).

Try the "Secret" on an other machine or remove the RW folder from the machine before you try to add the "Secret" or you will get an error "Selected folder is already added to BitTorrent Sync."

 

 

Fun Fact

========

RW Secret can be "A" or "D" followed by any 32 character from upper case A to Z and numbers 234567.

 

So this works

 

DABCDEFGHIJKLMNOPQRSTUVWXYZ234567

EYRCW2XHXF3NRDT4Z44CL45Y5ZH2HO6ADW33KXUGY4EZN4B5RQDELP7IQQE

FYRCW2XHXF3NRDT4Z44CL45Y5ZH2HO6AD

 

 

Hope this helps

 




Edited by Red Diode

Share this post


Link to post
Share on other sites

Hi all,

 

Couple of comments on @Red Diode instructions. 

The Encrypted nodes functionality is implemented in code and therefore is working. There is no UI for it now, so it can be accessed either via modifying Secret's prefix (as in instruction above) or via API. Note, that adding even a single encryption RW or RO key increases CPU load significantly as BTSync has to calculate also hash for all the files in the folder when they are encrypted.

 

While this load can be handled by modern i386/x64 CPUs due to hardware encryption ability, it can be extremely hard for ARM, PPC and other CPUs for low-power platforms. So I strongly do not recommend using encryption keys if any mobile / embedded platform is involved, only for desktop / server PCs.

 

The encrypted read-only Secret is very long as it consists of 2 parts: the access Secret (first 33 letters including the 1 symbol prefix) and the decryption key. So, by taking the first part only and putting the "F" prefix you indicate peer that the folder is going to contain encrypted files and peer will have only access key without ability to decrypt (as it physically does not contain decryption key). So it is safe from security POV.

 

Putting the whole long key (when adding new folder) starting with "E" will make a read-only node, which decrypts files.

 

Again, use with care due to high CPU load.

Share this post


Link to post
Share on other sites

Now a few questions. In the above:

 

2) DR7GC6JIVCTKG2XNPM7GGOSV3FI5BDDNH
 
3) EYF7Y3OOYZEZALVLFDQDAARXQTV2HO7IZCO2V2ZRZEAN32VY7RFH7HGOKRI
 
4) FYF7Y3OOYZEZALVLFDQDAARXQTV2HO7IZ
 
Can all three of these secrets be used usefully at the same time on different machines:
 
Does #2 still work for normal client sync?
 
Does #3 still work for Read Only sync?
 
And if Machine A is using #2 and Machine B is using #3, can Machine C use #4.

Share this post


Link to post
Share on other sites

#2 is Read-write secret with encryption. It behaves completely as usual secret, but Sync will also calculate encrypted hash tree, so encrypted nodes can connect to such folder.

#3 is a read-only secret with decryption. It will work exactly as regular read-only peer, but can connect to encrypting peer with secret in #2.

#4 is read-only-encrypted secret. Peer with such secret can receive files. store them on disk but can't decrypt them and show their content.

 

#2 and #3 are loading CPU more due to necessity to encrypt / decrypt data.

Share this post


Link to post
Share on other sites
Guest proactiveservices

Thanks for this guide and to RomanZ for the admin input. One question I have is that, understanding the software is beta, is there a practical reason that the encrypted peers GUI hasn't been written yet? Is it to prevent the masses using it for the moment or just because the team hasn't gotten round to it?

 

Are there any caveats that users of the encrypted peer feature should be aware of, other than CPU load and possible path length problems?

Share this post


Link to post
Share on other sites

proactiveservices

 

The main caveats for user (average user, not very tech savvy) are:

1) complexity of usage (more kinds of secrets are confusing)

2) deadly CPU usage of mobile devices due to lack of hardware encryption.

Share this post


Link to post
Share on other sites
Guest proactiveservices

I knocked together a Windows batch script to make the read-only encrypted peer secret a bit easier to find. Saves counting to 33 lots of times! If anyone would like to contribute similar code for other platforms, please PM me.

 

Not-so-secret: BNIS6FYN5YH4SXYM5V45QAF37VSGU3VTE

Share this post


Link to post
Share on other sites

I decided to be the guinea pig and tested this. The directions posted by Red Diode work.

 

Now I have an unencrypted folder (RW) on my local device, a Win PC. It's synced with an encrypted folder (RO) on a remote Linux VPS. I made edits on the PC and the encrypted version was instantly updated on the VPS.

 

Now for the questions:

 

(1) I am pleased that the VPS host can't see the files stored on their server. However, neither can I. Let's say my PC was lost, and I wanted to recover and decrypt the files. How would I do this?

 

(2) Since the remote VPS is "always on", I would want it to be the device in my mesh that propagates syncs to multiple users on their devices 24x7. Won't they be receiving an encrypted version? How would one set up the BTSync mesh so that all users see the unencrypted files EXCEPT for the VPS?

 

Thanks.

Share this post


Link to post
Share on other sites

I decided to be the guinea pig and tested this. The directions posted by Red Diode work.

 

Now I have an unencrypted folder (RW) on my local device, a Win PC. It's synced with an encrypted folder (RO) on a remote Linux VPS. I made edits on the PC and the encrypted version was instantly updated on the VPS.

 

Now for the questions:

 

(1) I am pleased that the VPS host can't see the files stored on their server. However, neither can I. Let's say my PC was lost, and I wanted to recover and decrypt the files. How would I do this?

 

(2) Since the remote VPS is "always on", I would want it to be the device in my mesh that propagates syncs to multiple users on their devices 24x7. Won't they be receiving an encrypted version? How would one set up the BTSync mesh so that all users see the unencrypted files EXCEPT for the VPS?

 

Thanks.

Just to verify your comments above: the VPS is E-RO (encrypted read-only), not RO, correct?

 

Scenario (1): If you were to lose your primary PC and the only copies left are the E-RO backup all you need is the original RW secret. When you place that RW key on a new PC it will automatically download and decrypt the files from your VPS. In other words PRINT and SAVE those keys somewhere really secure. Something like a safety deposit box. 

 

Scenario (2): It sounds like you're already doing this. When you add the sync folder to the VPS make sure to use the E-RO key. Any other computers that you want to see the actual files (decrypted) should use the RO or RW regular keys. The VPS will still hold all the files, it just doesn't have the decryption key to see them. 

 

I've been doing the above with a VPS at backupsy. It runs E-RO secrets for all my important files so I can edit something on my desktop in the morning, shut it down, then pick up editing the same file from my tablet sometime later in the day. All seamlessly synced to Backupsy. 

Share this post


Link to post
Share on other sites

Just to verify your comments above: the VPS is E-RO (encrypted read-only), not RO, correct?

 

 

 

Yes. The BTSync secret on the VPS is E-RO and the local device is RW.

 

Your comments TOTALLY and THOROUGHLY answered my 2 questions. Very helpful advice about saving backup copies of all secrets; and how to recover encrypted data in an emergency. Additionally I now comprehend the concept of using the E-RO secret on the remote VPS - while utilizing RW or RO secrets on the devices that need to see the actual decrypted files. 

 

Perfect. Thank you! 

Share this post


Link to post
Share on other sites

If someone deletes an encrypted file on the machine with Encrypted RO secret, is that file deleted then on other machines?

 

So, then, what level if trust is required for someone acting as a node with ERO secrets?

Share this post


Link to post
Share on other sites

I really like this feature!

 

Can i use secrets with 32 characters?

 

I get read-only secrets starting with an "U", not an "E", when i try:

Main:

DOZBQK55N6IWUOFP2R3J3GWAACFWDVFULAPQLCIZHIZVU2XTNQSRXYEWDT7

Read Only:

Uk9OTFl9VHlPp3rohjcmMCu0ZL0MLuJLlHqWzrEQMu8zU1GLW4oyjQBq7wdstdaSYg==

While the first 33 characters with an "F" are not valid, the complete string without the last 26 (the decrytion part) is valid:

Fk9OTFl9VHlPp3rohjcmMCu0ZL0MLuJLlHqWzrEQMu

But it does not seem to work that way.

 

To which letter do I have to change the "U" that its working? Or is only the standard secret length supported so far?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now