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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php