Add two further boundary tests for cases where both the exponent and modulus to
`mbedtls_mpi_exp_mod()` are `MBEDTLS_MPI_MAX_SIZE`, or longer, bytes long.
Signed-off-by: Chris Jones <christopher.jones@arm.com>
Work in progress: next step is to test it!
Extract the part that is common with non-ext version to a new internal
function. (We can't just use the non-ext version for that, as it's going to be
deprecated.)
Currently the NIST_KW part is somewhat duplicated between the ext
and non-ext versions, but that's OK because it will soon be removed from the
non-ext version.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Work in progress: next steps are to implement and test it.
Compared to the existing non-ext version:
- to separate tag parameter
- explicit output_len parameter
Also, this version will retain support for NIST_KW (hence documents it), while
the non-ext version will lose it in a few commits.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
- Document constraints on buffers/pointers NULLability explicitly.
- Simplify terminology around IV/nonce: all AEADs implemented so far call that
a nonce. Keep the parameter names (iv, iv_len) to avoid having to change the
code (or having different names in the header and C files).
- Align documentation to the code regarding parameter constraints: the
documentation said the for ciphers with fixed nonce/tag length, the
iv_len/tag_len arguments were ignored, while the code enforced them to be the
expected value. This is more consistent with what's done with GCM/CCM, which
for tag_len for example accept more than one value, but from a relatively
small set, and will return errors for values outside that set. Accepting a
single value is a particular case of that (the set of acceptable value only
has one element).
Don't document behaviour with NIST KW as we're about to change that.
Note: this function is currently only defined if at least one of GCM, CCM or
ChachaPoly is enabled, even though it's supposed to handle NIST KW as well. No
need to fix this as the function will soon no longer support NIST KW.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
* development: (488 commits)
Fix removal of deprecated PSA constants
Use GitHub-compatible table formatting
Remove psa header files in uninstall part
Change function casting in `ssl_calc_finished_tls_sha384`
Fix GCC warning in `ssl_calc_finished_tls_sha384`
Add changelog entry file to `ChangeLog.d`
Fix GCC warning in `ssl_calc_finished_tls_sha384`
Fix GCC warning about `test_snprintf`
Fix mismatched function parameters (prototype/definition)
Fix build failure on gcc-11
Copyediting
Clarifications around key import
Fix copypasta
A variable is unused in some configurations
Rename test_driver_keygen to test_driver_key_management
Move "internal use" sentence attached to the wrong function
Added changelog
Plug in the entry point for public key export through driver
tests: psa: Reset key attributes where needed
Improve/fix documentation
...
Adds test cases to ensure that `mbedtls_mpi_exp_mod` will return an error with
an exponent or modulus that is greater than `MBEDTLS_MPI_MAX_SIZE` in size.
Adds test cases to ensure that Diffie-Hellman will fail to make a key pair
(using `mbedtls_dhm_make_public`) when the prime modulus is greater than
`MBEDTLS_MPI_MAX_SIZE` in size.
Signed-off-by: Chris Jones <christopher.jones@arm.com>
Add a test case to ensure `mbedtls_mpi_exp_mod` fails when using a key size
larger than MBEDTLS_MPI_MAX_SIZE.
Add a test case to ensure that Diffie-Hellman operations fail when using a key
size larger than MBEDTLS_MPI_MAX_SIZE.
Signed-off-by: Chris Jones <christopher.jones@arm.com>
Check that the exponent and modulus is below `MBEDTLS_MPI_MAX_BITS` before
performing a time expensive operation (modular exponentiation). This prevents
a potential DoS from Diffie-Hellman computations with extremely
large key sizes.
Signed-off-by: Chris Jones <christopher.jones@arm.com>
Removed unecessary checks on the ALG_SHA_224 and ALG_SHA_384 since
those are handled in config_psa.h by ensuring the correct _C is
included. Reformatted config_psa.h to be alphabetical and made the
assignments line up correctly for consistency. Fixed the guards
for ALG_SHA_224 and ALG_SHA_384 to be correct in the crypto library
source.
Signed-off-by: John Durkop <john.durkop@fermatsoftware.com>
The driver interfaces described in crypto_accel_driver.h and
crypto_entropy_driver.h are no longer being worked on. We do not
intend to finish the design of these interfaces or to implement them
in Mbed TLS. They have been superseded by the unified driver
interface (docs/proposed/psa-driver-interface.md), which is being
actively worked on both to finalize the specification and to implement
it in Mbed TLS.
The partially implemented dynamic secure element interface is staying
for now.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Due to a misplaced #endif, the (non-functional) macro definitions were
not properly removed from crypto_compat.h if MBEDTLS_DEPRECATED_REMOVED
was declared.
Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
New tests have been added for all the hash algorithms to
confirm they compile correctly when using PSA_WANT and
accelerator guards.
Signed-off-by: John Durkop <john.durkop@fermatsoftware.com>
This set of changes converts all the previous MBEDTLS_*_C guards in
the crypto library to use the new MBEDTLS_PSA_BUILTIN_ guards for
hash algorithms.
Signed-off-by: John Durkop <john.durkop@fermatsoftware.com>
With the addition of hash algorithms to crypto config there
are new dependencies for SHA224 and SHA384 that need to be confirmed
for those hashes to be used.
Signed-off-by: John Durkop <john.durkop@fermatsoftware.com>
When MBEDTLS_PSA_CRYPTO_CONFIG is disabled, if an Mbed TLS crypto
feature is enabled, declare the corresponding PSA feature as enabled,
in addition to enabling its software implementation. This is necessary
for code that uses PSA APIs and relies on PSA_WANT_xxx symbols to know
which features are enabled (application code, our library code using
MBEDTLS_USE_PSA_CRYPTO, our test dependencies, etc.).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add missing tag check for algorithm parameters when comparing the
signature in the description part of the cert against the actual
signature whilst loading a certificate. This was found by a
certificate (created by fuzzing) that openssl would not verify, but
mbedtls would.
Regression test added (one of the client certs modified accordingly)
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
mbedtls_ctr_drbg_set_reseed_interval() and
mbedtls_hmac_drbg_set_reseed_interval() can now be called before
their seed functions and the reseed_interval value will persist.
Previously it would be overwritten with the default value.
*_drbg_reseed_interval is now set in init() and free().
mbedtls_ctr_drbg_free() and mbedtls_hmac_drbg_free() now
reset the drbg context to the state immediately after init().
Tests:
- Added test to check that DRBG reseeds when reseed_counter
reaches reseed_interval, if reseed_interval set before seed
and reseed_interval is less than MBEDTLS_CTR_DRBG_RESEED_INTERVAL.
Signed-off-by: gacquroff <gavina352@gmail.com>
Positive tests: test that the RNG has the expected size, given that we
know how many leading zeros it has because we know how the function
consumes bytes and when the test RNG produces null bytes.
Negative tests: test that if the RNG is willing to emit less than the
number of wanted bytes, the function fails.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The return values of the functions are updated in the documetation.
All possible return values are added including nested functions' return
values. The values which cannot be returned are removed.
Signed-off-by: gabor-mezei-arm <gabor.mezei@arm.com>
`finish_sha384_t` was made more generic by using `unsigned char*`
instead of `unsigned char[48]` as the second parameter.
This change tries to make the function casting more robust against
future improvements of gcc analysis.
Signed-off-by: Rodrigo Dias Correa <rodrigo@correas.us>
This commit fixes the same warning fixed by baeedbf9, but without
wasting RAM. By casting `mbedtls_sha512_finish_ret()`, `padbuf`
could be kept 48 bytes long without triggering any warnings.
Signed-off-by: Rodrigo Dias Correa <rodrigo@correas.us>
GCC 11 generated a warning because `padbuf` was too small to be
used as an argument for `mbedtls_sha512_finish_ret`. The `output`
parameter of `mbedtls_sha512_finish_ret` has the type
`unsigned char[64]`, but `padbuf` was only 48 bytes long.
Even though `ssl_calc_finished_tls_sha384` uses only 48 bytes for
the hash output, the size of `padbuf` was increased to 64 bytes.
Signed-off-by: Rodrigo Dias Correa <rodrigo@correas.us>
GCC 11 generated the warnings because the parameter `ret_buf`
was declared as `const char[10]`, but some of the arguments
provided in `run_test_snprintf` are shorter literals, like "".
Now the type of `ret_buf` is `const char *`.
Both implementations of `test_snprintf` were fixed.
Signed-off-by: Rodrigo Dias Correa <rodrigo@correas.us>
In GCC 11, parameters declared as arrays in function prototypes
cannot be declared as pointers in the function definition. The
same is true for the other way around.
The definition of `mbedtls_aes_cmac_prf_128` was changed to match
its public prototype in `cmac.h`. The type `output` was
`unsigned char *`, now is `unsigned char [16]`.
In `ssl_tls.c`, all the `ssl_calc_verify_*` variants now use pointers
for the output `hash` parameter. The array parameters were removed
because those functions must be compatible with the function pointer
`calc_verify` (defined in `ssl_internal.h`).
Signed-off-by: Rodrigo Dias Correa <rodrigo@correas.us>
If the file is read correctly, but it contains data that isn't valid,
the crypto storage code returns PSA_ERROR_DATA_INVALID.
The PSA_ERROR_DATA_CORRUPT and PSA_ERROR_STORAGE_FAILURE error codes are
replaced with PSA_ERROR_DATA_INVALID, except in the ITS subsystem.
Signed-off-by: gabor-mezei-arm <gabor.mezei@arm.com>
Rework the section describing key import, in particular to clarify key
size determination and checking. There is no intended semantic change.
Note an open question around support for implementation-specific
import formats.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
