Crypto Fails

0

Free

Updated 11 March 2025

Showcasing bad cryptography. Archive Ask Crypto Questions About Reasoning by Lego: The wrong way to think about cryptography. Scott Arciszewski from Paragon Initiative pointed me to this example of PHP cryptography. The code is bad and the crypto design is flawed, but as usual for this blog, we can learn something from it. Let’s ignore the fact that it’s using MCRYPT_RIJNDAEL_256 (the 256-bit block version of Rijndael, not AES) instead of MCRYPT_RIJNDAEL_128 (real AES), the fact that it’s not checking the return value of substr(), and the fact that it’s passing a hexadecimal-encoded key to a function that expects a binary string. I’ve covered all of these failings on this blog before, so I won’t touch on them again. Instead, let’s focus on two facts. First, it is doing “MAC then Encrypt” (MtA), which means the Message Authentication Code (MAC) is being applied to the plaintext message before encryption – contrary to modern crypto wisdom. Second, that the MAC is checked with a non-timing-safe comparison, which means that if an attacker can get really precise timing measurements of a failed decryption, they can find out how much of the MAC matches. In the “Encrypt then MAC” (EtM) design, where the MAC is applied to the ciphertext after encryption, this kind of a timing leak usually lets you forge a message. But this time, the MAC is inside the ciphertext, encrypted, so at a first glance, exploiting it seems more difficult. Indeed, the issue was brought up