Crypto IOV/non-IOV code consolidation

[Greg Hudson]

On Tue, 2009-11-17 at 15:51 -0500, ghudson at MIT.EDU wrote:
> The simplest starting point would be to take advantage of the existing
> hatch in krb5_k_encrypt, which invokes krb5int_c_encrypt_aead_compat
> if the enctype entry has no encrypt function (and likewise for
> decryption).  That would allow us to eliminate the non-IOV encryption
> code.

I tried this, and the performance penalty seems to be noticeable--around
15% for encrypt and 20% for decrypt, for 100-byte messages.  (Decrypt
has to copy both the input and the output, so it carries a larger
penalty.)

> I believe we can eliminate the need for them by using a unified internal
> interface which [takes input and output vectors]

A notable obstacle here is that we don't have IOV implementations for
the des-cbc-crc, des-cbc-md4, and des-hmac-sha1 enctypes, or for the
descbc, md4des, md5des, and md5_hmac keyhash providers.

It might be possible to handle the missing enctypes (they all correspond
to krb5int_old_encrypt) and then defer unifying the keyhash provider
interface until later.

> * krb5int_c_iov_{get,put}_block (internal functions used by the
>   enc_provider implementations) will need some massaging.

I misunderstood how these worked; I don't think they will pose an
obstacle to separating the input and output vectors.  There are already
separate input and output cursors in the block cipher IOV functions.

That said, these functions may be impacting performance since they
perform two additional copies for each block.  Perhaps they could be
adjusted to use aliases into the input and output vectors in the simple
case (where the next block fits entirely within the current vector).
I'll think about it.

> * Another bit of grossness is that gss-krb5 calls into krb5int_hmac,
>   passing a pointer to the RC4 enc_provider and the MD5 hash_provider.
>   (All three symbols are obtained via krb5int_accessor.)  I need to
>   take a good hard look at that to see whether it can be cleaned up.
>   At a minimum it will need to be adjusted since the non-IOV functions
>   it relies on will be going away.

This is resolved; there is now a single entry point into libcrypto for
GSS-style rc4 encryption, and it only uses the IOV path.