> Am 05.08.2015 um 04:57 schrieb Pierre Joye <pierre....@gmail.com>:
>
> On Wed, Aug 5, 2015 at 3:40 AM, Bob Weinand <bobw...@hotmail.com> wrote:
>>
>>> Am 3.8.2015 um 22:54 schrieb Scott Arciszewski <sc...@paragonie.com>:
>>>
>>> Hi,
>>>
>>> I would like to make it easier for PHP developers to implement
>>> cryptography features in their applications. I intend to work on some
>>> of these ideas and submit them for inclusion in PHP 7.1.
>>>
>>> Some of these might be familiar to some of you.
>>>
>>> 1. Pluggable Cryptography Frontend
>>>
>>> Work is currently underway for a PHP prototype for this idea
>>> originally suggested by ircmaxell, that will basically be like PDO for
>>> cryptography. Our current project name, subject to change, is PHP
>>> Crypto Objects (PCO).
>>>
>>> The idea is that you could write code like this to add secure
>>> authenticated encryption to your application without having to worry
>>> about the details.
>>>
>>> $AES = new \PCO\Symmetric('openssl:cipher=AES-128');
>>> $ciphertext = $AES->encrypt($plaintext, $someKey);
>>>
>>> $PKC = new \PCO\Asymmetric('libsodium');
>>> $offlineDecryptable = $PKC->seal($plaintext, $someX25519PublicKey);
>>>
>>> When it's finished, I'd like to turn it into a PECL extension so users
>>> can play with it in PHP 7.0 and submit it for inclusion in 7.1.
>>>
>>> 2. Cache-timing-safe character encoding functions
>>>
>>> Alternatives for existing functions that should function like their
>>> unsafe counterparts, but without branches or data-based index lookups.
>>>
>>> * hex2bin() -> hex2bin_ts()
>>> * bin2hex() -> bin2hex_ts()
>>> * base64_encode() -> base64_encode_ts()
>>> * base64_decode() -> base64_decode_ts()
>>>
>>> Other formats are out of scope, unless someone can make the case that
>>> we need to support RFC 4648 base32 encoding (e.g. for Tor Hidden
>>> Service integration).
>>>
>>> 3. Other ideas (not yet committed to at all, but might be of interest
>>> to others):
>>>
>>> * Improving the OpenSSL API, or at least the documentation
>>> * Adding streaming encryption/decryption support to OpenSSL
>>> * Adding AE and AEAD interfaces to OpenSSL
>>> * Aliasing MCRYPT_AES -> MCRYPT_RIJNDAEL_128, adding MCYPT_MODE_CTR
>>>
>>> What I need from you is guidance on what features or changes you want
>>> to see in 7.1 and which can be put off until later (or never proposed
>>> as an RFC at all).
>>>
>>> Seriously, all I need is your opinion and whether or not you'd like to
>>> see any of these happen. If you have specific implementation details
>>> you'd like to discuss or requests, of course those are welcome too. :D
>>>
>>> "With great ubiquity comes great responsibility." - Matthew Green
>>> <https://twitter.com/matthew_d_green/status/578567678492733440>
>>>
>>> Scott Arciszewski
>>> Chief Development Officer
>>> Paragon Initiative Enterprises <https://paragonie.com>
>>
>> Hey,
>>
>> I went ahead and just made bin2hex()/hex2bin() timing safe as a first step.
>>
>> See https://github.com/php/php-src/pull/1453
>> <https://github.com/php/php-src/pull/1453>
>>
>> Note that it does not add extra functions, but just because performance is
>> just about as good as before [or even better in cases of severe
>> mispredictions].
>
> Nice work :)
>
>
>> If there’s no negative feedback, I’m going to merge that in a few days into
>> master.
>
> We are in feature freeze so please hang on the push.
>
> Also time safe functions may be trickier than it looks. We have to be
> very careful by declaring one timesafe (or safe at all) so a peer
> reviews are a must here. A RFC too. Let not rush and push something
> possibly buggy too early.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org <http://www.libgd.org/>
Not sure what the point of a RFC here is. It is obviously okay to do that… the
only discussion is whether it's really safe. We need people with deep
understanding of these things to look at, not a generic RFC.
The pull request already provides all info needed. I don't know who to ask
specifically for review? I'd rather ask a few experts than throwing this at a
community where 99% of people have no deep understanding in this field.
Bob
P.s.: yes, we are in *feature* freeze. Not sure if a (timing) safety fix falls
in the feature category.
