Hi! > 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.
So my question here is - how important task is switching crypto backends easily? Moreover, what would be the reason for me, as an app developer, to target more than one crypto backend? I can see why I may want to target mysql and say, SQL server - these two platforms have different advantages, etc. But if OpenSSL works for my app, why would I need to support any other backend? Do I have a chance of a client saying "oh, we don't run apps using OpenSSL, only libsodium"? Abstraction is a nice thing, but in this case I'm not sure about the added value. Of course, if crypto library goes out of support - like mcrypt - it can be handy, but given that each library probably will have own peculiarities, I'm not sure abstraction would allow for clean switch anyway. > 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. OK, that makes sense. Do current base64 decoding libs have timing problems allowing to devise key bits? The code seems pretty simple, though it does have a lookup there, so in theory that might influence the timing. >> 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 By traveled, do you mean that this library has been reviewed and approved by professional cryptologists and crypt-analysts? > 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: OK, that looks like added value. Doing authenticated encryption right now is not obvious and easy to mess up. > There will also be an aeadEncrypt() and aeadDecrypt() interface, which > allows you to authenticate associated data which is not encrypted. This also sounds good but I'm worried about data formats - encrypted data tend to be exchanged between heterogeneous systems, so I think we should make decoding the resulting message easy without implementing special code (which also could have security problems). > 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. :) Thanks, that sounds good! -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
