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 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).
The splitting of this test into two versions depending on whether SHA-1 was
allowed by the server was a mistake in
5d2511c4d48eb197697466d1bd6b776cf09b0e7c - 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.
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.
Because two buffers were aliased too early in the code, it was possible that
after an allocation failure, free() would be called twice for the same pointer.
Previously mocked non-blocking read/write was returning 0 when buffer was empty/full. That was causing ERR_SSL_CONN_EOF error in tests which was using these mocked callbacks. Beside that non-blocking read/write was returning ERR_SSL_WANT_READ/_WRITE depending on block pattern set by test design. Such behavior forced to redesign of these functions so that they could be used in other tests
This error occurs when free space in the buffer is in the middle (the buffer has come full circle) and function mbedtls_test_buffer_put is called. Then the arguments for memcpy are calculated incorrectly and program ends with segmentation fault
Before, the string to parse may contain trailing garbage (there was
never more than one byte), and there was a separate argument
indicating the length of the content. Now, the string to parse is the
exact content, and the test code runs an extra test step with a
trailing byte added.
If there was a fatal error (bizarre behavior from the standard
library, or missing test data file), execute_tests did not close the
outcome file. Fix this.
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.
