No Encrypted Secret on Existing Folder Secrets

[PeterVerhees]

The Encrypted Secret seems to be only generated when not specifying an existing secret.

For example:

 

No existing secret:

Api call:http://servername:port/api?method=get_secrets&type=encryptionApi output:{"encryption": "FCE6ZBKXODMDR5XON6I7QRSFGU3BEI24E","read_only": "ECE6ZBKXODMDR5XON6I7QRSFGU3BEI24EJVQGY6GK7T4YGM6UGB3RQCGHDQ","read_write": "DLQGN57I6UCYFR3SJD3PHYRYY5TOCMLVN"}

Existing secret

Api call:http://servername:port/api?method=get_secrets&secret=A3BJWM2TUJ6EB7YQS75JOUPHJBDOT6PQU&type=encryptionApi output:{"read_only": "BJMBVSDSJOTDQX47BKM5MEIC2B5N77FAA","read_write": "A3BJWM2TUJ6EB7YQS75JOUPHJBDOT6PQU"}

Is this expected behaviour? The documentation does not state this explicitly.

And, can encryption secrets be generated with custom generated secrets in base64? I.e., Longer secrets?

[voz]

Have the same experience. I would expect to be able to get an encryption secret by providing an existing secret. Or are we missing something?

[nils]

If you look closely, the secret's first default character changed from Axxxxx (RW) and Bxxxx (RO) to Dxxxx (RW), Exxxx (RO) and Fxxxx (ENC), which means they are generated with a new function internally. In short, you can only enable encryption with new secrets. I also think this is a step backwards in making it impossible to create your own ENC nodes with a user supplied secret.

[PeterVerhees]

If you look closely, the secret's first default character changed from Axxxxx (RW) and Bxxxx (RO) to Dxxxx (RW), Exxxx (RO) and Fxxxx (ENC), which means they are generated with a new function internally. In short, you can only enable encryption with new secrets. I also think this is a step backwards in making it impossible to create your own ENC nodes with a user supplied secret.

 

This would mean that with newly generated keys it should work. However, when you generate a fresh new key in the GUI you get a A one and when you afterwards try to derive a encryption key from it, it also fails. This is weird, you should think the key generation functions would be the same in both situations. It also conflict with the API documentation as far as I know, since providing a key (secret) is mandatory.

 

 

From api Documentation...

• secret (required) - must specify folder secret

 

Are the starting characters documented somewhere or are they a deduction from generating a lot of keys?

 

I personally think that when generating encryption keys via the API you get layered encryption. Both used when in transfer and one for storage and that why the keys are different. But this is highly speculative!  ;-)

[PeterVerhees]

When testing I found that these api requests:

/api?method=get_secrets&secret=DJj98eY2XqsVf83RpiDU0SuAzVZcPatsjJ2KsxkTDl5em2hMsxPqx&type=encryption/api?method=get_secrets&secret=DJj98eY2XqsVf83RpiDU0SuAzVZPatsJ2KxkTDl5e2hMsxPqx&type=encryption/api?method=get_secrets&secret=DJj98eY2XqsVf83RpiD0SuAzZPatsJKxTDl5e2hMsxPqx&type=encryption/api?method=get_secrets&secret=DJj98eY2XqsVf83RpiD0SuAzatsJKTDl5ehMsxPqx&type=encryption/api?method=get_secrets&secret=DJj98eY2XqsVf83Rpi0uAzatsKTl5xPqx&type=encryption

crash the btsync process. It is repeatable. Btsync 1.2.68, glibc23_i386.

 

I will be testing some more to see if keylength is a variable in accepting keys to generate Encryptiontypes.

Edited November 7, 2013 by PeterVerhees

[nils]

Are the starting characters documented somewhere or are they a deduction from generating a lot of keys?

Deduction from generating keys with BTsync itself and also some comments seen on the forum.

 

The GUI does not create keys with ENC support, therefore the A and B secrets. The API is the only way to create shares with ENC capability for the time being.

 

From a business point of view it also makes sense, because this could be an enterprise feature, as API keys are needed to activate it.

[dogsbody]

I also think this is a step backwards in making it impossible to create your own ENC nodes with a user supplied secret.

 

Agreed, all my shares have user supplied secrets which instantly stops us from using this feature :-/

