As a protection against the Lucky Thirteen attack, the TLS code for
CBC decryption in encrypt-then-MAC mode performs extra MAC
calculations to compensate for variations in message size due to
padding. The amount of extra MAC calculation to perform was based on
the assumption that the bulk of the time is spent in processing
64-byte blocks, which is correct for most supported hashes but not for
SHA-384. Correct the amount of extra work for SHA-384 (and SHA-512
which is currently not used in TLS, and MD2 although no one should
care about that).
Fix IAR compiler warnings
Two warnings have been fixed:
1. code 'if( len <= 0xFFFFFFFF )' gave warning 'pointless integer comparison'.
This was fixed by wraping the condition in '#if SIZE_MAX > 0xFFFFFFFF'.
2. code 'diff |= A[i] ^ B[i];' gave warning 'the order of volatile accesses is undefined in'.
This was fixed by read the volatile data in temporary variables before the computation.
Explain IAR warning on volatile access
Consistent use of CMAKE_C_COMPILER_ID
The cast to void was motivated by the assumption that the functions only
return non-zero when passed bad arguments, but that might not be true of
alternative implementation, for example on hardware failure.
- need HW failure codes too
- re-use relevant poly codes for chachapoly to save on limited space
Values were chosen to leave 3 free slots at the end of the NET odd range.
That's what it is. So we shouldn't set a block size != 1.
While at it, move call to chachapoly_update() closer to the one for GCM, as
they are similar (AEAD).
This reduces clutter, making the functions more readable.
Also, it makes lcov see each line as covered. This is not cheating, as the
lines that were previously seen as not covered are not supposed to be reached
anyway (failing branches of the selftests).
Thanks to this and previous test suite enhancements, lcov now sees chacha20.c
and poly1305.c at 100% line coverage, and for chachapoly.c only two lines are
not covered (error returns from lower-level module that should never happen
except perhaps if an alternative implementation returns an unexpected error).
This module used (len, pointer) while (pointer, len) is more common in the
rest of the library, in particular it's what's used in the GCM API that
very comparable to it, so switch to (pointer, len) for consistency.
Note that the crypt_and_tag() and auth_decrypt() functions were already using
the same convention as GCM, so this also increases intra-module consistency.
This module used (len, pointer) while (pointer, len) is more common in the
rest of the library, in particular it's what's used in the CMAC API that is
very comparable to Poly1305, so switch to (pointer, len) for consistency.
In addition to making the APIs of the various AEAD modules more consistent
with each other, it's useful to have an auth_decrypt() function so that we can
safely check the tag ourselves, as the user might otherwise do it in an
insecure way (or even forget to do it altogether).
While the old name is explicit and aligned with the RFC, it's also very long,
so with the mbedtls_ prefix prepended we get a 31-char prefix to each
identifier, which quickly conflicts with our 80-column policy.
The new name is shorter, it's what a lot of people use when speaking about
that construction anyway, and hopefully should not introduce confusion at
it seems unlikely that variants other than 20/1305 be standardised in the
foreseeable future.
- in .h files: only put the context declaration inside the #ifdef _ALT
(this was changed in 2.9.0, ie after the original PR)
- in .c file: only leave selftest out of _ALT: even though some function are
trivial to build from other parts, alt implementors might want to go another
way about them (for efficiency or other reasons)
