Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:48305
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 207.97.245.233 as permitted sender)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <D0.2B.05421.113F1FB4@pb1.pair.com>
Date: Mon, 17 May 2010 22:19:09 -0400
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <AFCD45E3-3172-47A5-9868-260ECB13702B@php.net>
References: <D0.2B.05421.113F1FB4@pb1.pair.com>
To: Sara Golemon <pollita@php.net>
Subject: Re: [PHP-DEV] openssl_(en|de)crypt missing IV
From: davey@php.net (Davey Shafik)

The least disruptive change would be to have it as the last arg, and =
default to the current all-null value.

Perhaps you could do this and add a warning akin to the date.timezone if =
none is passed?

Having said that, I don't think the disruption would be too bad, I =
haven't seen much use of the openssl stuff in the
wild; it's pretty much pointless anyways, everybody knows you can =
decrypt anything with a modem coupler and
any 15 year old kid...

Another option, is an openssl_set_iv($iv); method, that would setup for =
openssl_encrypt/decrypt to use, otherwise
use the current all-null option....

This has the added benefit of being as global as you like, and no need =
to keep passing the IV to encrypt/decrypt
all over the place. It has the potential of clashing when you bring =
multiple codebases together however (i.e a framework).
Possible to limit to a single namespace?

- Davey


On May 17, 2010, at 9:53 PM, Sara Golemon wrote:

> 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.
>=20
> On opening ext/openssl/openssl.c, I noticed line 4620 which simply =
hardcodes IV as a string of NULL bytes.
>=20
> 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.
>=20
> 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".
>=20
> 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.
>=20
> 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.
>=20
> I think it's worth a BC break.  Comments?
>=20
> -Sara
>=20
> P.S. - Here's the signature I'd go with: openssl_encrypt($data, =
$method, $iv, $key, $raw=3Dfalse)
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20