Hi Scott,
I'm clearly very late to this party but, fwiw, ...
First: Great! Thank you. This is really needed. Chapeau!
Yes, a pluggable back-end is important. OSS crypto libs have some unhappy
history and it only makes sense to expect more.
When I reviewed cryptography.io, I really liked how their API and
documentation clearly separates what they call recipes vs. hazmat. I think
it's important to nudge developers away from primitives (hazmat) and
towards simple APIs to relatively safe protocols (recipes). (Some
improvements to PHP in recent years were motivated by the same concern.) I
wonder if you might consider some similar separation or other nudging?
> $AES = new \PCO\Symmetric('openssl:cipher=AES-128');
> $ciphertext = $AES->encrypt($plaintext, $someKey);
As some others, I too dislike the DSN-style constructor.
I think a lot of developers are not well placed to choose a backend, so
some way of making that optional would be swell.
> 2. Cache-timing-safe character encoding functions
>
> Alternatives for existing functions that should function like their
> unsafe counterparts, but without branches or data-based index lookups.
>
> * hex2bin() -> hex2bin_ts()
> * bin2hex() -> bin2hex_ts()
> * base64_encode() -> base64_encode_ts()
> * base64_decode() -> base64_decode_ts()
Interesting question. Whatever \PCO needs to be able to implement
high-level protocols may as well be made available to users.
> 3. Other ideas (not yet committed to at all, but might be of interest
> to others):
>
> * Improving the OpenSSL API, or at least the documentation
> * Adding streaming encryption/decryption support to OpenSSL
> * Adding AE and AEAD interfaces to OpenSSL
I'm in favor of spending as little time on OpenSSL as possible and
devoting that time instead to better interfaces in \PCO that hide it. But,
for anyone attempting documentation improvements to OpenSSL, when I was
porting code from Mcrypt to OpenSSL, I wrote some notes that may be of
use: thefsb.tumblr.com/post/110749271235
<http://thefsb.tumblr.com/post/110749271235> and
thefsb.tumblr.com/post/111035508040
<http://thefsb.tumblr.com/post/111035508040>
> * Aliasing MCRYPT_AES -> MCRYPT_RIJNDAEL_128, adding MCYPT_MODE_CTR
I have similar feeling towards Mcrypt. I would not make an investment of
effort in trying to make use of Mcrypt less dangerous. Better to spend
the budget on making good alternatives.
> What I need from you is guidance on what features or changes you want
> to see in 7.1 and which can be put off until later (or never proposed
> as an RFC at all).
>
> Seriously, all I need is your opinion and whether or not you'd like to
> see any of these happen.
100%
> If you have specific implementation details
> you'd like to discuss or requests, of course those are welcome too. :D
KDFs and padding, both being hazmat.
Question: I believe BoringSSL's and LibreSSL's APIs are similar to
OpenSSL's. Do you have any plans for those? And, if you have looked at
libgcrypt or Botan, what's your opinion on the value of supporting them?
Tom
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
