Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96756
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.48 as permitted sender)
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
In-Reply-To: <CAKws9z0+xQvUScy5a0TjOrorrPpRmCknaUfCASvWHTaqiaqfaA@mail.gmail.com>
Date: Mon, 7 Nov 2016 15:29:59 +0300
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <352DE108-A96C-4375-AABF-FC4F5C37014C@gmail.com>
References: <CAKws9z2C9cPYRWP4gAP=JiHEq2bDZT3z9v7JFRWnZiKg-QZH0Q@mail.gmail.com> <CAEKnhAF-qbiaHNzenf4STYuNhde7Deep=MQB0SsnEX78QKv8og@mail.gmail.com> <CAKws9z0+xQvUScy5a0TjOrorrPpRmCknaUfCASvWHTaqiaqfaA@mail.gmail.com>
To: Scott Arciszewski <scott@paragonie.com>
Subject: Re: [PHP-DEV] OpenSSL - New Defaults
From: inefedor@gmail.com (Nikita Nefedov)



> On 7 Nov 2016, at 03:35, Scott Arciszewski <scott@paragonie.com> wrote:
>=20
>> On Sun, Nov 6, 2016 at 2:19 PM, Jakub Zelenka <bukka@php.net> wrote:
>> Hi,
>>=20
>> On Thu, Nov 3, 2016 at 4:11 PM, Scott Arciszewski <scott@paragonie.com>
>> wrote:
>>>=20
>>> Hi,
>>>=20
>>> Can we change openssl_public_encrypt() and openssl_private_decrypt() fro=
m
>>> defaulting to PKCS1v1.5 padding, in favor of defaulting to OAEP?
>>>=20
>>> I'll create an RFC for this later. It will just prevent a lot of issues.=

>>>=20
>>> To wit:
>>>=20
>>> - https://framework.zend.com/security/advisory/ZF2015-10
>>> -
>>>=20
>>> https://github.com/garyr/portunus/blob/89853c180c85c71baac7015cb77ff8dda=
e129942/src/Portunus/Crypt/RSA/PrivateKey.php#L20
>>> -
>>>=20
>>> https://github.com/NorseBlue/Sikker/blob/c158bab1e676d751e5228cb17ecf959=
3c6b94e95/src/Asymmetric/Keys/PrivateKey.php#L72
>>>=20
>>> If we can't stop PHP developers who aren't cryptographers from writing
>>> their own high-level RSA implementation, we can at least make it safer b=
y
>>> default.
>>>=20
>>=20
>> We can't change default in 7.x as it would be a BC break and in this case=
 a
>> very hard to catch BC break as the only way how we could let user know ab=
out
>> that is a documentation. This is a very low level function and PKCSv1.5 i=
s
>> still used a lot so some apps might depend on. I think that the default i=
s
>> bad but I don't think that breaking both function without notice is a goo=
d
>> solution as users might not be able to catch it especially if it's some
>> third party protocol that is not very secure but you don't have choice
>> because 3rd party won't change it (that was actually the only case where I=

>> used these functions in practice so it's not made up). And even worse if y=
ou
>> don't have tests, then it breaks just production without a warning...
>>=20
>> What I would prefer instead is to deprecate calling
>> openssl_(private|public)_(en|de)crypt without a padding parameter. The
>> default would stay the same but user would get a deprecation message and t=
he
>> parameter would become required in PHP 8. We should add a note to the doc=
,
>> to let the user know what the safest option is. It means OAEP for
>> openssl_private_decrypt and openssl_public_encrypt. In case of
>> openssl_public_decrypt and openssl_private_encrypt, we support just
>> PKCS1v1.5 but if we add support for PSS (would require a little bit of
>> tweaking as it works on EVP level only but might add it later), we could
>> easily recommend it then.
>>=20
>> I have got actually very similar plan for openssl_seal and openssl_open t=
hat
>> have default method rc4. Again very bad default but the best way how to l=
et
>> user know is to deprecate it rather than choose new default and break
>> compatibility.
>>=20
>> Cheers
>>=20
>> Jakub
>>=20
>>=20
>=20
> Hi Jakub,
>=20
>> We can't change default in 7.x as it would be a BC break and in this case=
 a very hard to catch BC break as the only way how we could let user know ab=
out that is a documentation.
>=20
> A sane proposal had emerged before I even received this email, via
> kemmeta on Reddit:
>=20
> https://www.reddit.com/r/PHP/comments/5axmn5/phpinternals_openssl_new_defa=
ults_proposal/d9kx8sa/?context=3D1
>=20
> A backwards-compatible interface would default
> openssl_public_encrypt() to OAEP, but openssl_private_decrypt() would
> default to a new constant: OPENSSL_PKCS1_UNSPECIFIED, which when
> passed would first try OAEP and, if a padding error occurred, emit an
> E_DEPRECATED and fallback to PKCS1v1.5 (a.k.a. "let's pretend Daniel
> Bleichenbacher's research doesn't exist" mode).
>=20
> The upside is that better security would be applied opportunistically
> in codebases where the PHP developer was not a cryptographer. The
> downside is a performance hit unless you specify one mode or another.
>=20
> A long term solution would be to not even use RSA anymore.
>=20
>> I have got actually very similar plan for openssl_seal and openssl_open t=
hat
>> have default method rc4. Again very bad default but the best way how to l=
et
>> user know is to deprecate it rather than choose new default and break
>> compatibility.
>=20
> If your plan is to get it more in line with libsodium's
> crypto_box_seal API, I'd love to see it.
>=20
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20


Hey,

It might make even more sense to not provide a default here at all. As histo=
ry shows that those methods that are considered secure today can become less=
-than-desirably secure in a couple of years. Which means the same cycle of d=
eprecation/changing defaults in years to come.=