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.1458105200.txt.gz · Last modified: 2017/09/22 13:28 (external edit)