PeterVerhees

I second this. Using btsync-gui under Gnome Shell seems to render the icon inactive. Either with a manual or autostart..

Hello RomanZ, Are custom secrets ever going to be supported by Bittorrent sync? I'd like to double the length of the key and use a custom entropy pool.

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?

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.

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=encryptioncrash 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.

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. 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! ;-)

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?

Removed, see: http://forum.bittorrent.com/topic/24794-no-encrypted-secret-on-existing-folder-secrets/

Removed, see: http://forum.bittorrent.com/topic/24794-no-encrypted-secret-on-existing-folder-secrets

In the advent of the coming of the Encrypted Node, see the remark of kos13 on this page, it dawned on me. I miss some form of quota support and could not find a big topic about this so I started this one. It is mentioned a few times in the wish list I believe. In the linked topic I lay out a scheme of sharing bandwidth and storage with my brother and I now see I forgot to mention my brother is also storage hungry and could easily put me out of my storage space in a matter of months. Since my realisation of this I have been fiddling around with Linux quota support to try to get some of this functionality. However this leaves me with three big problems. I need to run a separate daemon. This one runs under different credentials, with quota assigned, just to share a single folder. Opening up some more ports on my router and gobbling up more resources, which on my NAS is no problem but could be a problem on others. My system needs to have Quota support enabled, which on some systems is just not possible. There is no warning at all to the clients syncing with each other, reporting a that a node is full (has reached its quota). It is possible to script around some of these issues, fiddling with bash, perl, python and some system utilities and emailing warnings around. However, it would be much more elegant to have this in the sync application embedded. Separate from the host operating system. So I could run a single daemon to cater a few different family members. Anyone second this Idea? Please mention your thoughts below and like this post, so it gets noticed.

You can, for the moment, circumvent access to your webui by only letting the Internet connect to UDP to your btsync instances. This means NO UPNP or NAT-PMP, but manual control over the ports you forward to your host from the internet. There are tricks to get through this, but at least you have a more fine grained control. (Trick: http://code.google.com/p/udp-tcp-bridge/) It should be fixed though, suspending here too.

@Kos13 and development-team You made my day!!!! Thank you very much for your efforts!

@several posts in this thread......... Can we please stop plugging other solutions like EncFS/Truecrypt/Lukscrypt etc etc. People interested in this feature most likely have already checked those out. I myself mentioned EncFS in one of my first posts just to say I am aware of it, no more.... It keeps coming back as a solution. It's not a solution for many people and as mentioned in posts before me, not even stable on Windows. I opened this post as a feature request. Can anyone from the staff give us an answer as to whether or not this is even on the radar of the developers? As for myself, this would be an option I would gladly pay for.

The PowerPC version needs to be compiled to a lower glibc for starters. This has been done with the i368 and x_64 versions but not thw powerpc. I myself experience this on my older NAS. (ds508)

Noticed a few things. The medialibrary on the Android device is not updated. Removed pictures from a synced folder (not Camera backup) still display in the overview, but cannot be clicked on to view the larger image since the file is removed. A medialibrary update event after a deletion could prevent this. The application seems to forget it´s device name sometimes. (May be mentioned before me) Maybe put in a way to purge the .SyncTrash folder from the application. Sync speeds slow down on wifi to a mere halt when screen is turned off. But I believe this is operation system related, just mentioning it. Great to see Btsync on mobile!