handle

Members
  • Content Count

    46
  • Joined

  • Last visited

  • Days Won

    2

About handle

  • Rank
    Advanced Member
  1. You can make the exact same argument 20 more times but it's not going to make it any more correct.
  2. 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.
  3. 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
  4. 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.
  5. Can a mod or administrator please close this topic? I've found all of the information I wanted.
  6. 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.
  7. 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.
  8. 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
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. Also, is there a reason you aren't using CryptoAPI's CTR mode and instead using a (what I assume is) homebrewed CTR mode?