Commit Graph

14 Commits

Author SHA1 Message Date
Simon Wilkinson
57f7373583 krb5: Add an optional encrypt_iov function to encryption types
Add a encrypt_iov function pointer to all of our encryption types
which can be used to implement an iovec based encryption routine.

Modify krb5_encrypt_iov so that it calls the iovec based routine
if it is available.
2018-05-23 09:54:27 -04:00
Simon Wilkinson
550067f6d0 krb5: Expand list of vector types that are hashed
So that we can eventually use iovec hashes with encrypt, as well
as sign operations, add CRYPTO_TYPE_HEADER and CRYPTO_TYPE_PADDING
to the list of iovecs which will be hashed.
2018-05-23 09:54:27 -04:00
Simon Wilkinson
b9b8e76376 krb5: Stash the HMAC context in the krb5_crypto object
Store the EVP HMAC context in the krb5_crypto object so that we
don't have to allocate it for every hashing operating we perform.
2018-05-23 09:54:27 -04:00
Simon Wilkinson
e50faea7f0 krb5: Store a digest context in the crypto structure
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.
2018-05-23 09:54:27 -04:00
Simon Wilkinson
8f947638c7 krb5: Use iovecs internally for checksum verification
When verifying checksums, pass iovecs through to the individual
verify routines.
2018-05-23 09:54:27 -04:00
Simon Wilkinson
ca756f0f7f krb5: Use iovecs for internal checksum handling
Modify the signature of the checksum operation in the
krb5_checksum_type structure so that it processes iovecs rather than
solid blocks of data.

Update all of the implementations of these functions for all of the
checksum types that we support so that they process iovecs, either
by iterating through the iovec in each function, or by calling
_krb5_evp_digest_iov or _krb5_evp_hmac_iov()

Update callers of these functions so that they turn their single blocks
of data into a single iovec of the correct type before calling checksum
2018-05-23 09:54:27 -04:00
Simon Wilkinson
eb5eae59a4 krb5: Add _krb5_crypto_iov_should_sign helper function
Add a helper function which contains the knowledge about whether
a particular portion of a krb5_crypto_iovec should be signed or not.
2018-05-23 09:54:27 -04:00
Luke Howard
7b720cf61c krb5: implement draft-ietf-kitten-aes-cts-hmac-sha2-07 2016-10-08 08:17:11 +02:00
Nicolas Williams
490337f4f9 Make OpenSSL an hcrypto backend proper
This adds a new backend for libhcrypto: the OpenSSL backend.

Now libhcrypto has these backends:

 - hcrypto itself (i.e., the algorithms coded in lib/hcrypto)
 - Common Crypto (OS X)
 - PKCS#11 (specifically for Solaris, but not Solaris-specific)
 - Windows CNG (Windows)
 - OpenSSL (generic)

The ./configure --with-openssl=... option no longer disables the use of
hcrypto.  Instead it enables the use of OpenSSL as a (and the default)
backend in libhcrypto.  The libhcrypto framework is now always used.

OpenSSL should no longer be used directly within Heimdal, except in the
OpenSSL hcrypto backend itself, and files where elliptic curve (EC)
crypto is needed.

Because libhcrypto's EC support is incomplete, we can only use OpenSSL
for EC.  Currently that means separating all EC-using code so that it
does not use hcrypto, thus the libhx509/hxtool and PKINIT EC code has
been moved out of the files it used to be in.
2016-04-15 00:16:17 -05:00
Roland C. Dowdeswell
6de861263a Provide support for enctype aliases for ease of use.
This should be compatible with MIT krb5 at least from my memory.
2012-03-06 09:34:43 +00:00
Love Hörnquist Åstrand
f60ec15834 partly unify enctype/keytype since there is only enctypes 2011-07-24 14:03:08 -07:00
Love Hornquist Astrand
1bb482e168 prefix internal structures with _krb5_ 2011-03-12 13:50:39 -08:00
Love Hornquist Astrand
03806492d9 prefix symbols that are _krb5_ structures 2011-03-12 13:45:09 -08:00
Simon Wilkinson
1d9072f026 krb5: reorganise crypto.c
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.
2010-11-03 11:12:24 +00:00