>> Basically, in the context I'd prefer not to touch aes-sparcv9.pl and >> stick to "aesni" approach as the only one, i.e. keep T4 code as >> separate module referred from EVP. It allows to concentrate on >> things that matter, optimizing specific modes performance. By >> extension it's preferred approach even for other ciphers. > > Too many pieces of code stil call interfaces such as AES_*() directly > and do not go through EVP. > > This I considered a show stopper, and an absolute failure of design > with the way the Oracle folks implemented crypto opcode support in > their openssl changes. > > It is absolutely impractical to have an EVP only driver for this > stuff.
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. 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. > I consider supporting the old APIs a requirement. Not at arbitrary high costs... ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
