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).
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.)
Fix get_len_step when buffer_size==0. The intent of this test is to
ensure (via static or runtime buffer overflow analysis) that
mbedtls_asn1_get_len does not attempt to access beyond the end of the
buffer. When buffer_size is 0 (reached from get_len when parsing a
1-byte buffer), the buffer is buf[1..1] because allocating a 0-byte
buffer might yield a null pointer rather than a valid pointer. In this
case the end of the buffer is p==buf+1, not buf+buffer_size which is
buf+0.
The test passed because calling mbedtls_asn1_get_len(&p,end,...) with
end < p happens to work, but this is not guaranteed.
Before the initial seeding, reseed_counter used to always be 0. Now, the
value depends on whether or not the user has explicitly set the amount
of data to get from the nonce (via e.g.
mbedtls_ctr_drbg_set_nonce_len()). Add comments to clarify the possible
values reseed_counter can have before the initial seeding.
