• Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by PeterVerhees

  1. I second this. Using btsync-gui under Gnome Shell seems to render the icon inactive. Either with a manual or autostart..
  2. 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.
  3. 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?
  4. 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.
  5. 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.
  6. 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! ;-)
  7. 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?
  8. Removed, see:
  9. Removed, see:
  10. 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.
  11. 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: It should be fixed though, suspending here too.
  12. @Kos13 and development-team You made my day!!!! Thank you very much for your efforts!
  13. @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.
  14. 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)
  15. 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!
  16. @rdebath: Yes I've read your earlier messages. I even mentioned EncFS myself in my initial posts. But I said, and I quote: "technically in-adept people". EncFS is all fine and I use it daily on several *nix machines and even a Windozebox for cloudsyncing to the NSA/FBI/CIA PRISM storage facility and other cloud providers..., however I am *NOT* technically in-adept.
  17. Please be aware that encryption is already in the BtSync product. Only on a network level. Since in my first post I talked about technically in-adept people, it WOULD be a nice to incorporate in into the simple secret exchange that BtSync now provides. And furthermore, we are talking about file encryption, not disk encryption or container encryption here. Please bare in mind that these are truly different. For me, this still stands. It would provide me with a really great solution for helping my family.
  18. Never mind, running the GLIBC 2.3 client on my other machine (with lib32 support) opens the ports correctly.... It must me something with the Synology NAS or because it is running Transmission on this host also... Weird. Will post updates then I figure it out. ;-(
  19. This script only uses specific characters, hugely diminishing the entropy of your generated key. Use something like this (on Linux), sorry no Windows experience here... Change the 42 after the -c for lengthier keys. head -c 42 /dev/random | base64 -w 0
  20. All, It seems the UPNP function in de build for Synology NAS GLIBC 2.3 is disabled. Can anyone confirm? The same config works fine on an other "normal" linux host (Ubuntu 12.10 in this case), UPNP ports are set to open when starting it on this host. I could be overlooking something though.
  21. I stand corrected, I totally got caught up into the entropy level of the key generation and started overlooking the blatant obvious problem of someone else getting hold of my key this way. I will sit in the corner and cry a little if you don't mind. I will be back when I find my brain. OH and if someone could change the "Advanced Member" below my name to "Blithering Idiot" please? As for depleting the entropy pool and the hardware filling the pool, I still stand by what I say. The pool gets depleted quickly and randomness suffers from it. Whether or not this is really quickly exploitable is a matter of debate and implementation. cat /proc/sys/kernel/random/entropy_avail should hover around 2000 for sufficient entropy. Mine hovers between 5 and 30.
  22. As henryk pointed out in the next post, I am completely talking sh*t in this post. Please ignore this post and DO NOT FOLLOW any advise in it, apart from using more bytes in your key generation. I kid you not, I am ashamed of overlooking the facts henryk points out and am bewildered of the fact I wrote this text. It must have been far past my bedtime. You can take a LOOK at the sites I mention, because they have interesting info about entropy, but do NOT use their data! When worried about entropy used in your random key, please take a look at or I use these to generate my own key, not depending on PRNG's. See my simple, badly written, attached bash script. (it filters out / + for copy paste in mail and uses a 42 byte key, for obvious reasons) #!/bin/bash bt_bytes=42 bt_token="" while [ -z "$bt_token" ]; do bt_token=`wget -qO- "https://do-not-do-this/" | base64 -w 0 | grep -v "/" | grep -v "+"` done echo "TRNG Nuclear: "$bt_token bt_token="" while [ -z "$bt_token" ]; do bt_token=`wget -qO- "https://do-not-do-this" | base64 -w 0 | grep -v "/" | grep -v "+"` done echo "TRNG Atmospheric: "$bt_token bt_token="" while [ -z "$bt_token" ]; do bt_token=`head -c $bt_bytes /dev/urandom | base64 -w 0 | grep -v "/" | grep -v "+"` done echo "PRNG urandom: "$bt_token I am still looking into a way to combine the TRNG outputs with the PRNG output to foil any attack on my key from persons owning the sites and still keeping the true randomness. Keep you posted.....
  23. This is easily fixed by running a seperate btsync (on different ports and different .sync direcotries) for every user. Administrationwise, this is a pain, but for a few users, this works like a charm. You could script it into an init script which starts on a configurable userbase or something.
  24. I really don't know. Is the AES encryption on top of the data streams or is it on top of the data itself. It's quite a difference. Socket encryption or File (block) encryption. Only a developer could tell I guess. @Kos13, is there any take within the Bittorrent development on this?
  25. Just remembered I did not post it in this list: and (Related posts) Please reply to the discussion in the posts and not here, lets keep the wish list as clean as possible.