[BTSync uses AES128 in CTR mode, which is good (was: Bittorrent Sync is using 128-bit AES in ECB mode!)]

We do use AES-128 in 1.1.x. Protocol has changed since version 1.0.x. AES-256 was removed from user guide PDF, but not from Technology section on site. We will update site shortly. You may find a lot of discussions AES-128 vs. AES-256 in Internet (including related keys attack). We believe AES-128 is not weak at all and it's a good choice for session encryption today. Also it's ~30-40% faster, which is critical for low end CPUs and mobile devices.

Thank you, thats indeed what I think of.

[BTSync uses AES128 in CTR mode, which is good (was: Bittorrent Sync is using 128-bit AES in ECB mode!)]

Okay, so under really really specific circumstances (an attacker has two keys that are mathematically related and they know the plaintext behind both of them) AES256 might be less secure, and is still not breakable in a reasonable amount of time. In absolutely EVERY other case, AES256 is leaps and bounds ahead of AES128 in terms of security. Also the "you always have to think that all requirements are fulfilled" quip only goes so far - it really does not apply for this.

Have you read this paper?

http://eprint.iacr.org/2009/374.pdf

The attacks on 256bit show only the potential that 256bit attacks have. So, it is much more probably that tomorrow 256bit than 128bit keys are broken. Have a look at

https://www.schneier.com/blog/archives/2009/07/another_new_aes.html

And still 128bit is soooooo secure. There is no reason to not use 128bit, or?

[BTSync uses AES128 in CTR mode, which is good (was: Bittorrent Sync is using 128-bit AES in ECB mode!)]

I have information that shows me that Bittorrent Sync is instead, actually (potentially) using 128-bit AES encryption. Whilst this may not be insecure, it shows (provided there isn't something beyond the story) that the Sync team is either not being truthful about the security, or there is a disconnect.

Not being truthful about security? Ok, what is more secure than? 128bit or 256bit? No, you are wrong, it is 128bit.

I do not know why all crypto tutorials suggest 256bit as the preferred key length when there has been proven that more attacks are possible against 256bit than 128bit. If all requirements for all attacks are given (see "related key attacks", 128bit keys are much much stronger than 256bit. And in crypto, you always have to think that all requirements are fulfilled.

So, to summarize, if the team has implemented 128bit keys instead of 256bit, I would call them "truthful about security". However, both are "secure" in the sense that nobody could ever ("ever" in x years) break them.

About the ECB part, yes that would be an issue . But seriously, I do not really believe that they have implemented that. Some developer has to talk to us (or give us the source code).

[Latest Sync Build: 1.1.70]

With 1.1.42 on FreeBSD AMD 64bits

btsync> ./btsync --config btsync.conf --nodaemon

terminate called after throwing an instance of 'std::length_error'

what(): basic_string::assign

Abort (core dumped)

ls -lh

1.8M btsync.core

Did you try the daemon-mode? It works fine here.

[Latest Sync Build: 1.1.70]

+1 for .SyncArchive from me as well.

Also, there is still no rename detection, so I can rename a file on A and what happens is that the file will be resynced to B (new copy with new name + move older file to trash). There is no need to as you have the hashes.

And there is still no FreeBSD instant syncing support. That makes it pretty useless in a Dropbox-like sense. Currently I can achieve the same results of Bittorrent Sync with Unison in a cron job + I get rename support and the source code. So please fix that, because it is pretty annoying when you have e.g. a server with a high rescan_interval because your drives want to sleep and btsync does not sync because it does not know it has to sync. And I'm not talking about the desktop...

Keep up the good work.

[Shell script I wrote to update btsync on linux/unix]

Did that ever happen to you ? But ps tells you if it's a zombie or not. You can check it if you want it, but I doubt that it will be neccessary.

[Shell script I wrote to update btsync on linux/unix]

Personally I would not hard code a possible maximum time that depends on your system and especially on your system load. Make an endless loop with a sleep inside and check whether btsync has been shutdown or not. For example you can check the amount of 'btsync' in the process table:

ps aux | grep btsync | wc -l

If thats =1 btsync has been shutdown.

[Instant syncing on FreeBSD]

What is the current status of implementing instant syncing in FreeBSD?

[Shell script I wrote to update btsync on linux/unix]

Just a side not: Is there a reason why you use key code 9 instead of the default one? This is not a smooth shutdown and in my cases btsync wants to reindex the whole collection after another restart which can be quite time-consuming. I would just consider "killall btsync".

[Latest Sync Build: 1.1.70]

Build 1.1.30 on FreeBSD AMD 64 worked without problems but with build 1.1.33

./btsync --config btsync.conf --nodaemon

/libexec/ld-elf.so.1: /usr/home/yield/btsync/btsync: Undefined symbol "posix_fallocate"

strange, it works fine here on FreeBSD AMD64 though i am not using the nodaemon mode.

[recent FreeBSD client]

Do you have the link to one of the older builds? Then just replace the version in the URL and then you will get to the latest Snapshot 1.1.27 including FreeBSD versions. Sry, but I could not find the old URL now.

edit:

Here it is:

http://syncapp.bittorrent.com/1.1.27/

[Latest Sync Build: 1.1.70]

I really dont get how I can update from 1.1.26 to 1.1.27. I am using the FreeBSD 32bit and 64bit version and both still say 1.1.26 (up to date). I restarted the one client and let the other wait over night, but there is no notification or whatsoever.

[Folders Not Properly Syncing Across Multiple Computers]

@GreatMarko

What do you mean by 'the system time is the same on all your devices'. I guess still if you use NTP to synch your time over network, there is a delta between different systems (in the range of milliseconds, or a second). In the beginning, do you synch a reference time? Because Im having the same problem: I share VirtualBox images and I had modified these and now they are broken, because btsync tried to synch chunks of it it shouldnt do, I dont know.

[Quick questions: atime needed?]

Does btsync rely on the atime property of a filesystem? So do I need to turn atime on?

[Instant syncing on FreeBSD]

I guess you are using inotify for linux. Maybe you want to take a look at devel/inotify:

http://www.freshports.org/devel/libinotify

which is a inotify-compatible library based on kqueue/kevent. If you want to use kqueue/kevent directy, you may want to have a look at the man-page:

http://www.freebsd.org/cgi/man.cgi?query=kqueue&sektion=2

[Instant syncing on FreeBSD]

I thought thats what kqueue is for? And its there since FreeBSD 4.1.

[Instant syncing on FreeBSD]

Hey!

I would like to know if you are planning instant syncing on FreeBSD (and Mac I guess). Currently I have to wait rescan_time before changes get committed. However, it would be possible to implement event scanning by kqueue I guess. Is this right and what are your plans?

In regards,

Stephan

[Source code control metadata shouldn't sync by default]

I would also like to ignore .git folders. But how can I ignore them in each subfolder? I often have this scenario where I have A/B/C/D/.git and not A/.git.

I mean */*/*/*/.git is oviously not the best solution as it might be that I create another subfolder E in D.

[password generator]

Same issue here on FreeBSD 64bit.

[moving files or folders -> uploaded again]

Same problem here on FreeBSD. Pretty annoying and I hope they will fix it soon. Currently I cannot reorganize my collection, because too much data gets transferred.