On Tue, Aug 4, 2015 at 8:55 PM, Stanislav Malyshev <smalys...@gmail.com> wrote: > 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
Hi Stas, > By traveled, do you mean that this library has been reviewed and > approved by professional cryptologists and crypt-analysts? This is probably my favorite question, because it's a very challenging one to answer with adequate precision. I will, however, attempt to do so! :) The answer to your question is: It depends on your criteria. I don't know who you would consider to be "professional cryptologists and crypt-analysts", so I can't just say "yes" or "no" without possibly being wrong. Would you consider Taylor Hornby (the author of the library) a professional? How about Anthony Ferrara (a board member for the Password Hashing Contest)? I would. If you consider the combined efforts of everyone who has contributed to Defuse's library to account for anything at all, including myself, then I'm going to say "Yes." Sidenote: would you consider me a professional, in any capacity? If not, would it matter if I took the time to document and list all of the (cryptography related) vulnerabilities I've found and reported in other peoples' projects, or all of the literature I've written on the subject? Surely that counts for proof of competence in the field, even if I'm not entrenched deep enough in academia to have published papers or allocated time to studying cryptography primitives (e.g. block cipher cryptanalysis)? I'm also not sure who all Taylor has asked to examine the library or what their findings were. I do know, if any were found, they would be fixed immediately. Maybe others (Solar Designer, Daira Hopwood, Zooko Wilcox-O'hearn, et al.) have looked at it and found no vulnerabilities? I can't speak for anyone else. However, as of today, nobody has been ponied up thousands of dollars to hire someone else to review it line-by-line and attempt to make it fail to encrypt/decrypt data safely. Neither myself nor Taylor are rich, but if that's what it takes to guarantee a "yes" answer to your question, and anyone would like to cover this expense, please let Taylor know. He would be positively thrilled to hear it. As for my pull request, it's probably best to discuss that on Github with others. Schneier's Law dictates that nothing I say about the security of my own code matters. However, I can say with reasonable certainty that the following issues have been addressed: 1. The File class only provides authenticated encryption using AES-128-CTR with HMAC-SHA256 (facilitated by OpenSSL). 2. During decryption, the MAC is recalculated over the the entire file and verified against the MAC stored at the end of the file. 3. MACs are compared in constant time. 4. TOCTOU is mitigated during decryption by keeping MACs of each chunk in memory and verifying each before continuing decryption, so race conditions (i.e. overwriting or rearranging blocks in the file after the MAC has been verified) will not allow arbitrary ciphertext forgery. If there is a cryptography concern not listed above, that means it either isn't fresh on my memory (i.e. it's obvious), or it hasn't come up and might be a source of insecurity in the current iteration of File.php :O With all that said, more scrutiny is always welcomed. 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
