php-encryption

> If they update the library to match the newer expert opinion, it breaks existing code. If they do not update the library, then new applications using it will get the bad default value. This is true for lower-level cryptography libraries like OpenSSL or Libsodium. This isn't true, however, for the sort of higher-level libraries I recommend developers use. See https://github.com/defuse/php-encryption which implements version tagging in its ciphertext output. If Taylor Hornby has to publish a version 3 that uses, say, NORX instead of AES-256-CTR+HMAC-SHA256, the first 4 bytes will identify the version of the library that was used to encrypt the original message. Backwards compatibility is transparent to the end user. (Headers are covered by the HMAC.)

I'm the person who published this advisory to oss-sec and a co-author of https://github.com/defuse/php-encryption I also wrote https://github.com/paragonie/halite which is a PHP library aims to make libsodium incredibly easy for PHP developers to get right. For systems that need asymmetric crypto and can't install libsodium, I also wrote https://github.com/paragonie/EasyRSA which side-steps a lot of the mistakes developers make. EasyRSA uses defuse for symmetric-key encryption, then encrypts the AES key with RSA. Writing secure cryptography isn't trivial. Assuming the three projects I just linked to are secure enough to use (all indications point to: they are), there's literally no reason to reinvent the wheel solely for Magento. Magento already uses Composer; they could just add them to their composer.json file and rewrite their routines