As for Oracle, they all are [or definitely should be and have been]
pro-EVP, because crypto support on pre-T4 was relying on pluggable
engine interface and EVP is the *only* way to utilize it.
That's really Oracle's problem, and nothing I am concerned with at
all.
Secondly, if you stick to old interface [and want parallelizable
modes] you don't get adequate performance. AES-NI is available only
though EVP (normally developers target on multiple platforms). EVP
interface is the one that gets FIPS-validated, not low-level. There
is a lot of incentives to use EVP, and most critical applications do
so.
Even supposedly well maintained trees using openssl's interfaces
such as OpenSSH still use a mixture of EVP and direct AES calls.
There is only one place OpenSSH calls AES_* directly and that's their
own counter mode implementations. The reason they do is that there was
no EVP counter in OpenSSL at the time. But what do they do with it? They
actually ... implement EVP interface. So that the only code modification
that is required in OpenSSH is to lookup if counter is already provided
and use it or fall back to own implementation.
A library is supposed to be maximally useful to it's users, both
existing and new. This is violated by simply dismissing existing
users who don't use EVP.
Give more examples.
I consider supporting the old APIs a requirement.
Not at arbitrary high costs...
At least for AES and Camellia, the amount of changes necessary for T4
direct support was very low.
Not from my viewpoint...
And BTW, there is precedence for this, as this is what already is done
for the s390 crypto instruction support.
And I regret every bit of it! Day will come for a change... But you
contradict yourself:-) If you don't care about what Oracle does, why do
you care about IBM? It was a joke!
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
