sts

Members
  • Content Count

    20
  • Joined

  • Last visited

  • Days Won

    1

About sts

  • Rank
    Member
  1. 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?
  2. 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).
  3. Did you try the daemon-mode? It works fine here.
  4. +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.
  5. 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.
  6. 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.
  7. What is the current status of implementing instant syncing in FreeBSD?
  8. 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".
  9. strange, it works fine here on FreeBSD AMD64 though i am not using the nodaemon mode.
  10. 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/
  11. 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.
  12. @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.
  13. Does btsync rely on the atime property of a filesystem? So do I need to turn atime on?
  14. 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