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-----
Setting the dh_flag to 1 used to indicate that the caller requests safe
primes from mbedtls_mpi_gen_prime. We generalize the functionality to
make room for more flags in that parameter.
OFB and CFB are streaming modes. XTS is a not a cipher mode but it
doesn't use a separate padding step. This leaves only CBC as a block
cipher mode that needs a padding step.
Since CBC is the only mode that uses a separate padding step, and is
likely to remain the only mode in the future, encode the padding mode
directly in the algorithm constant, rather than building up an
algorithm value from a chaining mode and a padding mode. This greatly
simplifies the interface as well as some parts of the implementation.
Mbed TLS distinguishes "invalid padding" from "valid padding but the
rest of the signature is invalid". This has little use in practice and
PSA doesn't report this distinction. We just report "invalid
signature".
There were only 5 categories (now 4). Reduce the category mask from 7
bits to 3.
Combine unformatted, not-necessarily-uniform keys (HMAC, derivation)
with raw data.
Reintroduce a KEY_TYPE_IS_UNSTRUCTURED macro (which used to exist
under the name KEY_TYPE_IS_RAW_DATA macro) for key types that don't
have any structure, including both should-be-uniform keys (such as
block cipher and stream cipher keys) and not-necessarily-uniform
keys (such as HMAC keys and secrets for key derivation).
The last slot in the array was not freed due to an off-by-one error.
Amend the fill_slots test to serve as a non-regression test for this
issue: without this bug fix, it would cause a memory leak.
MBEDTLS_PK_WRITE_C only requires either MBEDTLS_RSA_C or MBEDTLS_ECP_C to be defined.
Added wrappers to handle the cases where only one has been defined.
Moved mbedtls_pk_init to be within the ifdefs, so it's only called if appropriate.
In psa_generator_import_key, if generating a DES or 3DES key, set the
parity bits.
Add tests for deriving a DES key. Also test deriving an AES key while
I'm at it.
In psa_generator_hkdf_read, return BAD_STATE if we're trying to
construct more output than the algorithm allows. This can't happen
through the API due to the capacity limit, but it could potentially
happen in an internal call.
Also add a test case that verifies that we can set up HKDF with its
maximum capacity and read up to the maximum capacity.
New key type PSA_KEY_TYPE_DERIVE. New usage flag PSA_KEY_USAGE_DERIVE.
New function psa_key_derivation.
No key derivation algorithm is implemented yet. The code may not
compile with -Wunused.
Write some unit test code for psa_key_derivation. Most of it cannot be
used yet due to the lack of a key derivation algorithm.
Add an API for byte generators: psa_crypto_generator_t,
PSA_CRYPTO_GENERATOR_INIT, psa_crypto_generator_init,
psa_get_generator_capacity, psa_generator_read,
psa_generator_import_key, psa_generator_abort.
This commit does not yet implement any generator algorithm, it only
provides the framework. This code may not compile with -Wunused.
In psa_mac_setup and psa_hmac_setup_internal, perform a sanity check
on the hash size and the hash block size respectively. These sanity
checks should only trigger on an incompletely or incorrectly
implemented hash function.
Remove the check on the block size in psa_hmac_finish_internal
because at this point it has already been checked and used.
In the common case (key no longer than the block size), psa_hash_setup
was being called twice in succession. With current implementations
this is just a small performance loss, but potentially with
alternative implementations this could have lead to a memory leak.
Call psa_hash_setup in psa_hmac_setup_internal rather than
psa_mac_init. This makes it easier to use psa_hmac_setup_internal on
its own (for the sake of using HMAC internally inside the library).
Create internal functions for HMAC operations. This prepares for two
things: separating crypto-sensitive code from argument decoding and
validation, and using HMAC for other purposes than a MAC inside the
library (e.g. HMAC_DRBG, HKDF).
No intended observable behavior change in this commit.
Although RSASSA-PSS defines its input as a message to be hashed, we
implement a sign-the-hash function. This function can take an input
which isn't a hash, so don't restrict the size of the input, any more
than Mbed TLS does.
Remove a redundant check that hash_length fits in unsigned int for the
sake of Mbed TLS RSA functions.
Test that PSS accepts inputs of various lengths. For PKCS#1 v1.5
signature in raw mode, test the maximum input length.
No common signature algorithm uses a salt (RSA-PKCS#1v1.5, RSA-PSS,
DSA, ECDSA, EdDSA). We don't even take an IV for MAC whereas MAC
algorithms with IV are uncommon but heard of. So remove the salt
parameter from psa_asymmetric_sign and psa_asymmetric_verify.
