Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:87605 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 50157 invoked from network); 4 Aug 2015 13:04:53 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Aug 2015 13:04:53 -0000 Authentication-Results: pb1.pair.com header.from=jakub.php@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=jakub.php@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.170 as permitted sender) X-PHP-List-Original-Sender: jakub.php@gmail.com X-Host-Fingerprint: 209.85.223.170 mail-io0-f170.google.com Received: from [209.85.223.170] ([209.85.223.170:33219] helo=mail-io0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 52/00-49831-478B0C55 for ; Tue, 04 Aug 2015 09:04:52 -0400 Received: by ioii16 with SMTP id i16so15926466ioi.0 for ; Tue, 04 Aug 2015 06:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=epCR2MnyQI6+W2zUX28ZkOM1vsCf76YaYPL3EyB8CpQ=; b=fM6Pt0t8LxFWpH5a7rLxSW7byndKWn/eMkY7DBTX3CCeSc6mM9KDwvxSMqootVHdqp S8DFDebyMHmu/P+Oe/jJsuGa5z6FcjQjD1dVaEEOAonU+sqPi0oM/ZwTdwRKbaeVA4fy f/Bm32tDGlMZZPyx4vUr5d9u04ulsDNO3dzKnYYx4WeCZ4YGTHtKZ9YDqrC4lVqocht5 G0y6WT2P13ohTFaBcMXShHBhSHBrCKWmti0xH43GIJf4tJ0cth1ZZtE27erSGPDiwpz6 Q1KoVNgHepJSkLBe+9pJ0n66Tr6bU+n3YwmE0bprcNG0f1OFnp7Pp2OlNdbXd9zfpXaK 0PFw== MIME-Version: 1.0 X-Received: by 10.107.156.203 with SMTP id f194mr3212115ioe.164.1438693064194; Tue, 04 Aug 2015 05:57:44 -0700 (PDT) Sender: jakub.php@gmail.com Received: by 10.107.20.83 with HTTP; Tue, 4 Aug 2015 05:57:44 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Aug 2015 13:57:44 +0100 X-Google-Sender-Auth: 3NDNRAvpbnN4GNkX1-TVWEBVgg8 Message-ID: To: Scott Arciszewski Cc: PHP Internals Content-Type: multipart/alternative; boundary=001a1140cd00083ec2051c7bd5cc Subject: Re: [PHP-DEV] PHP 7.1 Cryptography Projects From: bukka@php.net (Jakub Zelenka) --001a1140cd00083ec2051c7bd5cc Content-Type: text/plain; charset=UTF-8 Hi, On Mon, Aug 3, 2015 at 9:54 PM, Scott Arciszewski wrote: > 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 > > I have been actually working on something similar for some time. It's already on PECL and it's called php-crypto: https://github.com/bukka/php-crypto I have been doing lots of changes and fixes including support for PHP 7 (it also supports PHP 5 using https://github.com/bukka/phpc wrapper) and php streams. The internal part has been almost completely rewritten since version 0.1.0 and I plan to release soon 0.2.0 so I will send some update then. I'm currently working on fixing some issues, improving tests and mainly documentation that is still very incomplete (just hash is partially documented in the main readme) so probably the best doc at the moment is generated api doc: https://github.com/bukka/php-crypto/blob/master/docs/Crypto.php There also are some examples in https://github.com/bukka/php-crypto/blob/master/examples and even more examples in tests where is about 70 tests: https://github.com/bukka/php-crypto/blob/master/tests In case you are interested in what I plan to do in the near future, it's all in my TODO list: https://github.com/bukka/php-crypto/blob/master/TODO.md In the long term I would like to add support for asymmetric encryption. I actually wrote an extension called php-rsa ( https://github.com/bukka/php-rsa ) just to play with OpenSSL rsa.h (there is no doc but you can look to the tests if you are interested). However the way how it should be done in crypto is more about using PKEY which is much more flexible but it will be supported only for OpenSSL 1.0.0+. The providers (pluggable api) is a nice thing but it will require quite a bit of thinking to make it right from the internal PoV (address all needs of particular libs - especially OpenSSL) and it's quite a bit of work as well :) But it would be definitely nice to have and I have been thinking about it for some time. But the priority is a creating of a good wrapper for OpenSSL first and then split it to more layers. Cheers Jakub --001a1140cd00083ec2051c7bd5cc--