Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87635
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain paragonie.com from 209.85.220.177 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAKws9z1Xq8ySjahxCY32UaRCFWnT6BxOiakNc2s7mOue=6=nSw@mail.gmail.com>
References: <CAKws9z1fatmSR2YLaeBn0zVv-s3iwCj7OUKjW949QC0L_VndpA@mail.gmail.com>
	<55C0685E.2070202@gmail.com>
	<CAKws9z3gBf+_0cSPvo3Sh4NAxuPRZT5EbQoqbvhnLxpyjY4F8g@mail.gmail.com>
	<55C15F1B.9010401@gmail.com>
	<CAKws9z1Xq8ySjahxCY32UaRCFWnT6BxOiakNc2s7mOue=6=nSw@mail.gmail.com>
Date: Tue, 4 Aug 2015 22:25:46 -0400
Message-ID: <CAKws9z0sHEAPbgb9zGYW4+i-O=k2LNZ4a26Zqu67m8ofrobxNA@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] PHP 7.1 Cryptography Projects
From: scott@paragonie.com (Scott Arciszewski)

On Tue, Aug 4, 2015 at 10:18 PM, Scott Arciszewski <scott@paragonie.com> wrote:
> On Tue, Aug 4, 2015 at 8:55 PM, Stanislav Malyshev <smalyshev@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
>> smalyshev@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>