I was just looking through the implementation of openssl_encrypt() (and
openssl_decrypt()) today because I need to make some encrypted payloads,
but the prototype didn't have anywhere to place an initialization vector.
On opening ext/openssl/openssl.c, I noticed line 4620 which simply
hardcodes IV as a string of NULL bytes.
This is a bad idea roughly equivalent to hashing passwords without salt;
Worse, it prevents interoperability at the application layer by
preventing the decryption of a data stream where the generator used an
IV other than all-null.
Fixing this is a simple matter, but I wanted to bounce approaches for BC
(or lack thereof) off everyone else since this version of
openssl_encrypt() is already "in the wild".
The most direct and obvious solution is to add a fifth, optional
parameter to openssl_encrypt() and openssl_decrypt() to take IV as a
string. The problems with this are that it: (A) Places the IV in an odd
argument location, and (B) Does not enforce the passing of an IV (since
raw is already optional). As stated above, IV really *should* be
enforced, given what it does to soften the security normally offered by
a chaining block method.
That said, I'd like to propose something unpopular; Change the
signature for these methods entirely, deliberately breaking BC. I know,
I know.... spare me your rotten tomatoes. I think it's justified in
this case because, as they are now, these functions are useless at best,
and possibly dangerous in terms of encouraging unsafe practices with
regards to cryptography.
I think it's worth a BC break. Comments?
-Sara
P.S. - Here's the signature I'd go with: openssl_encrypt($data, $method,
$iv, $key, $raw=false)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
