secp224k1 is the one with 225-bit private keys.
The consequences of this mistake were:
* We emitted positive test cases for hypothetical SECP_R1_225 and
SECP_K1_224 curves, which were never executed.
* We emitted useless not-supported test cases for SECP_R1_225 and SECP_K1_224.
* We were missing positive test cases for SECP_R1_224 in automatically
generated tests.
* We were missing not-supported test cases for SECP_R1_224 and SECP_K1_225.
Thus this didn't cause test failures, but it caused missing test coverage
and some never-executed test cases.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
All of ECP requires the bignum module and there is no plan to change that,
so guarding a few bits of code is just noise.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
`$(MBEDTLS_TEST_OBJS)` included TLS-specific test support modules in
`tests/Makefile` but not in `programs/Makefile`. This difference is not
actually necessary. What is necessary is that all programs that use
functions from TLS-specific test support modules are linked with those
modules in addition to `-lmbedtls`, and programs that are not linked with
`-lmbedtls` are not linked with TLS-specific test support modules. Since we
always pass `-lmbedtls` when linking programs in `programs/Makefile`, we can
link with the TLS-specific test support modules as well. This keeps things
simpler.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
fixup "Create common.make with LOCAL_CFLAGS and friends"
The code wasn't what I had intended, although it was functionally
equivalent. Make it more readable and more robust.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
CCM/GCM can be either fully accelerated or rely on just the key type
being accelerated. This means that ultimately it is just the key
type which determines if the legacy block cipher modes need to
be auto-enabled or not.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Legacy CCM and GCM can work even when AES_C is not defined thanks
to the block_cipher module, so we can relax guards in
cipher_wrap.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
These were probably leftovers from the development phase of the
associated PR that were not removed in the end.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
This commit also updates test_suite_pkparse.data file adding
MBEDTLS_CIPHER_C dependencies whenever PKCS[5/12] is used.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
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>
