PeterVerhees

Members
  • Posts

    56
  • Joined

  • Last visited

  • Days Won

    5

Posts posted by PeterVerhees

  1. Did the math too, it's fairly simple.

    Considering a truly random entropy with random bytes (these are not only letters and numbers you can type!), the optimal keylenght to support the 256bits AES encryption, without overdoing it, is actually 32 bytes. A simple 256 divided by 8 gives you this.

    When considering that bittorrent sync uses truly random bytes in their implementation (/dev/urandom) , this matches the perfectly with the AES 256 bits encryption used. (Not debating whether random functions are truly random, lets assume they are... http://www.random.org/)

    Therefore, it is unnecessary to provide extra key length. It is nice that btsync supports lengthier keys, but for the sake of the encryption it is not necessary. It might give you piece of mind....

    Re-using a part of the key (without adding length) for a date or computer-name actually makes the key LESS unique and thus more guessable for others. (Counter intuitive I know, but thats the truth....).

    Adding computer-name or date to the length of the 32 byte key makes it MORE unique, but adds no security, due to the length of the key surpassing the entropy of the encryption used.

    See my previous posts about when to attack the key and attack the algorithm.

    I myself am more than happy with the solution provided.

    Generate your own key like this on Linux.

    dd if=/dev/urandom bs=32 count=1 | base64

    Change the bs value for lengthier keys...

    (Edited, multiple embarrasing typos)

  2. Hi I'm having issues running btsync on a powerpc based synology NAS. Its the ds511+. Its missing the required libraries see this when I run it any ideas ?

    ./btsync: /lib/libresolv.so.2: version `GLIBC_2.9' not found (required by ./btsync)

    ./btsync: /lib/libc.so.6: version `GLIBC_2.4' not found (required by ./btsync)

    running ipkg install glib did not work. Let me know thanks.

    The standard build of btsync uses a newser version of libc. The fellows at bittorrent have to create a special build for Synology which uses an older version without inotify support. These builds are available for i386 and x64 but not "yet?" for powerpc and other platforms.

    (just a second too late. ;-) )

  3. Dear Bittorrent,

    After digging around in some wireshark logs of my btsync setup I found that btsync calls home to a server named: www.usyncapp.com.

    I believe this is to gather statistics on which version is running where on what platform and so on. Especially important during the testing period I guess. Is the software still going to be doing this when it is final? And what info are you saving for how long and what purposes?

    /nosy

    Educated Guess:

    Architecture,

    Number of Files

    Numer of shared folders

    A unique ID

    What options are used.

    This is the URI I found. (some info scambled)

    http://www.usyncapp.com/cfu.php?arch=x86_64&cl=BitTorrent%20Sync&direct=432129821&files=3567&folders=9&id=htRWdGwwER-daEraerE&pl=linux&relay=0&size=345675432&v=221122

  4. There is a nice workaround already called EncFS which I personally use to great length to store data elsewhere (even on USB disks or sticks I personally own) and is usable on all platforms.

    But this is cumbersome, just as cumbersome as zipping, rarring or tarring files to preserve file attributes or metadata before putting them on BTSync. It would be nice to have this functionality in one package so it is transparent to the "end-user". Using archiving defeats the "live sync" functionality.

    Thanks for your interest thought and your offer to help.

    Use case:

    My bother has a newborn and took pictures of the birth. Really close-up personal, not to be published anywhere, but for him and his wife VERY important pictures. If you catch my drift...

    I am more than willing to store them on my NAS (which gets backupped to a second NAS with de-duplication AND versioning) which provides piece of mind he himself can never achieve. He is not techsavvy.

    However... I can fully understand that while he trusts me not to open the pictures and me telling him I have NO interest in them AT ALL, he still would like the assurance of "end-user" controlled encryption to block me from seeing this at all. Not being a techperson himself, it would be nice if the software support it.

    I hope this clarifies things a bit, I can be a bit fuzzy when trying to explain. unsure.png English is not my native language...

  5. What you essentially want is a backup solution.....

    ....half-assed product with 100 features.

    No, I am not seeking a backup solution. I just want to share my bandwidth and storage so my family does not have to leave their computer on at all times if I already am leaving my NAS on. (Sync to phone and or laptop etc etc...)

    Furthermore, BTSync is such a beautiful product just BECAUSE it syncs live data and not provide a backup only solution. I do not want to store my data anywhere but at home. My family trusts me more that any other third party (at least they have not led me to believe otherwise smile.png). It's just that when files get synced to my storage I have plausible deniability when I cannot access the files due to encryption.

    And hey, it was just something I thought about as a "nice to have" and in my case this specific nice to have is more important than HFS or HFS+ resource stuph or finder labels since I do not use those.

    You reason from your point of view as I do from mine, but calling it "half-assed" because of someone liking/wanting some functionality is a bit strong, don't you think? huh.png

    Edited: because I did not read the Crashplan line thoroughly...

  6. I realize this is beyond the scope of filesyncing, however, encryption at the sending end is not always feasible (phones for example). My proposition is merely to feel what others might think and tank you for your view.

    I do not write the software and have no idea how it works, but one thought I have is that the before an incoming file get written to disk, the decryption get circumvented or bypassed. Again, I have NO idea of the feasibility of this.

    Encryption at the receiving untrusted end (with other software like truecrypt for example), still implies the receiving end can encrypt en decrypt it, that is not what one might wish.

    As for myself, in such a situation I am more than happy to use EncFS of something similar, just putting up the idea for the masses.

    Maybe the secret key system lends itself easily for this.

  7. Disclaimer: Could not find something similar as a request, however, I've also put not much effort in searching the forums exhaustively.

    Example:

    I've got plenty of disk space and plenty of network bandwidth and am willing to share this with my family. So I'd like to provide them with a btsync solution. However, since we in our family are all bordering to clinical paranoia ^_^, my brother does not want to store his files in clear text form on my storage AND I do not want to be able to read them. (Hell knows what he is putting on MY disks, I really am not interested in his weird fairytale fetish :blink:)

    Is it possible to have a new type of secret which allows me to sync the files for him but store them in an encrypted way?

    This would also be interesting for people who have some rack-space or server somewhere and want to utilize the space without running the risk of getting their private data compromised when for some reason the machine (virtual or not) falls in the wrong hands. (yes this could be accomplished with another form of disk encryption)

    Anyone second this option?

    PS: Check this related topic too: Quota Support

  8. For me personally this would suck. ;-)

    I have multiple users on my linux machine, logged on at the same time, sharing the same secret.

    (I know, I could handle this differently, but this is the easiest way).

    As a linux user, it is all scripted so they will not interfere with eachother.

    So if one wants to prevent multiple instances, then please use the pid file and not the processname. This way accidental executions will be prevented but intentional ones do not.

  9. Weird thing is: My ds1010+ (i386) also has the same old glibc as this PowerPC one (ds508). However the Synology build runs like a charm on the ds1010+. Isn't this just a matter of crosscompiling the source from the synology build for PowerPC?

    I say this because I think it might interest you, I am not planning on running SyncApp on the PowerPC Synology... just testing it for you.

  10. PowerPC Quoriq? SyncApp supports it.

    It gives me the:

    ./SyncApp_ppc_quoriq: /lib/libc.so.6: version `GLIBC_2.4' not found (required by ./SyncApp_ppc_quoriq)

    error.

    So not for Synology. ;-)

    Granted, these are the older models of Synology, but still in use in great numbers I expect.

  11. Running syncapp on Synology DS1010+. SyncApp 1.0.92.

    Again running into to GLIBC_2.4 error. The binary is dynamically linked. Can you please create a statically linked binary? It is larger, but it should work on this system. (And other Synology systems). I think this is a rather big chunk of hosts this is going to be run on.

    Forcibly tricking the system with Ermine works, but is really really nasty.

    http://www.magicermi...m/products.html

    If you want to test a statically compiled binary, please PM me. I will be MORE than happy to serve as a tester on this issue.

    (Some random link: http://stackoverflow...c-linking-glibc)

    PS> Cannot create a debuglog, since the application is not starting.

  12. Then again,

    When the length of the key is way longer than the amount of bits used by the form of encryption, you gain nothing.

    Example:

    When we use a 256 bits encryption without any form of block cipher-based mode of chaining (which is VERY unlikely, but for the purpose of the example necessary because it makes attacking the cypher much more difficult) you could use a 4096 bits key to encrypt. However, this results only in a 256 bits encryption with no further protection than these 256 bits, which has way LESS unique combinations than the 4096 bits key used.

    So what I really want to know is, what kind of underlying encryption scheme is used to cypher the data, because this wil determine the largest key I can use to generate the most effect.

    Not quite correct but a somewhat general rule of thumb:

    When the key is shorter than the bits used to encrypt: attack the key.

    When the key is longer than the bits used to encrypt: attack the cypher.

    This is in no way to say that for me personally the use of a secret key is inadequate or that it is unsafe or easily guessable.

    And furthermore, 256 bits AES encryption with some form of block cipher-based mode is more than adequate for military applications, let alone syncapp cloud syncing.

    (However if the 'encryption' is ROT13 then I'll pass :) )

  13. Is it possible to add an option to let all traffic be routed through a proxy server (Socks5 for instance).
    This way is it possible to route and mask all traffic through a tunnel when the network is bit-torrent unfriendly. (Hence, at work)

    I myself would like to use a SSH tunnel for this, but it can be anything.

    (
    Using tsocks does not route the bit-torrent traffic though the tunnel weirdly enough
    http://tsocks.source...e.net/about.php
    )

  14. In your "Shared Folders" tab, right-click .....

    Sorry, I only use Linux as my OS. ;-)

    No such option in the WebUI for Linux. In the config file however I found this....


    "use_relay_server" : false,
    "use_dht" : true,

    When using shared folders in the config file, it disables the Webinterface completely.

    Thank you for the anwser though. I feel a bit of a nitwit as I dug through the config file before and completely missed it.

  15. They should totally implement a two-step verification process like the Google Authenticator

    Please no! Not another service/application depending on Google knowing what we do and when with whom and where. I LOVE the simplicity of the shared secret. (maybe certificate based sharing is a nice upgrade).

    By the way, is there a way to prevent Syncapp to even connect to the bittorrent servers?

    /paranoia mode ;-)

  16. Synology DS1010+ Not OK. (DSM 4.2 Beta)

    Synology DS508 Not OK. (DSM 4.0 - Latest)

    Also Libc Issues.

    I can test with a statically compiled version of SyncApp if you want. I believe this will circumvent the libc problems altogether, howevery I'm not sure about that.

    I've also looked into the possibility of upgrading my libc on the synology. Luckily it was my test system, things broke beyond repair. Had to reinstall.

  17. Update:

    I managed to start the application after using http://www.magicermine.com/ to create a independent file to run. However this sucks for many reasons. Least of all a 30 day trail. ;-)

    Statifier also created a usable independent file, however, this would only run after I turned VDSO (Virtual Dynamic Shared Object) and stack randomization off on my Synology. Which I rather not do for obvious reasons. (see: http://en.wikipedia.org/wiki/Address_space_layout_randomization)

    This is all with the i386 binairy, I have not even started on the PowerPC one and do no even know if this is possible.

    The aplha testing is quite the challenge it seems, having fun over here. ;-)