BTSync uses AES128 in CTR mode, which is good (was: Bittorrent Sync is using 128-bit AES in ECB mode!)

[handle]

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 https://i.minus.com/i4FurGjh8WjUW.png ) 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

[sts]

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.

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).

[handle]

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).

Okay, so under really really specific circumstances (an attacker has two keys that are mathematically related and they know the plaintext behind both of them) AES256 might be less secure, and is still not breakable in a reasonable amount of time. In absolutely EVERY other case, AES256 is leaps and bounds ahead of AES128 in terms of security. Also the "you always have to think that all requirements are fulfilled" quip only goes so far - it really does not apply for this.

Next, how does this make them "truthful about security"? It doesn't matter the security of 128 bits or 256 bits, the fact of the matter is that their code uses 128-bit when their marketing and forums say they use 256-bit. That is not being "truthful about security". It is an outright lie.

As for you not believing they have implemented that, welcome to the real world. People do dumb things all the time, especially with cryptography. I have no trouble believing it is possible they're using ECB over the wire.

I also have a good amount of proof in my screenshot showing they do indeed use 128-bit AES with ECB. If you don't believe that, well, BTLive.exe is publicly available - it's easy enough to perform the same steps to get to that point. CryptImportKey only appears to be called once in the entire codebase.

[sergey@bt]

ECB in the context of this Win32 API call means basic AES operation - encrypt input block with key. The real mode of operation depends on what is encrypted and how the result is used. Currently Sync uses counter mode. But we are still working intensively on a protocol, so it should not be considered as a final spec.

[handle]

ECB in the context of this Win32 API call means basic AES operation - encrypt input block with key. The real mode of operation depends on what is encrypted and how the result is used. Currently Sync uses counter mode. But we are still working intensively on a protocol, so it should not be considered as a final spec.

Thank you for your response, glad to hear a cipher mode is indeed implemented over it, and a secure one at that.

As for the 128-bit AES versus the documented 256-bit AES, is there any explanation for that?

Also, could you explain to me how read-only mode works from a low-level point of view?

Thanks

[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?

[sts]

Okay, so under really really specific circumstances (an attacker has two keys that are mathematically related and they know the plaintext behind both of them) AES256 might be less secure, and is still not breakable in a reasonable amount of time. In absolutely EVERY other case, AES256 is leaps and bounds ahead of AES128 in terms of security. Also the "you always have to think that all requirements are fulfilled" quip only goes so far - it really does not apply for this.

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?

[bascule]

Have you read this paper?

Yes, but apparently you didn't.

And still 128bit is soooooo secure. There is no reason to not use 128bit, or?

Well, for starters, handle's question isn't about the security of 128-bit vs 256-bit AES. It's a question about a discrepancy between what BitTorrent Sync's web site describes versus what's actually in the code. So this entire discussion is a bit of a red herring. That said...

Yes, there is a reason to use 256-bit keys over 128-bit ones: because 256-bit keys are stronger. This is an attack against a 10-round variant of AES-256. The real version is 14 rounds.

It is mildly alarming that there are attacks on AES-256 (even with 10 rounds) don't work on AES-128, and that 10-round AES-256 can be broken with a lower computational complexity than 10-round AES-128. However, we don't use 10 round AES-256, we use 14 round AES-256.

Will there be a successful cryptanalysis of 14-round AES-256 which lowers its computational complexity to below 10-round AES-128? I don't know, I don't have the crystal ball to tell me that. Nor can my nonexistent crystal ball tell me if there will be future attacks on AES-128 which don't work on AES-256.

tl;dr: you're making a slippery slope argument. In the meantime 14-round AES-256 still provides a higher computational complexity than 10-round AES-128.

[Xanza]

Potentially means nothing to me. Prove beyond a reasonable doubt that they are using 128-bit AES instead of 256-bit AES and I'll demand an explanation -- not before. Since you're not a first hand programmer, and are not fluent in the way that the application was designed, or released, I'm more inclined to believe the original statements of 256-bit AES in lieu of 128-bit AES; as that's what I've been told and have not been told otherwise since.

Secondly, any cypher mode could potentially, in the eyes of the programmers, put the entire protocol at risk if released. Although it does look suspicious I won't immediately rebuke their decision to keep such information away from public view.

EDIT:

ECB in the context of this Win32 API call means basic AES operation - encrypt input block with key. The real mode of operation depends on what is encrypted and how the result is used. Currently Sync uses counter mode. But we are still working intensively on a protocol, so it should not be considered as a final spec.

Ask and you shall receive.

[sergey@bt]

We do use AES-128 in 1.1.x. Protocol has changed since version 1.0.x. AES-256 was removed from user guide PDF, but not from Technology section on site. We will update site shortly. You may find a lot of discussions AES-128 vs. AES-256 in Internet (including related keys attack). We believe AES-128 is not weak at all and it's a good choice for session encryption today. Also it's ~30-40% faster, which is critical for low end CPUs and mobile devices.

[sts]

We do use AES-128 in 1.1.x. Protocol has changed since version 1.0.x. AES-256 was removed from user guide PDF, but not from Technology section on site. We will update site shortly. You may find a lot of discussions AES-128 vs. AES-256 in Internet (including related keys attack). We believe AES-128 is not weak at all and it's a good choice for session encryption today. Also it's ~30-40% faster, which is critical for low end CPUs and mobile devices.

Thank you, thats indeed what I think of.

[handle]

Potentially means nothing to me. Prove beyond a reasonable doubt that they are using 128-bit AES instead of 256-bit AES and I'll demand an explanation -- not before. Since you're not a first hand programmer, and are not fluent in the way that the application was designed, or released, I'm more inclined to believe the original statements of 256-bit AES in lieu of 128-bit AES; as that's what I've been told and have not been told otherwise since.

Secondly, any cypher mode could potentially, in the eyes of the programmers, put the entire protocol at risk if released. Although it does look suspicious I won't immediately rebuke their decision to keep such information away from public view.

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.

[handle]

Thank you, thats indeed what I think of.

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.

[handle]

We do use AES-128 in 1.1.x. Protocol has changed since version 1.0.x. AES-256 was removed from user guide PDF, but not from Technology section on site. We will update site shortly. You may find a lot of discussions AES-128 vs. AES-256 in Internet (including related keys attack). We believe AES-128 is not weak at all and it's a good choice for session encryption today. Also it's ~30-40% faster, which is critical for low end CPUs and mobile devices.

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

[handle]

Can a mod or administrator please close this topic? I've found all of the information I wanted.

[Disappointed Cat]

Please forgive me for reviving a security thread.

In this new spy-age would you consider adding the option to change the cipher to AES256-GCM or something similar?

I'm not saying AES128-CTR is not sufficient but we'd better be prepared for the future.