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).
The splitting of this test into two versions depending on whether SHA-1 was
allowed by the server was a mistake in
5d2511c4d4 - the test has nothing to do with
SHA-1 in the first place, as the server doesn't request a certificate from
the client so it doesn't matter if the server accepts SHA-1 or not.
psa_hash_compare is tested for good cases and invalid-signature cases
in hash_compute_compare. Also test invalid-argument cases. Also run a
few autonomous test cases with valid arguments.
Whether a parameter should be const is an implementation detail of the
function, so don't declare a parameter of psa_hash_compare as
const. (This only applies to parameters themselves, not to objects
that pointer parameters points to.)
While the whole script makes (often implicit) assumptions about the version of
GnuTLS used, generally speaking it should work out of the box with the version
packaged on our reference testing platform, which is Ubuntu 16.04 so far.
With the update from Jan 8 2020 (3.4.10-4ubuntu1.6), the patches for rejecting
SHA-1 in certificate signatures were backported, so we should avoid presenting
SHA-1 signed certificates to a GnuTLS peer in ssl-opt.sh.