On Wed, Mar 03, 2010, PMHager wrote: > > - EVP support for the CTR128 modes *1) (AES and Camellia), as these > are required in the GCTR [SP800-38D] function of the GCM (instead of > a block-wise use of the ECB mode), >
Andy has added EVP support for CTR128 already. > > - redesign of the EVP interface. > > > My suggestion for the interface is to introduce functions like *2) > EVP_AeadInit(EVP_AEAD_CTX *ectx, EVP_CIPHER_CTX *ctx,...); > > where EVP_AEAD_CTX could be EVP_gcm(), EVP_ccm(), EVP_eax(), > EVP_cwc() and EVP_ocb() for the moment *3), > > and EVP_CIPHER_CTX could be EVP_aes_128_ctr(), EVP_aes_192_ctr(), > EVP_aes_256_ctr(), EVP_camellia_128_ctr(), EVP_camellia_192_ctr(), > EVP_camellia_256_ctr() for EVP_gcm(), and so on. > > > It would be nice if we could bring our parts together to build and > test a version having all advantages together. > I don't see why the existing EVP_CIPHER interface isn't suitable. You add a new flag for GCM/CCM mode and pass or retrieve additional information via standardised ctrls. If you add a whole new API you end up needing new algorithm tables, new ENGINE functions, new BIOs etc. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
