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>
In the ecjpake_do_round(), fix a magic number that was causing buffer
size to be incorrectly advertised.
Followup of 'Fix magic number buffer length in J-PAKE tests' for what
seem to be duplicate tests.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Enable memory poisoning for all functions whose names start with
'psa_pake'. Regenerate the wrappers and commit the result.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
The buffer size was advertised as 512-bytes, despite sometimes being
smaller. This did not cause a crash until buffer copying, which always
copies all of the buffer, was added.
When copying back to the original, we would cause a heap buffer
overflow, which ASan detected.
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>
