The iovec encryption code doesn't handle 0 length iovecs correctly.
Instead of just skipping them, _krb5_evp_encrypt_iov_cts() will spin
on the 0 length iovec.
Modify the _krb5_evp_iov_cursor_expand helper so that iovec expansion
simply skips 0 length iovecs, and make _krb5_evp_iov_cursor_nextcrypt
do the same.
Original bug report and tests from Andrew Bartlett <abartlet@samba.org>
Some versions of gcc can't follow the logic in the encryption path
of the _krb5_evp_encrypt_iov_cts code, and believe that it is
possible for the lastpos structure to be used uninitialised.
This isn't actually possible. On entry to the loop, remaining is
guaranteed to be both greater than, and a multiple of blocksize.
In order to exit the loop, remaining must be set to 0. If
cursor.current.length >= remaining, then we set remaining to 0 and
also set lastpos. Otherwise, we calculate the number of whole blocks
in the current iovec, which must be less than remaining, and subtract
that from remaining. Remaining must still be a multiple of and greater
than or equal to blocksize. If remaining == blocksize, we set lastpos,
and set remaining to 0. Otherwise we consume a single block, and go
around again. All of the paths which may set remaining to 0 also
set lastpos, so lastpos must be populated when the loop terminates.
Coverity has a similiar misconception, albeit with ivec2, which is
mistaken for the same reasons.
Add iovec routines for both padded CBC, and CTS EVP based encryption.
These routines go to great lengths to minimise the number of times
we call EVP_Cipher. With some EVP implementations (such as OpenSSL's
AES-NI) there is a significant entrance and exit overhead from this
routine, due to the use of SIMD vectors for the ivec.
Creating and destroying an EVP_CTX_MD structure with every hash
operation is very expensive. Speed things up by caching one within
the krb5_crypto structure. krb5_crypto can already only be safely
used by one thread at a time - adding a message digest context here
shouldn't introduce any further threading risks.
Users of the stashed context must be careful to ensure that they
call no other hash functions whilst they are in the middle of using
the context.
Add a function which will perform an HMAC over a set of iovecs,
using the hcrypto provided HMAC functions.
Join contiguous iovecs together before passing them to the hash
function so we make as few calls into the hash as possible.
lib/krb5/crypto.c was a large, monolithic block of code which made
it very difficult to selectively enable and disable particular
alogrithms.
Reorganise crypto.c into individual files for each encryption and
salt time, and place the structures which tie everything together
into their own file (crypto-algs.c)
Add a non-installed library (librfc3961) and test program
(test_rfc3961) which builds a minimal rfc3961 crypto library, and
checks that it is usable.
