handle

Members
 View Profile  See their activity

  • Posts

    46

  • Joined

  • Last visited

  • Days Won

    2

 Content Type 

Everything posted by handle

  1. handle
    This however, is a good idea.
  2. handle
    You can make the exact same argument 20 more times but it's not going to make it any more correct.
  3. handle
    It will act almost exactly the same as uTorrent would with a torrent. Tough to say if uTorrent compensates for slow connections, however you should be able to set your max bandwidth.
  4. handle
    Seems cool, but bittorrent sync already uses /dev/random (or /dev/urandom, but that's also very secure) to generate secrets and so I don't really see a use for this
  5. handle
    It will work, but you'll be wasting your bandwidth. It should work, but your sync client will have to download changes every time you restart your computer.
  6. handle
    Can a mod or administrator please close this topic? I've found all of the information I wanted.
  7. handle
    In which case you are diverging off of the original argument and moving the goal fields. This was never about keys being obtained prior to you writing it down. It was about how to securely share keys. And I still stand by my opinion that it's really not Bittorrent Sync's problem. Stop using insecure email and IM altogether and you'll have no problems.
  8. handle
    It is a possibility. What happens (as far as I understand) is RW nodes send out "modification requests" to RO nodes. These requests are "signed" in a way that only RW nodes can sign them, and RO nodes can verify that these signatures are legitimate but cannot create the signatures themselves. Now, there are two possibilities beyond this that a dev would have to verify for me. If an RO node actually stores these modification requests with signatures, they can then pass them on to other RO nodes. If these requests are not stored however, they cannot tell other RO nodes to modify anything, and so they cannot propogate changes to other RO nodes.
  9. handle
    Thank you very much for your response. I am happy to see that SRP is used for authentication and Ed25519 for the protection of data in the situation of read-only keys. I feel much more confident using this tool, and await the protocol spec (and even more so, I await the release of the source code (hopefully)) Cheers
  10. handle
    No it isn't. Your entire argument is a red herring, and "truthfulness" is not "using a different cipher than is said". Luckily it appears to have just been a documentation mistake, and there is a valid reason (faster encryption for mobile devices), however your argument really does not fit into any of this.
  11. handle
    I posted proof... twice. If you actually read through the original post instead of stopping at the word "potentially" (and basing your entire argument on that) then you would have seen the screenshot I posted two times that gave me reason to believe that 128-bit AES was being used. Also it's cipher, not cypher. Cypher is a Matrix character. Your entire second argument is moot, as that is considered "security through obscurity", and arguably weakens the security of any system. Cryptography is based on the ability to open your algorithms to scrutiny from the world and still have it strong. The only thing that should ever be kept secret are keys used in a cryptosystem.
  12. handle
    Exactly. Not to mention that you could easily just share a key by writing it down on a piece of paper, then it's completely off any network.
  13. handle
    I'd argue that the router analogy is invalid. That would be more accurate if BTSync sent data unencrypted, but it does not. In fact, WPA2 works in arguably the same way as BTSync in this case - they both use pre-shared keys. You know, the part where you have to enter the wifi password to gain access to the router's network? And then at that point the communications are encrypted? Yeah. Also, the application is not built around sharing your key. There are other applications that are. BTSync is built around sharing your DATA with a pre-shared key.
  14. handle
    No, it really doesn't. Let the developers concentrate on building a secure syncing solution - use secure key transfer solutions to securely transfer keys. If they build that into bittorrent sync, that's great, but it's in no way their burden.
  15. handle
    Also, is there a reason you aren't using CryptoAPI's CTR mode and instead using a (what I assume is) homebrewed CTR mode?
  16. handle
    In order to learn the protocol, either the binary has to be reverse engineered, or one must be very lucky at guesses. I think he meant Bittorrent Sync as in the binary program. Though I might be wrong. As for the second paragraph, he doesn't seem upset - it sounds like more of a friendly warning than a "Silence, naysayers" sort of deal. Though I might be wrong on this as well.
  17. handle
    Indeed, hence why I said "allow". The "require" is only if they chose to do so. It is possible to change the directory location with a tool called mklink, however it won't accomplish much because it'll still be on your drive, and whether the path is in the symlink or the config, it'll still be easy to find.
  18. handle
    That's fair enough. You should be able to use a symlink (junction in windows) to change the directory location, however that would not accomplish anything in this case. The best way to solve this would be to allow someone to encrypt their secret with a password, and require that password to be entered on startup.
  19. handle
    This is true, however when people do this to expose good security being used, it helps the product because more security-conscious people are likely to use it, and to spread it around as a good thing. Because of this, I do not believe this portion of the Terms of Use is being actively enforced, and for good reason. I'm waiting for answers from a developer in a different thread, however I really do want to use Bittorrent Sync, as do many other people. Due to the lack of protocol information or source code, security-conscious people have to either wait for developers (who are most likely very busy) to answer questions about how the system works, or it can be partially reverse engineered to explain better how the internals work. As one of the developers have stated that they do not abide by Security through Obscurity, I see no problem with this when done reasonably. Using it to explain the security of a program is perfectly reasonable.
  20. handle
    Fair enough, thanks.
  21. handle
    Thank you for reverse engineering the protocol some. Would you be able to divulge and/or explain some more information? If you are still persuing this, keep up the good work!
  22. handle
    Hello, Is there an IRC channel for discussing Bittorrent Sync, potentially with developers? Such as #BittorrentSync on freenode or anything? Thanks
  23. handle
    First off, the secret is on disk and not necessarily in one's head. Secondly, a password would not be stored in plain text on a remote third party server - it would most likely be hashed, or hopefully stretched (think PBKDF2). Extra points if the hashing or stretching is done client-side. The problem that comes from using a centralized server to authenticate is that you effectively give that server authority, meaning they can authenticate themselves and access all of your information. It also becomes a central point of failure - if this were the way things worked and Bittorrent Inc. decided to close their doors, Bittorrent Sync would stop working completely. The way they actually work right now (which in my opinion is the right way), is that even if the company shut down, the current version of Sync would still work without problems.
  24. handle
    SSH is not comparable to bittorrent sync. SSH usually has multiple clients connecting to a single server. Each client verifies that the server has the correct key, and the server authenticates the client via a password so no key verification is needed on that side. So if you have one server and 6 clients, you verify 6 times. If you add one more client, you verify one more time, if you add another client on top of that, you only verify once again, etc. With BTSync, on the other hand, every peer connects to every other peer. That means if you have 6 nodes, you verify 6 times. If you add one more node, you verify 7 more times. If you add one more node, you verify 8 more times, etc.
  25. handle
    I disagree, as this is a problem that has been solved numerous times over. Not to mention that using a one-time key is an additional solution over all of the other solutions already out there.