Sorry about the C++ comments, I just found them in the GCM acceleration
code. I'll fix those.
There's no EVP layer for an encrypt + hash EVP API which would be needed
for GCM and CCM to be usable via an EVP type interface.
AES-CCM also has it's own quirks which would bite if you ever wanted to
have it FIPS certified and it was used via a generic upper layer API.
By specification it's not supposed to produce decrypted output if the hash
fails which breaks the normal Init/Update/Update/.../Final pattern.
If you mean the use of AES_set_encrypt_key() and AES_encrypt() - you'd have
to get CCM and GCM explicitly tested to get them FIPS certified anyway,
they won't gain FIPS certfication just because the underlying AES is FIPS
certified so there's no real loss there.
However I take the point about not using AES hardware where it exists. The
code IBM uses is software only and the catch was that there's was a fairly
decent performance penalty using EVP and it didn't seem worth the hit when
CCM and GCM are only specified for use with AES.
I'll change GCM and CCM to call the EVP functions.
As a comment, there are a number of hardware cores offering AES-GCM now, so
re-vectoring they whole of AES-GCM is possibly a more desirable option than
using just AES hardware when available.
Creating an encrypt +hash EVP API though - at least one that would also
cope with CCM just gave me a headache - and there doesn't seem enough gain
to do it for only one algorithm.
As for CMAC, I just copied HMAC - which also lacks upper level EVP style
entry points. Again, both algorithm famillies (CMAC/HMAC) probably should
have a single generic EVP wrapper.
CMAC is cleaner in that it does use the underlying EVP calls - the
performance trade off there was against the ability to support multiple
ciphers - no contest.
Peter
From: "Dr. Stephen Henson" <[email protected]>
To: [email protected]
Date: 25/05/2009 09:58 PM
Subject: Re: [openssl.org #1935] AES-GCM, AES-CCM, CMAC updated for
OpenSSL1.0 beta 2
Sent by: [email protected]
On Mon, May 25, 2009, Peter Waltenberg wrote:
> Up to the OpenSSL team. I'm happy to do any maintenance required, but
it's
> up to them to merge it - or not.
> Given that there are a number of people using the patch now and AES-GCM
is
> needed for new TLS modes, I'd hope it gets merged.
>
I had a brief look at the patch. Thre are quite a few C++ style comments in
there which cause issues on some compilers. If you up the gcc warning
levels
these will be obvious (see $gcc_devteam_warn in the Configure script).
This can't go into 1.0.0 because that's in a feature freeze. It could go
into
HEAD (which will be 1.1.0) and 1.0.1 (no branch exists for this yet).
This really needs EVP support though. Applications should avoid use of low
level APIs because they prohibit the use of ENGINEs and such things as FIPS
require the use of EVP.
Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
