Let the caller decide what certificates and keys are loaded (EC/RSA)
instead of loading both for the server, and an unspecified one
for the client. Use only DER encoding.
For each of the crypto-only presets, run the build and check that the
resulting libmbedx509 and libmbedtls are empty.
Don't bother testing, because for each crypto-only preset, another
component builds that plus the x509 and tls parts and tests
everything.
Adapt to the change of encoding of elliptic curve key types in PSA
crypto. Before, an EC key type encoded the TLS curve identifier. Now
the EC key type only includes an ad hoc curve family identifier, and
determining the exact curve requires both the key type and size. This
commit moves from the old encoding and old definitions from
crypto/include/mbedtls/psa_util.h to the new encoding and definitions
from the immediately preceding crypto submodule update.
Previously in d8752858fc:
* #333: Streamline PSA key type encodings: prepare
* #323: Initialise return values to an error
Previously in dbcb44202c:
* #291: Test MBEDTLS_CTR_DRBG_USE_128_BIT_KEY
* #334: Fix some pylint warnings
Previously in ceceedb532:
* #348: Bump version to Mbed TLS 2.20.0 and crypto SO version to 4
* #354: Fix incrementing pointer instead of value
In this commit:
* #349: Fix minor defects found by Coverity
* #179: Add option to build SHA-512 without SHA-384
* #327: Implement psa_hash_compute and psa_hash_compare
* #330: Streamline PSA key type and curve encodings
We already have a specific component in all.sh for testing SSLv3, we don't
need to also test it in components that aren't specifically about it.
Previously config.py full enabled SSLv3, but it no longer does since it is
deprecated.
If psa_key_agreement_ecdh fails, there may be output that leaks
sensitive information in the output buffer. Zeroize it.
If this is due to an underlying failure in the ECDH implementation, it
is currently not an issue since both the traditional Mbed TLS/Crypto
implementation and Everest only write to the output buffer once every
intermediate step has succeeded, but zeroizing is more robust. If this
is because the recently added key size check fails, a leak could be a
serious issue.
Change the encoding of key types, EC curve families and DH group
families to make the low-order bit a parity bit (with even parity).
This ensures that distinct key type values always have a Hamming
distance of at least 2, which makes it easier for implementations to
resist single bit flips.
All key types now have an encoding on 32 bits where the bottom 16 bits
are zero. Change to using 16 bits only.
Keep 32 bits for key types in storage, but move the significant
half-word from the top to the bottom.
Likewise, change EC curve and DH group families from 32 bits out of
which the top 8 and bottom 16 bits are zero, to 8 bits only.
Reorder psa_core_key_attributes_t to avoid padding.
Remove the values of curve encodings that are based on the TLS registry
and include the curve size, keeping only the new encoding that merely
encodes a curve family in 8 bits.
Keep the old constant names as aliases for the new values and
deprecate the old names.
Define constants for ECC curve families and DH group families. These
constants have 0x0000 in the lower 16 bits of the key type.
Support these constants in the implementation and in the PSA metadata
tests.
Switch the slot management and secure element driver HAL tests to the
new curve encodings. This requires SE driver code to become slightly
more clever when figuring out the bit-size of an imported EC key since
it now needs to take the data size into account.
Switch some documentation to the new encodings.
Remove the macro PSA_ECC_CURVE_BITS which can no longer be implemented.
Change the representation of psa_ecc_curve_t and psa_dh_group_t from
the IETF 16-bit encoding to a custom 24-bit encoding where the upper 8
bits represent a curve family and the lower 16 bits are the key size
in bits. Families are based on naming and mathematical similarity,
with sufficiently precise families that no two curves in a family have
the same bit size (for example SECP-R1 and SECP-R2 are two different
families).
As a consequence, the lower 16 bits of a key type value are always
either the key size or 0.
Don't assume that the PSA encoding of elliptic curves is identical to
the TLS encoding. This is currently true but about to change.
The new implementation only works when MBEDTLS_ECP_C is defined. This
is ok because the function is only used with MBEDTLS_ECP_C defined.
Internally, use the corresponding function from psa_crypto.c instead.
Externally, this function is not used in Mbed TLS and is documented as
"may change at any time".
Don't rely on the bit size encoded in the PSA curve identifier, in
preparation for removing that.
For some inputs, the error code on EC key creation changes from
PSA_ERROR_INVALID_ARGUMENT to PSA_ERROR_NOT_SUPPORTED or vice versa.
There will be further such changes in subsequent commits.
Key types are now encoded through a category in the upper 4 bits (bits
28-31) and a type-within-category in the next 11 bits (bits 17-27),
with bit 16 unused and bits 0-15 only used for the EC curve or DH
group.
For symmetric keys, bits 20-22 encode the block size (0x0=stream,
0x3=8B, 0x4=16B).
Change the numerical encoding of values for symmetric key types to
have 0000 as the lower 16 bits. Now the lower 16 bits are only used
for key types that have a subtype (EC curve or DH group).
