Encrypt more than 2 blocks of data, causing both update() calls to
output data as well as the call to finish().
This exposes a test bug where the pointer to a buffer is not updated
as it is filled with data.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
The operation will still return an error, but the assert-based
validation checks will pass. This allows GCM to work with buffer
copies / local inputs, which may be NULL when they are zero-length.
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>
We do not intend to support multithreaded testing in 2.28, so
introducing a C11 feature here is an unnecessary burden.
Signed-off-by: David Horstmann <david.horstmann@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>
The signature and naming of the Montgomrey initialisation function in
development and in the LTS was different. Align them for easier
readability and maintenance.
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>
So far we needed it only locally here, but we will need calculating RR
for safe unblinding in RSA as well.
Signed-off-by: Janos Follath <janos.follath@arm.com>
