rfc:mcrypt-viking-funeral
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| rfc:mcrypt-viking-funeral [2016/03/16 05:13] – Add background information to provide insights into the security motivations for its removal sarciszewski | rfc:mcrypt-viking-funeral [2017/09/22 13:28] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 3: | Line 3: | ||
| * Date: 2016-01-09 | * Date: 2016-01-09 | ||
| * Author: Scott Arciszewski, | * Author: Scott Arciszewski, | ||
| - | * Status: | + | * Status: |
| * First Published at: http:// | * First Published at: http:// | ||
| Line 65: | Line 65: | ||
| } | } | ||
| </ | </ | ||
| + | |||
| + | Problems with this code: | ||
| + | |||
| + | * It's using [[https:// | ||
| + | * It's attempting to generate an IV for ECB mode (which is a waste of CPU since IVs aren't used in ECB mode) | ||
| + | * It's using MCRYPT_RAND for IV generation, which isn't a CSPRNG | ||
| + | * fnEncrypt() will rtrim() null bytes off the encrypted value before base64 encoding it, which means a 1/256 chance of data corruption that prevents decryption | ||
| + | * fnDecrypt() will rtrim() null bytes off the decrypted plaintext, which means if your plaintext message was raw binary (e.g. gzip compressed), | ||
| + | * There is no MAC, so you transmit this over a network, [[https:// | ||
| Mcrypt has a lot of design warts and puts a lot of burden on the implementer to choose the right components (and stitch them together correctly). Blaming the implementer leads to error-prone cryptographic designs. Error-prone cryptographic designs leads to insecure applications. | Mcrypt has a lot of design warts and puts a lot of burden on the implementer to choose the right components (and stitch them together correctly). Blaming the implementer leads to error-prone cryptographic designs. Error-prone cryptographic designs leads to insecure applications. | ||
| Line 76: | Line 85: | ||
| Comparing libmcrypt to openssl, you will find that it is: | Comparing libmcrypt to openssl, you will find that it is: | ||
| - | * Less well-maintained | + | |
| - | * Less standards compliant (NULL byte padding can cause data loss on decryption; PKCS#7 padding, which openssl_encrypt() uses, does not) | + | * Less standards compliant (NULL byte padding can cause data loss on decryption; PKCS#7 padding, which openssl_encrypt() uses, does not) |
| - | * More confusing for end-users (not that OpenSSL' | + | * More confusing for end-users (not that OpenSSL' |
| - | * Slower on modern hardware | + | * Slower on modern hardware |
| - | * Less resistant to active attackers | + | * Less resistant to active attackers |
| - | * Less feature-rich (no public-key cryptography) | + | * Less feature-rich (no public-key cryptography) |
| ===== Backward Incompatible Changes ===== | ===== Backward Incompatible Changes ===== | ||
| Line 115: | Line 124: | ||
| Since this would break backwards compatibility, | Since this would break backwards compatibility, | ||
| - | <doodle title=" | + | <doodle title=" |
| * Yes | * Yes | ||
| * No | * No | ||
| Line 124: | Line 133: | ||
| ===== Patches and Tests ===== | ===== Patches and Tests ===== | ||
| - | If this RFC is accepted, I will author the patches to deprecate ext/mcrypt. | + | Patches are available: |
| + | * < | ||
| + | * < | ||
| ===== References ===== | ===== References ===== | ||
rfc/mcrypt-viking-funeral.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1