Document that a derivation function is used.
Document the security strength of the DRBG depending on the
compile-time configuration and how it is set up. In particular,
document how the nonce specified in SP 800-90A is set.
Mention how to link the ctr_drbg module with the entropy module.
* State explicit whether several numbers are in bits or bytes.
* Clarify whether buffer pointer parameters can be NULL.
* Explain the value of constants that are dependent on the configuration.
If none of the inputs to a key derivation is a
PSA_KEY_DERIVATION_INPUT_SECRET passed with
psa_key_derivation_input_key(), forbid
psa_key_derivation_output_key(). It usually doesn't make sense to
derive a key object if the secret isn't itself a proper key.
Allow a direct input as the SECRET input step in a key derivation, in
addition to allowing DERIVE keys. This makes it easier for
applications to run a key derivation where the "secret" input is
obtained from somewhere else. This makes it possible for the "secret"
input to be empty (keys cannot be empty), which some protocols do (for
example the IV derivation in EAP-TLS).
Conversely, allow a RAW_DATA key as the INFO/LABEL/SALT/SEED input to a key
derivation, in addition to allowing direct inputs. This doesn't
improve security, but removes a step when a personalization parameter
is stored in the key store, and allows this personalization parameter
to remain opaque.
Add test cases that explore step/key-type-and-keyhood combinations.
Keys of size 0 generally don't make sense: a key is supposed to be
secret. There is one edge case which is "raw data" keys, which are
useful to store non-key objects in the same storage location as keys.
However those are also problematic because they involve a zero-length
buffer. Manipulating zero-length buffers in C requires special cases
with functions like malloc() and memcpy(). Additionally, 0 as a key
size already has a meaning "unspecified", which does not always
overlap seamlessly with the meaning "0".
Therefore, forbid keys of size 0. No implementation may accept them.
Clarify how key creation functions use attributes. Explain the meaning
of attribute values, espcially what 0 means in each field where it has
a special meaning. Explain what an algorithm usage policy can be (an
algorithm, a wildcard with ANY_HASH, or 0).
* crypto/development: (77 commits)
all.sh: disable MEMORY_BUFFER_ALLOC in cmake asan build
Unify gcc and clang cmake flags to test with UBsan
Add an input check in psa_its_set
Remove storage errors from psa_generate_random
Update getting_started.md
Update based on Jaeden's comments.
Update getting_started.md
Fix return code warnings
Update getting_started.md
Fix warnings
Add PSA_ERROR_STORAGE_FAILURE to psa_cipher_generate_iv
Remove errorneous insert
Add STORAGE_FAILURE everywhere + add missing codes
Add storage failure to psa_mac_verify_finish
Add storage failure to psa_mac_sign_finish
Add PSA_ERROR_STORAGE_FAILURE to psa_aead_*_setup functions
Added PSA_ERROR_BAD_STATE to functions with operations
Added extra bad state case to psa_hash_setup
Add missing return codes to psa_generate_key
Add PSA_ERROR_BUFFER_TOO_SMALL to psa_mac_compute
...
Alternative implementations are often hardware accelerators and might
not need an RNG for blinding. But if they do, then we make them misuse
the RNG in the deterministic case.
There are several way around this:
- Exposing a lower level function for replacement. This would be the
optimal solution, but litters the API and is not backward compatible.
- Introducing a new compile time option for replacing the deterministic
function. This would mostly cover the same code as
MBEDTLS_ECDSA_DETERMINISTIC and would be yet another compile time flag.
- Reusing the existing MBEDTLS_ECDSA_DETERMINISTIC macro. This changes
the algorithm used by the PK layer from deterministic to randomised if
the alternative implementation is present.
This commit implements the third option. This is a temporary solution
and should be fixed at the next device driver API change.
The current interface does not allow passing an RNG, which is needed for
blinding. Using the scheme's internal HMAC-DRBG results the same
blinding values for the same key and message, diminishing the
effectiveness of the countermeasure. A new function
`mbedtls_ecdsa_det_ext` is available to address this problem.
`mbedtls_ecdsa_sign_det` reuses the internal HMAC-DRBG instance to
implement blinding. The advantage of this is that the algorithm is
deterministic too, not just the resulting signature. The drawback is
that the blinding is always the same for the same key and message.
This diminishes the efficiency of blinding and leaks information about
the private key.
A function that takes external randomness fixes this weakness.
* open output distinct key handles
* each handle must be closed
* destroying a key does not invalidate other handles
* closing a key can/might fail an active operation (but not required)
