rfc:mcrypt-viking-funeral

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
rfc:mcrypt-viking-funeral [2016/03/16 05:13]
sarciszewski Add background information to provide insights into the security motivations for its removal
rfc:mcrypt-viking-funeral [2017/09/22 13:28] (current)
Line 3: Line 3:
   * Date: 2016-01-09   * Date: 2016-01-09
   * Author: Scott Arciszewski, security@paragonie.com   * Author: Scott Arciszewski, security@paragonie.com
-  * Status: Voting+  * Status: Implemented (PHP 7.1)
   * First Published at: http://wiki.php.net/rfc/mcrypt-viking-funeral   * First Published at: http://wiki.php.net/rfc/mcrypt-viking-funeral
  
Line 65: Line 65:
 } }
 </code> </code>
 +
 +Problems with this code:
 +
 +  * It's using [[https://blog.filippo.io/the-ecb-penguin|ECB Mode]]
 +  * 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), it's now corrupted
 +  * There is no MAC, so you transmit this over a network, [[https://tonyarcieri.com/all-the-crypto-code-youve-ever-written-is-probably-broken|it's vulnerable to chosen-ciphertext attacks]]
  
 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 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's API and documentation are stellar) +  * More confusing for end-users (not that OpenSSL's API and documentation are stellar) 
-* 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, a 2/3 majority is required. Since this would break backwards compatibility, a 2/3 majority is required.
  
-<doodle title="Deprecate then Remove Mcrypt from the PHP Core?" auth="sarciszewski" voteType="single" closed="false">+<doodle title="Deprecate then Remove Mcrypt from the PHP Core?" auth="sarciszewski" voteType="single" closed="true">
    * 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:  
 +  * <del><https://github.com/php/php-src/pull/1995></del> 
 +  * <https://github.com/php/php-src/pull/1996> (merged)
  
 ===== References ===== ===== References =====
rfc/mcrypt-viking-funeral.1458105200.txt.gz · Last modified: 2017/09/22 13:28 (external edit)