The sample program aescrypt2 shows bad practice: hand-rolled CBC
implementation, CBC+HMAC for AEAD, hand-rolled iterated SHA-2 for key
stretching, no algorithm agility. The new sample program pbcrypt does
the same thing, but better. So remove aescrypt2.
Fix#1906
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Made a mistake when copy-pasting and put the guard in the wrong place.
Fix that by moving the compile time guard.
Signed-off-by: Chris Jones <christopher.jones@arm.com>
This function was introduced before ssl_test_common_source.c and so the
function is replicated in both ssl_client2.c and ssl_server2.c. Move
the function to ssl_test_common_source.c to avoid duplication.
Signed-off-by: Chris Jones <christopher.jones@arm.com>
Remove some accidental newlines that were added previously.
Update some definition guards to make it clearer that
`MBEDTLS_X509_REMOVE_INFO` is defined and not undefined.
Signed-off-by: Chris Jones <christopher.jones@arm.com>
The new compile-time option MBEDTLS_X509_REMOVE_INFO removes various
X.509 debugging strings and functionality, including
```
mbedtls_x509_crt_verify_info()
```
which ssl_client2.c and ssl_server2.c use to print human readable
descriptions of X.509 verification failure conditions. Those
conditions are also grepped for in numerous ssl-opt.sh tests.
Instead of disabling those tests if MBEDTLS_X509_REMOVE_INFO is set,
this commit essentially moves mbedtls_x509_crt_verify_info() to
ssl_client2.c and ssl_server2.c. However, instead of just copy-pasting
the code from x509_crt.c, the following approach is used:
A macro MBEDTLS_X509_CRT_ERROR_INFO_LIST is introduced which for each
verification failure condition invokes a user-defined macro X509_CRT_ERROR_INFO
with (a) the numerical error code, (b) the string presentation of the
corresponding error macro, (c) the info string for the error condition.
This macro can thus be used to generate code which somehow iterates over
the verifiation failure conditions, but the list of error conditions and
information strings is nowhere duplicated.
This is then used to re-implement mbedtls_x509_crt_verify_info() in
x509_crt.c and to provide a functionally equivalent (yet slightly different)
version in ssl_client2.c and ssl_server2.c in case MBEDTLS_X509_REMOVE_INFO
is set.
This way, little changes to ssl-opt.sh will be necessary in case
MBEDTLS_X509_REMOVE_INFO is set because the info strings for the
verification failure conditions will be printed regardless of whether
MBEDTLS_X509_REMOVE_INFO is set or not.
Signed-off-by: Hanno Becker <hanno.becker@arm.com>
The introduction of positive options to control the presence
of pre-existing functionality breaks the build for users of
handwritten configurations.
Signed-off-by: Hanno Becker <hanno.becker@arm.com>
Introduce MBEDTLS_X509_INFO to indicate the availability of the
mbedtls_x509_*_info() function and closely related APIs. When this is
not defined, also omit name and description from
mbedtls_oid_descriptor_t, and omit OID arrays, macros, and types that
are entirely unused. This saves several KB of code space.
Signed-off-by: Hanno Becker <hanno.becker@arm.com>
Signed-off-by: Chris Jones <christopher.jones@arm.com>
According to the design in psa-driver-interface.md. Compiles without
issue in test_psa_crypto_drivers.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
Call it “SHAKE256-512”, just like SHA3-512 has 512 bits of output.
SHAKE256-64 looks like it's 64 bits of output, but this is 64 bytes.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Define algorithms for PureEdDSA and for HashEdDSA, the EdDSA variants
defined by RFC 8032.
The encoding for HashEdDSA needs to encode the hash algorithm so that
the hash can be calculated by passing PSA_ALG_SIGN_GET_HASH(sig_alg)
to psa_hash_compute() or psa_hash_setup(). As a consequence,
Ed25519ph (using SHA-512) and Ed448ph (using SHAKE256) need to have
different algorithm encodings (the key is enough to tell them apart,
but it is not known while hashing). Another consequence is that the
API needs to recognize the Ed448 prehash (64 bytes of SHAKE256 output)
as a hash algorithm.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add an elliptic curve family for the twisted Edwards curves
Edwards25519 and Edwards448 ("Goldilocks"). As with Montgomery curves,
since these are the only two curves in common use, the family has a
generic name.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
