Now that ETYPE_xxx names are macros to the KRB5_ENCTYPE_xxx
symbols there is no longer a need to cast to (krb5_enctype).
Change-Id: Ib561f6e45346abac7a53eb1db0bfef60ee3bcb74
AES256 and AES128 are newer enctypes because they are officially
specified in RFC4120 and RFC8009, while enctypes not officially
specified since RFC4120 are considered older. This function differs from
older_enctype() in that it does not report unknown or non-existent
enctypes as being 'newer'.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Make keyed checksums mandatory when generating and verifying checksums, with
the following exceptions:
* the checksum is being generated or verified as part of encrypting data for
a legacy (DES) encryption type
* the KRB5_CRYPTO_FLAG_ALLOW_UNKEYED_CHECKSUM flag was set on the crypto
context, used to allow unkeyed checksums in krb5 authenticators
By making unkeyed checksums opt-in, we eliminate a class of potential
vulnerabilities where callers could pass unkeyed checksums.
Any code that uses the mandatory checksum type for a given non-legacy
encryption type should not be affected by this change. It could potentially
break, say, a client trying to do FAST with DES keys but, that should not be
supported (because FAST KDCs also support AES).
Closes: #835
Add unkeyed checksum types for SHA-256, SHA-384 and SHA-512, for future
internal use. They are assigned private (negative) checksum types and must
never appear in cleartext on the wire.
When we have an underlying iovec encryption function, use iovecs for
checksum-then-encrypt alogrithms in decrypt_iov_ivec, rather than
coalescing iovecs into a single memory buffer.
Add a verify operation for this checksum. If a verify operation isn't
defined, then the verify_checksum code has to dynamically allocate and
free a block of memory for the computed checksum, which can be a
significant overhead when performing bulk data encryption.
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.
Use the iovec checksum routines in krb5_encrypt_iov_ivec. This
still marshalls all of the iovecs together to perform the encryption
operation, but this change halves the amount of time spent on
data marshalling in this function.
When we decide we need to zero the padding iovec, do so with 0, not
with the length that we've determined.
This had no effect because we zero the padding properly later, but it
should be fixed, so that things still work when the later memset() goes
away.
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.
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.
Instead of flattening the iovecs passed into
krb5_verify_checksum_iov, create a new internal verify_checksum_iov
function which passes iovecs down onto the individual ->verify or
->checksum functions.
_krb5_find_enctype is a moderately expensive operation, as it
does a linear search of the enctype lists. Avoid calling it
in _key_schedule when we already have a key schedule in place.
This change makes the most common check the first in the function.
Rather than flattening the iovecs supplied to
krb5_create_checksum_iov into a malloc()'d memory block, refactor
the function so that they can be passed straight through to the
backend hash functions.
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
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
(cherry picked from Samba commit 05cc099499ef3a07d140981ef82937c842a3ffef)
It is necessary to use the RFC3961 random_to_key operation when
creating a key from a bitstring.
Signed-off-by: Nicolas Williams <nico@cryptonector.com>
This reverts commit c25af51232 because
otherwise we could attempt to check a CKSUMTYPE_HMAC_SHA1_96_AES_256 key with a
KRB5_ENCTYPE_ARCFOUR_HMAC_MD5 key.
Andrew Bartlett
Signed-off-by: Love Hornquist Astrand <lha@h5l.org>
1. on errors, it appears to core dump, and
2. the sense of the return code is inverted from the
MIT implementation.
Signed-off-by: Love Hörnquist Åstrand <lha@h5l.org>
Start to explain what the replacement function is.
Generate the #define/#undef logic in generated header files.
Use gcc style where the deprecation warning is after the prototype.
