handle

Members
 View Profile  See their activity

  • Posts

    46

  • Joined

  • Last visited

  • Days Won

    2

handle's Achievements

Advanced Member

Advanced Member (3/3)

  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?