Hi Pierre,
On Thu, Jun 2, 2016 at 10:30 AM, Pierre Joye <pierre....@gmail.com> wrote:
> hi Scott,
>
> On Wed, Jun 1, 2016 at 2:49 PM, Scott Arciszewski <sc...@paragonie.com> wrote:
>> Hi PHP Internals Team,
>>
>> Let's begin discussing the prospect of adding libsodium as a core extension
>> in PHP 7.1. I've updated the RFC to explain why this would be a good idea
>> and the benefits it offers.
>>
>> https://wiki.php.net/rfc/libsodium
>>
>> If the subsequent discussion goes smoothly, I would like to open voting on
>> June 15.
>>
>> Together, let's make PHP cryptography so safe that it becomes boring.
>
> Good work and very good choice for the backend library.
>
> I am overall in favor of having this extension in the core. However a
> couple of things are sub optimal or not ideal (in no special order):
>
>
> - \Sodium\library_version_major() \Sodium\library_version_minor() and
> \Sodium\version_string() should be constants
I agree.
> For \Sodium\version_string(), the name is not consistent as it refers
> to the library version not the extension version ("Returns a string
> identifier of the current version of the sodium library installed.")
> (edit: used would better represent what is actually happening)
>
>
> - memzero, memcmp, hex2bin
>
> I am not totally convinced that memzero and maybe memcmp names are
> good nor they should be there. Both would be very useful as operator
> on variables. Given the simplicity of the implementations, it could be
> very useful in many other areas in case this ext is not installed
IMO: memzero is fine; memcmp isn't that great.
For what it's worth, we have hash_equals() already.
> For hex2bin, the optional parameter could be added to the existing
> functions. As this function does not require crypto safe
> implementation (and does not need from an implementation), we should
> have them as part of the engine instead.
We should seriously just make bin2hex, hex2bin, base64_encode, and
base64_decode constant-time now so we don't have to worry later when
some clever CS post-doc find a way to exfiltrate crypto keys through
cache misses. That calls for a separate RFC, but there's no salient
argument against this change.
> - buf and other abbreviations should be better. I think we had a
> discussion some time ago about how to provide interfaces for non C
> developers.
No argument there.
> - compare should be string_compare, or it could be confusing about
> what it can compare, especially in code review while checking crypt
> code, where many other types come into the game
This is an excellent point.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