[sergey@bt]

Secrets with support of encrypted peers have some performance penalty. On low-end CPUs (NAS or mobile devices), it may increase file indexing time by 2-3 times. This is the main reason why they are not enabled by default when generating new secret from UI.

 

There should be no significant performance degradation on modern desktop CPUs with hardware AES support.

[avladev]

There are mistakes in the documentation about this feature:
1. secret parameter is not required
2. type=encrypted should be type=encryption
 

secret (required) - must specify folder secrettype (optional) - if type=encrypted, generate secret with support of encrypted peer

[Quinist]

Agreed, all my shares have user supplied secrets which instantly stops us from using this feature :-/

 

I second this. I was really excited about the encrypted peer feature, but this is a deal breaker.

 

To sum this up from my enduser perspective (I planned to use a VPS as an encrypted peer for somewhat secure cloud storage), please correct me if I am wrong: 

 

• Unlike with other secrets is not and will never be possible to simply derive an encrypted peer secret from a custom, self generated base 64 RW secret.

   

• The only way to make use of the encrypted peer feature is to generate a brand new share using the "api?method=get_secrets&type=encryption" call, note down the three (RO/RW/ENC) secrets and use those for the peers accordingly.

[dms2013]

 

I second this. I was really excited about the encrypted peer feature, but this is a deal breaker.

 

To sum this up from my enduser perspective (I planned to use a VPS as an encrypted peer for somewhat secure cloud storage), please correct me if I am wrong: 

 

• Unlike with other secrets is not and will never be possible to simply derive an encrypted peer secret from a custom, self generated base 64 RW secret.

   

• The only way to make use of the encrypted peer feature is to generate a brand new share using the "api?method=get_secrets&type=encryption" call, note down the three (RO/RW/ENC) secrets and use those for the peers accordingly.

 

You can have the API on your VPS. Let the client generate a key them self. Easy as pie!

[PeterVerhees]

You can have the API on your VPS. Let the client generate a key them self. Easy as pie!

 

1. Generating the keys on your insecure VPS renders all possible security void!

 

2. Using your own (longer, complexer, with more entropy, spacenoisegeneratedsatteliteNSAproof) key avoids using the standard, remotely possible unsafe, method of btsync.

[dms2013]

You can have it run over HTTPS without logs.

If it's too sensitive. Have the client configuration somewhere you consider safe. The keys will work no matter where they are generated.

 

I believe that the amount of possible combinations the standard key has, will outlive any media holding the data.

 

And after that. They still need to download all the data. And you can keep logs of that..

 

You could store data in Truecrypt containers?

[PeterVerhees]

Yes, there are several options to use, all with different pro's and con's, I've explored them all extensively in previous posts in the general section of the Sync forums. You can look them up if you like, but they are quite a long read.

 

Among them a discussion on Entropy, keylenght and statistics and why I'd like a slightly larger key. I'm just a bit disappointed this function has such a limitation in the API.

 

When the key generation methods are explained, maybe I could write my own code to generate longer keys.

 

Can anyone from the staff confirm or deny that using your own keys in the future will be possible? That would put this thread, which is almost certainly going to end in another discussion on statistics or a repeat of old subjects (all well intended, no doubt), to an end.

 

Or can the key derivation be explained so we get more insight into this to try to create our own keys?

 

[Quinist]

 

I believe that the amount of possible combinations the standard key has, will outlive any media holding the data.

 

You could store data in Truecrypt contain

 

Oh please, just like 1024 bit PGP keys were "unbreakable in the foreseeable future", back in 2001. Or how 640 kB ought to be enough for everybody.

 

You could store data in Truecrypt containers?

 

Yes, and at that point I would lose mobile access and I could also store the data on other untrusted servers like Dropbox and the many other options.

 

Don’t get me wrong, I’m not planning to save any highly sensitive data via Bittorrent Sync, but I still don’t want random people to go through my family pictures and random documents with almost no effort sometime in the future.

 

An encrypted peer under my control with a long, self-generated secret seemed like the perfect tradeoff between security and convenience for me, but on a second thought, maybe I am stupid for trusting such a tight-lipped closed-source program with security/privacy sensitive features in the first place.

[dms2013]

Great examples. Do you have any other?