On Tue, Aug 4, 2015 at 3:23 AM, Stanislav Malyshev <smalys...@gmail.com> wrote: > Hi! > >> 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). > > It would be nice to see full RFC (or other extensively documented > proposal) about this. I like the idea, though I wonder isn't mcrypt > essentially doing the same? It would be nice to see the description of > the added value provided over mcrypt, openssl, etc. extensions. > >> 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() > > Why specifically these functions? It would be nice to hear rationale for > this. > >> * Improving the OpenSSL API, or at least the documentation > > Improving documentation is always a worthy goal! > >> * Adding streaming encryption/decryption support to OpenSSL > > Hm... Implementing streaming cyphers right is not trivial, and if we'd > be doing our own crypto (as opposed to providing API to existing > libraries) we need a real lot of review to be confident it's done right. > >> 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 think it'd be nice to see more details on the proposal. I.e. > "improving OpenSSL API" - how? PCO - great, but what API would it offer > and how that API is better than what we have now? The idea of making > crypto easier is great, but if we want to make specific plans as of > which features we want, we need more detailed proposals I think. > > -- > Stas Malyshev > smalys...@gmail.com
Hi Stanislav, > It would be nice to see full RFC (or other extensively documented > proposal) about this. I like the idea, though I wonder isn't mcrypt > essentially doing the same? It would be nice to see the description of > the added value provided over mcrypt, openssl, etc. extensions. The idea here isn't too far removed from what PDO does versus mysql_*, mssql_*, pgsql_*, etc. except it's probably more critical: Switch crypto backends with almost zero refactoring; just change your constructor. Also, libmcrypt has been abandoned and we should look into rm -rf /ing ext/mcrypt in a future PHP version (say, 8.0). https://paragonie.com/blog/2015/05/if-you-re-typing-word-mcrypt-into-your-code-you-re-doing-it-wrong > Why specifically these functions? It would be nice to hear rationale for > this. Developers are, quite rationally, going to want to store their encryption key in configuration files. (INI, JSON, XML, YAML, .env files, etc.) In doing so, they will generally choose to encode these functions in base-16 or base-64 for storage purposes. Offering timing-safe encoding functions adds no negligible cost but prevents cache-timing attacks (especially relevant if you're doing cryptography in "the cloud" -- check out FLUSH+RELOAD attacks, for example) that could otherwise leak your secret key. > Hm... Implementing streaming cyphers right is not trivial, and if we'd > be doing our own crypto (as opposed to providing API to existing > libraries) we need a real lot of review to be confident it's done right. You're right. Luckily this is a road I've already traveled with defuse/php-encryption. https://github.com/defuse/php-encryption/pull/78 Anyone who wants to help everyone using PHP 5 while also providing guidance and words of caution that we can reference when developing this feature for 7.1 is invited to hammer at that PR. > I think it'd be nice to see more details on the proposal. I.e. > "improving OpenSSL API" - how? PCO - great, but what API would it offer > and how that API is better than what we have now? The idea of making > crypto easier is great, but if we want to make specific plans as of > which features we want, we need more detailed proposals I think. Which brings me to the meat of the proposal: Although the interface I introduced in the first post only mentions encrypt() and decrypt(), that's actually not the whole truth. PCO\Symmetric will only ever, and this is not negotiable, offer Authenticated Encryption modes: * AES-CBC + HMAC-SHA256 * AES-CTR + HMAC-SHA256 * AES-GCM * XSalsa20 + Poly1305 * Salsa20 + Poly1305 * ChaCha20 + Poly1305 openssl_encrypt() does not authenticate ciphertexts for you. mcrypt_encrypt() does not authenticate ciphertexts for you. \Sodium\crypto_secretbox() DOES authenticate ciphertexts for you. If anyone is unclear on why authenticated encryption is important, I've explained it in great detail here: https://paragonie.com/blog/2015/05/using-encryption-and-authentication-correctly Unless your driver does this (e.g. libsodium), \PCO\Symmetric::encrypt() will always Encrypt then MAC, and verify the MAC (in constant time!) before decrypting, and the user never has to concern themselves with such details. All they will know is that their messages are encrypted, and tampering with the encrypted data throws an exception when they try to decrypt it afterwards. There will also be an aeadEncrypt() and aeadDecrypt() interface, which allows you to authenticate associated data which is not encrypted. This will all be documented in the RFC when it comes time to open it (as well as the Github repository for the PHP extension when we get to this point), so if anyone misses this email don't worry. :) 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
