When testing the lifecycle of a transient key, it doesn't make much sense to
try psa_open_key: that expects a persistent key and the lookup takes a
different path. The error from psa_open_key is also different depending on
whether MBEDTLS_PSA_CRYPTO_STORAGE_C is enabled.
To check that the key ownership is taken into account, try to access the
same key id with a different owner without expecting that this is a
persistent key. Just call psa_get_key_attributes, which works fine for a
transient key.
This fixes a test failure when MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER is
enabled and MBEDTLS_PSA_CRYPTO_STORAGE_C is disabled.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The shipped Visual Studio project files were misconfigured for build
combinations of 64 bit Release builds.
Signed-off-by: Simon Butcher <simon.butcher@arm.com>
Variable had the very Windows name of lengthAsInt, which is fine for C# but
doesn't match the Mbed TLS coding standards.
Signed-off-by: Simon Butcher <simon.butcher@arm.com>
Changes to the build to add the new Win32 Crypto API's inadvertently broke
the build for mingw and Visual Studio builds when generated by CMake.
Signed-off-by: Simon Butcher <simon.butcher@arm.com>
CryptGenRandom and lstrlenW are not permitted in Windows Store apps,
meaning apps that use mbedTLS can't ship in the Windows Store.
Instead, use BCryptGenRandom and wcslen, respectively, which are
permitted.
Also make sure conversions between size_t, ULONG, and int are
always done safely; on a 64-bit platform, these types are different
sizes.
Also suppress macro redefinition warning for intsafe.h:
Visual Studio 2010 and earlier generates C4005 when including both
<intsafe.h> and <stdint.h> because a number of <TYPE>_MAX constants
are redefined. This is fixed in later versions of Visual Studio.
The constants are guaranteed to be the same between both files,
however, so we can safely suppress the warning when including
intsafe.h.
Signed-off-by: Kevin Kane <kkane@microsoft.com>
Components that accelerate an algorithm that uses hashing internally
(such as deterministic ECDSA and RSA-PSS) need the hash algorithms
available in libtestdriver1.
Previously, the omission of SHA-3 in
tests/include/test/drivers/crypto_config_test_driver_extension.h meant
it was enabled in libtestdriver1 when not requesting its acceleration,
and disabled when requesting it. Adding it in a previous commit fixed
the components that asked it accelerated, but broke the component that
didn't ask for it but still needed it.
Fix those components by explicitly requesting SHA-3 as we already do for
the other hash algorithms that are require for the same reason.
Note: this broke test_suite_psa_crypto_storage_format.v0 which is
apparently the only place exercising signatures with SHA-3.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
