There was no test case of ECDH with anything other than
PSA_ALG_SELECT_RAW. Exercise the code path from ECDH through a
"proper" KDF.
ECDH shared secret copied from an existing test, HKDF output
calculated with Cryptodome.
In ECDH key agreement, allow a public key with the OID id-ECDH, not
just a public key with the OID id-ecPublicKey.
Public keys with the OID id-ECDH are not permitted by psa_import_key,
at least for now. There would be no way to use the key for a key
agreement operation anyway in the current API.
Add test cases that do key agreement with raw selection in pieces, to
validate that selection works even when the application doesn't read
everything in one chunk.
A key selection algorithm is similar to a key derivation algorithm in
that it takes a secret input and produces a secret output stream.
However, unlike key derivation algorithms, there is no expectation
that the input cannot be reconstructed from the output. Key selection
algorithms are exclusively meant to be used on the output of a key
agreement algorithm to select chunks of the shared secret.
On key import and key generation, for RSA, reject key sizes that are
not a multiple of 8. Such keys are not well-supported in Mbed TLS and
are hardly ever used in practice.
The previous commit removed support for non-byte-aligned keys at the
PSA level. This commit actively rejects such keys and adds
corresponding tests (test keys generated with "openssl genrsa").
We had only allocated 40 bytes for printing into, but we wanted to print 46
bytes. Update the buffer to be 47 bytes, which is large enough to hold what
we want to print plus a terminating null byte.
Simplify the test case "PSA export a slot after a failed import of an
EC keypair": use an invalid private value for the specified curve. Now
the dependencies match the test data, so this fixes curves.pl.
Update some test data from the asymmetric_apis_coverage branch that
wasn't updated to the new format from the
psa-asymmetric-format-raw_private_key branch.
1. New test for testing bad order of hash function calls.
2. Removed test hash_update_bad_paths since it's test scenario
was moved to the new test.
3. Moved some scenarios from test hash_verify_bad_paths to
the new test.
1. Rename hash_bad_paths to hash_verify_bad_paths
2. Add test hash_update_bad_paths
3. Add test hash_finish_bad_paths
The different scenarios tested as part of hash_bad_paths are
moved to the relevant test.
This commit introduces variants test-ca_utf8.crt,
test-ca_printablestring.crt and test-ca_uppercase.crt
of tests/data_files/test-ca.crt which differ from
test-ca.crt in their choice of string encoding and
upper and lower case letters in the DN field. These
changes should be immaterial to the recovation check,
and three tests are added that crl.pem, which applies
to test-ca.crt, is also considered as applying to
test-ca_*.crt.
The test files were generated using PR #1641 which
- adds a build instruction for test-ca.crt to
tests/data_files/Makefile which allows easy
change of the subject DN.
- changes the default string format from `PrintableString`
to `UTF8String`.
Specifically:
- `test-ca_utf8.crt` was generated by running
`rm test-ca.crt && make test-ca.crt`
on PR #1641.
- `test-ca_uppercase.crt`, too, was generated by running
`rm test-ca.crt && make test-ca.crt`
on PR #1641, after modifying the subject DN line in the build
instruction for `test-ca.crt` in `tests/data_files/Makefile`.
- `test-ca_printable.crt` is a copy of `test-ca.crt`
because at the time of this commit, `PrintableString` is
still the default string format.
This commit introduces variants test-ca_utf8.crt,
test-ca_printablestring.crt and test-ca_uppercase.crt
of tests/data_files/test-ca.crt which differ from
test-ca.crt in their choice of string encoding and
upper and lower case letters in the DN field. These
changes should be immaterial to the recovation check,
and three tests are added that crl.pem, which applies
to test-ca.crt, is also considered as applying to
test-ca_*.crt.
streamline the API for the test test_derive_invalid_generator_state: by removing
the key_data parameter.
This parameter is not important for test flow and can be hard-coded.
Add boundary test cases for private key validity for a short
Weierstrass curve (0 < d < n).
Remove obsolete test cases "valid key but wrong curve". With the new
format, the private key representation does not contain an encoding of
the curve.
In preparation for the import/export format change for private
elliptic curve keys from RFC 5915 to the raw secret value,
remove ASN.1-based sanity checks. For the raw secret value, most byte
strings of the correct length are valid (the details depend on the
curve), so as a sanity check, just check the length.
In preparation for the import/export format change for private
elliptic curve keys from RFC 5915 to the raw secret value, transform the
test data to the new format.
Tests will not pass until the implementation has been changed to the
new format and some test cases and test functions have been adjusted.
I used the script below to look for lines containing a
PSA_KEY_TYPE_ECC_KEYPAIR and change the first hex string in the
line with an ASN.1 header that looks like the beginning of an RFC 5915
ECPrivateKey. This always happens to be a private key input.
perl -a -F: -i -pe 'sub pad { local ($_) = @_; s/^00// if length == $digits + 2; die if length > $digits; sprintf("\"%0${digits}s\"", $_) } if ($F[0] !~ /\W/ && /:PSA_KEY_TYPE_ECC_KEYPAIR\( *PSA_ECC_CURVE_[A-Z_]+([0-9]+)/) {$digits = int(($1+7)/8)*2; s/"30(?:[0-7].|81..|82....)02010104(..)([0-9a-f]+)"/pad(substr($2, 0, hex($1)*2))/ie}' tests/suites/test_suite_psa_crypto.data
In the test function for export_public_key, don't just check the
length of the result. Compare the actual result to the expected
result.
Take an extra argument that allows using an export buffer that's
larger or smaller than needed. Zero is the size given by
PSA_KEY_EXPORT_MAX_SIZE.
Don't check the output of psa_get_key_information. That's useful in
import_export because it tests both import and export, but not in
import_export_public_key whose goal is only to test public key export.
This commit adjusts the existing test data but does not add new test
cases.
Key derivation test now uses an indirect way to test generator validity
as the direct way previously used isn't compatible with the PSA IPC
implementation. Additional bad path test for the generator added
to check basic bad-path scenarios.
Add comments noting that the maximum length of a MAC must fit in
PSA_ALG_MAC_TRUNCATION_MASK. Add a unit test that verifies that the
maximum MAC size fits.
Extend the mbedtls_mpi_is_prime_det test to check that it reports
the number as prime when testing rounds-1 rounds, then reports the
number as composite when testing the full number of rounds.
When using a primality testing function the tolerable error rate depends
on the scheme in question, the required security strength and wether it
is used for key generation or parameter validation. To support all use
cases we need more flexibility than what the old API provides.
Primality tests have to deal with different distribution when generating
primes and when validating primes.
These new tests are testing if mbedtls_mpi_is_prime() is working
properly in the latter setting.
The new tests involve pseudoprimes with maximum number of
non-witnesses. The non-witnesses were generated by printing them
from mpi_miller_rabin(). The pseudoprimes were generated by the
following function:
void gen_monier( mbedtls_mpi* res, int nbits )
{
mbedtls_mpi p_2x_plus_1, p_4x_plus_1, x, tmp;
mbedtls_mpi_init( &p_2x_plus_1 );
mbedtls_mpi_init( &p_4x_plus_1 );
mbedtls_mpi_init( &x ); mbedtls_mpi_init( &tmp );
do
{
mbedtls_mpi_gen_prime( &p_2x_plus_1, nbits >> 1, 0,
rnd_std_rand, NULL );
mbedtls_mpi_sub_int( &x, &p_2x_plus_1, 1 );
mbedtls_mpi_div_int( &x, &tmp, &x, 2 );
if( mbedtls_mpi_get_bit( &x, 0 ) == 0 )
continue;
mbedtls_mpi_mul_int( &p_4x_plus_1, &x, 4 );
mbedtls_mpi_add_int( &p_4x_plus_1, &p_4x_plus_1, 1 );
if( mbedtls_mpi_is_prime( &p_4x_plus_1, rnd_std_rand,
NULL ) == 0 )
break;
} while( 1 );
mbedtls_mpi_mul_mpi( res, &p_2x_plus_1, &p_4x_plus_1 );
}
Pass the nonce first, then the AD, then the input. This is the order
in which the data is processed and it's the order of the parameters to
the API functions.
Add signing tests with 528-bit and 520-bit RSA keys with SHA-512. These
selections of key and hash size should lead to an error returned, as
there is not enough room for our chosen minimum salt size of two bytes
less than the hash size. These test the boundary around an available
salt length of 0 or -1 bytes.
The RSA keys were generated with OpenSSL 1.1.1-pre8.
$ openssl genrsa 520
Generating RSA private key, 520 bit long modulus (2 primes)
.............++++++++++++
.................++++++++++++
e is 65537 (0x010001)
-----BEGIN RSA PRIVATE KEY-----
MIIBPwIBAAJCANWgb4bludh0KFQBZcqWb6iJOmLipZ0L/XYXeAuwOfkWWjc6jhGd
B2b43lVnEPM/ZwGRU7rYIjd155fUUdSCBvO/AgMBAAECQgDOMq+zy6XZEjWi8D5q
j05zpRGgRRiKP/qEtB6BWbZ7gUV9DDgZhD4FFsqfanwjWNG52LkM9D1OQmUOtGGq
a9COwQIhD+6l9iIPrCkblQjsK6jtKB6zmu5NXcaTJUEGgW68cA7PAiENaJGHhcOq
/jHqqi2NgVbc5kWUD/dzSkVzN6Ub0AvIiBECIQIeL2Gw1XSFYm1Fal/DbQNQUX/e
/dnhc94X7s118wbScQIhAMPVgbDc//VurZ+155vYc9PjZlYe3QIAwlkLX3HYKkGx
AiEND8ndKyhkc8jLGlh8aRP8r03zpDIiZNKqCKiijMWVRYQ=
-----END RSA PRIVATE KEY-----
$ openssl genrsa 528
Generating RSA private key, 528 bit long modulus (2 primes)
.........++++++++++++
....++++++++++++
e is 65537 (0x010001)
-----BEGIN RSA PRIVATE KEY-----
MIIBQgIBAAJDAKJVTrpxW/ZuXs3z1tcY4+XZB+hmbnv1p2tBUQbgTrgn7EyyGZz/
ZkkdRUGQggWapbVLDPXu9EQ0AvMEfAsObwJQgQIDAQABAkJhHVXvFjglElxnK7Rg
lERq0k73yqfYQts4wCegTHrrkv3HzqWQVVi29mGLSXTqoQ45gzWZ5Ru5NKjkTjko
YtWWIVECIgDScqoo7SCFrG3zwFxnGe7V3rYYr6LkykpvczC0MK1IZy0CIgDFeINr
qycUXbndZvF0cLYtSmEA+MoN7fRX7jY5w7lZYyUCIUxyiOurEDhe5eY5B5gQbJlW
ePHIw7S244lO3+9lC12U1QIhWgzQ8YKFObZcEejl5xGXIiQvBEBv89Y1fPu2YrUs
iuS5AiFE64NJs8iI+zZxp72esKHPXq/chJ1BvhHsXI0y1OBK8m8=
-----END RSA PRIVATE KEY-----
Since we wish to generate RSASSA-PSS signatures even when hashes are
relatively large for the chosen RSA key size, we need some tests. Our
main focus will be on 1024-bit keys and the couple key sizes larger than
it. For example, we test for a signature generated using a salt length
of 63 when a 1032-bit key is used. Other tests check the boundary
conditions around other key sizes. We want to make sure we don't use a
salt length larger than the hash length (because FIPS 186-4 requires
this). We also want to make sure we don't use a salt that is too small
(no smaller than 2 bytes away from the hash length).
Test RSASSA-PSS signatures with:
- 1024-bit key and SHA-512 (slen 62)
- 1032-bit key and SHA-512 (slen 63)
- 1040-bit key and SHA-512 (slen 64)
- 1048-bit key and SHA-512 (slen 64)
The tests also verify that we can properly verify the RSASSA-PSS
signatures we've generated.
We've manually verified that OpenSSL 1.1.1-pre8 can verify the
RSASSA-PSS signatures we've generated.
$ openssl rsa -in rsa1024.pem -pubout -out pub1024.pem
writing RSA key
$ openssl rsa -in rsa1032.pem -pubout -out pub1032.pem
writing RSA key
$ openssl rsa -in rsa1040.pem -pubout -out pub1040.pem
writing RSA key
$ openssl rsa -in rsa1048.pem -pubout -out pub1048.pem
writing RSA key
$ cat message.bin | openssl dgst -sha512 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:62 -verify pub1024.pem -signature valid1024.bin
Verified OK
$ cat message.bin | openssl dgst -sha512 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:63 -verify pub1032.pem -signature valid1032.bin
Verified OK
$ cat message.bin | openssl dgst -sha512 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:64 -verify pub1040.pem -signature valid1040.bin
Verified OK
$ cat message.bin | openssl dgst -sha512 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:64 -verify pub1048.pem -signature valid1048.bin
Verified OK
We've also added a new test that ensures we can properly validate a
RSASSA-PSS 1032-bit signature with SHA-512 generated by OpenSSL. This
has been added as the "RSASSA-PSS Verify OpenSSL-generated Signature
1032-bit w/SHA-512" test. The signature to verify was generated with the
following command line.
$ cat message.bin | openssl dgst -sha512 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:63 -sign rsa1032.pem > valid.bin
The RSA private keys used by these tests were generated with OpenSSL
1.1.1-pre8.
$ openssl genrsa 1024
Generating RSA private key, 1024 bit long modulus (2 primes)
........................................++++++
......++++++
e is 65537 (0x010001)
-----BEGIN RSA PRIVATE KEY-----
MIICWwIBAAKBgQDDyYc1SFQ1kcH5R+QSwz2la50blKWML0EKimIOm08dkZdkPr9S
f19isgK51noyZU0F8yapth4BBu/fSClnPE89I2VZluJCQFmRarR6pn5AbBKWeeWX
nKRnCIZmCP+iH2GYQ7lZtEQuQiWYovqrVKjO8fExmSZ30s9byvK1Vk90GQIDAQAB
AoGAG1BnO4i+rsaJ8DQWXoO8evJ7dZiUS+1fvo+1xGHodLCWFVcnq+O3M/avqKuC
WruFNlpIv453ux7zogvYMt3YE+ny//kgh5gUh0O1mXPbZtF4gGxsqXdV13lMW9dK
ZH2ltN94MwynrXl74m2P4uCHWIHLE9+ZyWRzwH/c/o1E4n0CQQDo+VpxbBJ9UUfc
wkGnwf6NVIez6LbpXkioMzTSHQDHmtCpDimUHAxTBlsgBZ3pXp5AYGFBb3rBLtyh
mDue4ozDAkEA1yNIspfn5dxDKfarh0sXmCWE4KtDF0Bwqb6YPA8EAyDW+JPEDScX
yzBEOAyzIwtxM2IescVaPqVtDnzuaUtd8wJAdOP3XwUsWbgYaEkHDBank12gIMJY
U8q8hbf7fpiStZOVsdyrO+a+wEFmIzDuRBL3L7Gr2lsGqjrK9EEfWN6uZQJAOJml
1Ka2cfkDCpVFB3EwIe0tClbEbeecPGxSbOqeaZxIMlnd6H/yeJiYOg7NSlkGTThx
Tt/XIEgxavBfYQBdFQJAMFmLr9DL5lWAZNAHspJ8R5NdoOcsrKV9tb24cu0YapuZ
rSPwmebskHyinvoBsD2CthUtpSo3NE+xZ6HcfYca9w==
-----END RSA PRIVATE KEY-----
$ openssl genrsa 1032
Generating RSA private key, 1032 bit long modulus (2 primes)
....................++++++
.................................++++++
e is 65537 (0x010001)
-----BEGIN RSA PRIVATE KEY-----
MIICYAIBAAKBggCqlKuRtMJr4lfkaVKCKMSwtrTJnnOoSicrMQGJLAdAaRE3K4Ps
SnuBkfC6S0y0yztzIHTpbGaCl+EyO4rQgip+FRGC3vA4caZqR7cEuShFxhlBQtTu
2hmQPgQENYH3qDXcKIEXhj0hlEw67e1RhFjxowpBx2OKpOCYqI/fLCCXJw0CAwEA
AQKBgWcY+CFWePOvl6OrrHySm16a7uW06P5b4xSNx/naLH/XgNoxaMiVs9P6Gt7d
x/y1oLbSdRbnt4VSun8b0ah4I6qEyk3MdfiNnhy24LlCuv0TOLbQVibjH+5Q+iP2
995ssUrkfPa/QAA95nPVaDhcsATSh32JagE0rkItukalyc/IGQJBDfrttwmtohBS
I+XndkpfMdB656N73HtKVsJJnhFzFHvNyxZbj7AaJSgZDLaHRlapNkkYmPyjMNuK
9antVBcmjtcCQQwznFZ5epDGQSklYNDvZ19xrCyZ/KumJgw45PFn39F563qeJV+b
28VJ5BgfmioZsfMKgLKS1e8a11ueZY6qb7C7AkEExSw7mmfOtrbwXNAfwry8qKBn
TZdD4iW5eM3Zy6ZyxNOxik1vt+0T5Jy3g8igrY1LYqGsAfhFAYRm0raSTNvxPQJB
AUcOIYfKq4n2nKZLQtUuT7IJQwpEiHx3E2SJpDUqHDbVzxrr8tzQ4BFijpwQekQC
e94np4r0V3rJ/c/R9mQmGa0CQQrd2veAgj1F7Rma7zE4vYhvCf0XB1rshw972xGo
BTAU4BagC7/vht1YXhhdz1FC36DrWm3veTwLLuNUQTJWsYIH
-----END RSA PRIVATE KEY-----
$ openssl genkey 1040
Generating RSA private key, 1040 bit long modulus
........++++++
........++++++
e is 65537 (0x10001)
-----BEGIN RSA PRIVATE KEY-----
MIICZgIBAAKBgwDSNAU4Ix3NWmHt+Dq5Sy5LOnhDlMTtNaQkwFDClBV7diX5rKgl
jCHi0Keqm3ydtXZATmMJDbpQ2Zj5o+xysaXPKNgyUauTNBx9LBqQQD1w9nvBqeQT
vGL6zMtSRB4kw/K8n97KGngwEucLlSgXYmBYDE4QJsWCCejcxN478/W+VWXpAgMB
AAECgYMAutjQ1uCoKhSwPgbLtE92vBoiMvh3v99Ro/VrFDrriY4xHWlzIcUZjfMp
Rsblk45sqabD85VHS3zQtP8YO69bkvK+r5upGfzLtzX8r5BVuO1+7oO+/jbRHLYJ
ieBoFZbUc27YcKzR35Iv78d+KjygYIsWgt7W2Yqf6qt98r43WcrYsQJCAPx/S0kL
TT73Kdsj+1r7tfL8YgpHI0LYuP8xDP3BJL523CKrb0vjWjjd0x8k1/ZNMQ9nqzo3
XoP04FWeTLXcQ+h1AkIA1R6GgKtx3AHhqKaKKYY2uxZYz6uNc85SimJpdyLUhauQ
za/F4ndot2GDn/k0IEWK5V8VppRl28DHtSTcmjhf+SUCQT4RVIJaItztiP5zc+BD
q9BVNgxsvEA8Yg1pE1Z1WgDv2uEy3yL6ej0sWi93sRa8lujAhRjEb5lkYpjpVtYF
lTPZAkIAlt1yB3nWMxEd5l5mZbi927iZDAF8M+N1aML7t7tvSGTIL+LjKUqwVUhx
ffhSXxn7lh22XOKmLGcOuHussnt/7QUCQS2GWdSBu7DGZ5uIvZVj+5KPTwv3Pw9+
uuj12Z3shojl1iVije7nsBK1q3NbrXksEiQ4QJIoK2V2quqD58O2/K8T
-----END RSA PRIVATE KEY-----
$ openssl genrsa 1048
Generating RSA private key, 1048 bit long modulus (2 primes)
...............................++++++
.++++++
e is 65537 (0x010001)
-----BEGIN RSA PRIVATE KEY-----
MIICaQIBAAKBhADHXQ+foX0dJLk5U3pDQBfzkMZgRETDWhM2DWsfyYa69AFZuEJ1
03uIMnjfUGTdnrDymw0yWsx5DEtZZyc32786y4j14vLVTJGcr9ByJyxJRZHVLhWJ
kzFeceLKYLHHT+/489d4QrQV1OcXNKSYIGpc2TFch7I+WD4l60ypcFa0XJaFbQID
AQABAoGDSqKtUa6sXze7XBnDYN/i151wluOX9qaHIKo/W4Qfu2fUBZm0z9Wfnqp+
k+PODyX0yq5/b0WM3RhcMRksFn5fBgzYHEmAj8IHhDsjavNtiv8nIl6EF2PfuT1p
6iEpo8IS15dp6j5AKH4Zmnq6TRYiqdaz/ry/kpQrmeJym83KksujZWUCQg85t5gJ
UWvswuNIG2tHWEqiKZvSAnq4owO53lsK3LSl04447bjB+sPqHb1+HVC4QyPjYs/0
3z9aUYLa+pu5IXpz1wJCDRgWT4vQ1Y0BmZjIyxfEwDVOYripRirMowgWiU+YLCrh
FOc5k+MGmJMEN7TuxErewk0yzLy658xMn4kRseshAGhbAkIBClKPIuPbWfwfB4hI
FkHkJ5xsNzdQJ1mMIaEd22olNcd0ylMD8s0tocuSbRGXuF9uDlVsHDE85PD43fmN
tmKhOVUCQgG6H5c2VcEU7BUaNcGzzNudLE2RFaKPmpYWRwKtYODSdwWOyeVbmE8f
dPrz/lodlewCyqR+cBiKtcCFD7Rr0tp+6QJCALZlz954leZ6UKkdeOiTb+fVFpsq
DNNALCL4VJ7XcJJMpjgSKYv9sr1C43nifr1M4YDH+B3NFRF+FWdVodaseOKF
-----END RSA PRIVATE KEY-----
It should be valid to RSASSA-PSS sign a SHA-512 hash with a 1024-bit or
1032-bit RSA key, but with the salt size being always equal to the hash
size, this isn't possible: the key is too small.
To enable use of hashes that are relatively large compared to the key
size, allow reducing the salt size to no less than the hash size minus 2
bytes. We don't allow salt sizes smaller than the hash size minus 2
bytes because that too significantly changes the security guarantees the
library provides compared to the previous implementation which always
used a salt size equal to the hash size. The new calculated salt size
remains compliant with FIPS 186-4.
We also need to update the "hash too large" test, since we now reduce
the salt size when certain key sizes are used. We used to not support
1024-bit keys with SHA-512, but now we support this by reducing the salt
size to 62. Update the "hash too large" test to use a 1016-bit RSA key
with SHA-512, which still has too large of a hash because we will not
reduce the salt size further than 2 bytes shorter than the hash size.
The RSA private key used for the test was generated using "openssl
genrsa 1016" using OpenSSL 1.1.1-pre8.
$ openssl genrsa 1016
Generating RSA private key, 1016 bit long modulus (2 primes)
..............++++++
....++++++
e is 65537 (0x010001)
-----BEGIN RSA PRIVATE KEY-----
MIICVwIBAAKBgACu54dKTbLxUQBEQF2ynxTfDze7z2H8vMmUo9McqvhYp0zI8qQK
yanOeqmgaA9iz52NS4JxFFM/2/hvFvyd/ly/hX2GE1UZpGEf/FnLdHOGFhmnjj7D
FHFegEz/gtbzLp9X3fOQVjYpiDvTT0Do20EyCbFRzul9gXpdZcfaVHNLAgMBAAEC
gYAAiWht2ksmnP01B2nF8tGV1RQghhUL90Hd4D/AWFJdX1C4O1qc07jRBd1KLDH0
fH19WocLCImeSZooGCZn+jveTuaEH14w6I0EfnpKDcpWVAoIP6I8eSdAttrnTyTn
Y7VgPrcobyq4WkCVCD/jLUbn97CneF7EHNspXGMTvorMeQJADjy2hF5SginhnPsk
YR5oWawc6n01mStuLnloI8Uq/6A0AOQoMPkGl/CESZw+NYfe/BnnSeckM917cMKL
DIKAtwJADEj55Frjj9tKUUO+N9eaEM1PH5eC7yakhIpESccs/XEsaDUIGHNjhctK
mrbbWu+OlsVRA5z8yJFYIa7gae1mDQJABjtQ8JOQreTDGkFbZR84MbgCWClCIq89
5R3DFZUiAw4OdS1o4ja+Shc+8DFxkWDNm6+C63g/Amy5sVuWHX2p9QI/a69Cxmns
TxHoXm1w9Azublk7N7DgB26yqxlTfWJo+ysOFmLEk47g0ekoCwLPxkwXlYIEoad2
JqPh418DwYExAkACcqrd9+rfxtrbCbTXHEizW7aHR+fVOr9lpXXDEZTlDJ57sRkS
SpjXbAmylqQuKLqH8h/72RbiP36kEm5ptmw2
-----END RSA PRIVATE KEY-----
This commit fixes some missing size comparison. In
aead_encrypt_decrypt, aead_encrypt and aead_decrypt, the test code
would not have noticed if the library function had reported an output
length that was not the expected length.
ASSERT_COMPARE tests that the two buffers have the same size and
content. The intended use is to replace TEST_ASSERT( size1 == size2 )
followed by memcmp on the content. Keep using memcmp when comparing
two buffers that have the same size by construction.
This commit resolves a bug whereby some test cases failed on systems
where mbedtls_calloc returns NULL when the size of 0, because the test
case asserted `pointer != NULL` regardless of the size.
The new macro ASSERT_ALLOC allocates memory with mbedtls_calloc and
fails the test if the allocation fails. It outputs a null pointer if
the requested size is 0. It is meant to replace existing calls to
mbedtls_calloc.
