Hi Erik, Thanks for backing me up on a number of things. Only one response below. > > In light of that, there's > > nothing particularly wrong with using CBC, if it is implemented well. > > At least, using it is not *more* wrong than using OFB, CFB, or CTR > > That is wrong. CBC mode allows attacks such as "Sweet32" > (https://sweet32.info/), which is not possible with CTR mode. The site you linked mentioned 64bit block ciphers are vulnerable, even in CTR mode. Obviously the birthday "paradox" applies. Regardless of how right or wrong you are about Sweet32, this far from the most important thing *implementors* should be worried about. Obviously if they start with AES, then the birthday paradox issues are vastly reduced. Any new system should be avoiding the likes of 3DES, Blowfish, etc. So it seems moot. On the flip side, tell me what the impact is of these two scenarios where a developer follows *some* of our advice: (A) They use AES in CBC mode and apply an HMAC to the cipehrtext. They actually validate that HMAC before decrypting. However, they fail to use a unique IV for every message. (B) They use AES in CTR mode and apply an HMAC to the cipehrtext. They actually validate that HMAC before decrypting. However, they fail to use a unique IV for every message. Which is worse? Obviously (B) fails pretty catastrophically. (A) is not great, but at least the plaintext isn't nearly as easy to expose (usually only minor block-level information leaks). In the real world I see these kinds of mistakes all of the time. So be careful of steering people toward a mode that doesn't degrade as gracefully when developers make mistakes. They invariably will do so, unless they've spent as much time with crypto as you and I. tim PS- And to re-iterate, we shouldn't ask them to use any particular cipher mode, but instead to use something off the shelf.
Source: Gmail -> IFTTT-> Blogger
No comments:
Post a Comment