Hi Herbert, Chuck,
I've been thinking more on how I might go about rebuilding at least part of my
krb5 crypto library on top of the AEAD template.
I don't think it makes sense to try and put the entirety of it in there.
There are functions that completely don't fit (such as key generation) and the
catalogue of Kerberos type values and associated parameters.
Also, I'm not sure it makes sense to try and squeeze the Integrity-type
operations get_mic and verify_mic as AEAD. get_mic might work as AEAD, but
all a wrapper would add is to emplace the checksum into ciphertext buffer.
The actual checksumming is handled by a SHASH algorithm perfectly well.
verify_mic doesn't really make sense as it has no output other than "yes/no" -
and so is also handled fine by a SHASH algorithm.
Where it does make sense is at the core of the encrypt/decrypt ops where I
have four compound ops to choose from:
- encrypt-then-hash
- hash-then-decrypt
- hash-then-encrypt
- decrypt-then-hash
These can conceivably be hardware optimised to do both parts of the op
simultaneously. I *think* I've seen a suggestion that x86_64 AVX has
sufficient registers available to do both AES and SHA simultaneously, say.
The question I then have is this: How do I parameterise the crypto algorithm
inside AEAD? Can I do something like:
cipher = crypto_alloc_sync_aead("enc-then-hash(cts(cbc(camellia)),cmac(camellia))");
David