* Rename psa_aead_set_nonce() to psa_aead_set_nonce_internal()
* Recreate psa_aead_set_nonce() as a wrapper that copies buffers before
calling the internal function.
This is because psa_aead_set_nonce() is currently called by
psa_aead_generate_nonce(). Refactoring this to call the static internal
function avoids an extra set of buffer copies as well as simplifying
future memory poisoning testing.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Resize buffer used to hold the nonce to twice the maximum nonce size.
Some test cases were requesting more than the maximum nonce size
without actually having backing space. This caused a buffer overflow
when PSA buffer-copying code was added.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Note that this is not strictly necessary as this function only copies to
the output buffer at the end. However, it simplifies testing for the
time being.
Future optimisation work could consider removing this copying.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
The psa_test_wrappers.h inclusion was breaking the examples in programs/
on functions with poisoning added
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
This option causes nested calls to PSA functions, so is not compatible
with memory poisoning as it currently stands.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Add a new macro `LOCAL_OUTPUT_ALLOC_WITH_COPY` to support the output buffer
handling of the multipart operations like `psa_cipher_update`. This will
allocate a local buffer and copy the content of the original buffer.
Signed-off-by: Gabor Mezei <gabor.mezei@arm.com>
Upon further consideration we think that a remote attacker close to the
victim might be able to have precise enough timing information to
exploit the side channel as well. Update the Changelog to reflect this.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Any timing variance dependant on the output of this function enables a
Bleichenbacher attack. It is extremely difficult to use safely.
In the Marvin attack paper
(https://people.redhat.com/~hkario/marvin/marvin-attack-paper.pdf) the
author suggests that implementations of PKCS 1.5 decryption that don't
include a countermeasure should be considered inherently dangerous.
They suggest that all libraries implement the same countermeasure, as
implementing different countermeasures across libraries enables the
Bleichenbacher attack as well.
This is extremely fragile and therefore we don't implement it. The use
of PKCS 1.5 in Mbed TLS implements the countermeasures recommended in
the TLS standard (7.4.7.1 of RFC 5246) and is not vulnerable.
Add a warning to PKCS 1.5 decryption to warn users about this.
Signed-off-by: Janos Follath <janos.follath@arm.com>
