Commit Graph

10 Commits

Author SHA1 Message Date
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