On Tue, Aug 4, 2015 at 10:18 PM, Scott Arciszewski <sc...@paragonie.com> wrote: > 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>
Drat, quick correction: Point 2 of that list should read "Before decryption, the MAC ..." It's strictly Encrypt-then-MAC, Verify-then-Decrypt. 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
