5 ms·
> These are all errors that would be impossible in a language with, oh, bounds checking. How would that prevent the timing leak that caused Lucky 13 or the pad
by CiPHPerCoder 10y ago
> These are all errors that would be impossible in a language with, oh, bounds checking.
How would that prevent the timing leak that caused Lucky 13 or the padding oracle that resulted from not erroring when the message was too short?
The problem with CVE-2016-2107 (and the vulns that precede it) stems from TLS not using Encrypt-Then-MAC (checking the MAC before checking the padding is less error-prone than checking the padding before the MAC). You can design a cryptographically doomed protocol in any language, even memory-safe ones.
Here's one in Haskell: https://github.com/RNCryptor/rncryptor-hs/issues/2#issuecomment-174385279 https://github.com/RNCryptor/rncryptor-hs/issues/2#issuecomm...
Further reading on the Cryptographic Doom Principle: https://moxie.org/blog/the-cryptographic-doom-principle/ https://moxie.org/blog/the-cryptographic-doom-principle/
- pjmlp 10y agoYes you can, but you cannot corrupt memory in them and that is already helpful.
- CiPHPerCoder 10y agoThat's nice, but irrelevant. The quote I was replying to said, "These are all errors that would be impossible in a language with, oh, bounds checking." Them: All X is Y. Me: But here's an X that isn't Y. That's my point. Blanket statements about the superiority/inferiority of programming languages aren't useful here.
- coherentpony 10y agoSure you can. Compilers (and interpreters) have bugs in them.
- pjmlp 10y agoA compiler, interpreter bug in terms of attack surface is much different than a programming language where every single string and array access might cause memory corruption.
- lmm 10y agoBounds checking would only solve half of the vulnerabilities that break the security of every computer on the Internet, not all of them, so I guess it's not worth bothering with?