PeterVerhees

Members
  • Posts

    56
  • Joined

  • Last visited

  • Days Won

    5

Posts posted by PeterVerhees

  1. Hi

     

    I've have a strange behaviour on my computers using debian jessie. After starting bittorrent by autostart i am not able anymore to click on the icon in the message tray. This behaviour only happens with bsync-gui while with btsync-user i am still able to click on the btsync icon

     

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

  2. 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?

     

    :rolleyes:

  3. 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.

  4. 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.

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

  6. 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?

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

    1. 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.
    2. My system needs to have Quota support enabled, which on some systems is just not possible.
    3. 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.

  8. 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.

  9. @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.

  10. 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!

  11. 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.

  12. Can anyone suggest a good program that generates strong keys locally?

    I'm looking around for pre-built AHK scripts... might play around with:

    http://www.autohotke...ring-generator/

    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

  13. Do not, do not, DO NOT use any sort of external service to create 'random' keys for you.

    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. :blink:

  14. 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!

    Coming up with secure entropy is in the same general ballpark of difficulty, and I have every expectation of myself and others to muck it up (see also: passwords that are children's or pet's names, or common words, or even 'password').

    When worried about entropy used in your random key, please take a look at http://random.org or http://www.fourmilab.ch/hotbits/

    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..... :D

  15. 3. Some kind of defining owning user and owning group on linux machines. In my case, I would like to sync data from more than one users on my linux server. Each one got it's own secret and directory, but since the BT Sync application runs as root, all files are owned by root.

    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.