Search the Community

Showing results for tags 'aes'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Resilio Sync
    • Sync General Discussion
    • Sync Troubleshooting
    • Sync for NAS (Network Attached Storage)
    • Sync Stories
    • Developers
    • Feature Requests

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL







Found 3 results

  1. Hello Developers, I think i have discovered a bug in your Sync Program If you add a random generated AES-256bit encrypted base64 string into the program, it asks you to load a folder for you to sync, however this automatically makes it read-write, apparently this shouldn't be possible? try it if you wish encrypt any random data with any random password ans use that key generated and add it to BitTorrent Snyc and choose a folder. give anyone you know that key, and they can act as peers, is this supposed to happen, as i think its not? Sorry if this makes no sense, I'm extra tired from programming java all night. No this isn't spam this is a authentic post and i think i may have discovered a bug. - Gigasea
  2. On this forum, someone(RomanZ?) recomemded not to use encrypted secret keys (stars with "D" instead of "A") as they require more work (checksum) and hence more load on ARMs. I just got an idea that if substitution cipher is used instead of AES, is there any way of not having to do more checksums (assuming sum of all bytes is the checksum, it wont change even after encryption). And the encryption would be fast as well and it is compressible as well. And if another encryption is done after compression, it is more hard to break I guess. I am not an expret, just some thoughts. Any possibility?
  3. Hello, All over the marketing and the forums, it is stated that Bittorrent Sync uses 256-bit AES encryption, and also nowhere is the cipher mode actually stated. 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. The other problem (again, provided there isn't something else beyond the story) is that the cipher mode is ECB, or Electronic Code Book. It means there is no mode at all, which is definitively the least secure method of using AES. Is ECB what is used over the wire, or is a cipher mode implemented over this ECB? I have attached a screenshot (also available at ) that shows why I believe this is the case. Notice the lines "pbData.aiKeyAlg = CALG_AES_128" near the middle, and "v13 = CRYPT_MODE_ECB" about 1/5 of the way from the bottom. Also while I'm here, can a developer explain how read-only keys work, and how 1) malicious nodes are prevented from syncing in new or modified files, as well as 2) how a read-only node knows the difference between another read-only node and a regular node? Please give the low-level gritty explanation, as I would prefer that over a higher-level one. Thanks