- mbed-tls - lists.trustedfirmware.org

FIPS 140-3 compliance of MbedTLS Test suites

by Viktor.Ivanets＠infineon.com

Hi All, We are using MbedTLS on our devices and implementing PSA wrappers to use our Crypto hardware. For validating this one we are using MbedTLS test suites. Could you please tell me: 1. Does your test suites compliant to FIPS 140-3? 2. Do you use NIST test vectors to validate your algorithm implementations? Thanks. Viktor Ivanets.

2 months, 4 weeks

1
0
0 0

3.6.0 library size

by Steven Burck

On a project at my company, we're using mbedtls to encrypt and sign our data. We began the project with mbedtls 2.2.6, and have continuously upgraded until now, 3.6.0. I've noticed my application has grown greatly since then, even though we are only using the following APIs: Encryption:(only decryption on the embedded side) - mbedtls_aes_init - mbedtls_aes_setkey_dec - mbedtls_aes_crypt_cbc Signing (only verification on the embedded side) - mbedtls_ecp_point_read_binary - mbedtls_sha256_init/free - mbedtls_sha256_starts_ret - mbedtls_sha256_update_ret - mbedtls_sha256_finish_ret - mbedtls_ecdsa_init/free - mbedtls_ecp_group_load - mbedtls_ecdsa_read_signature The size of libembedcrypto.a has grown from under 400K to almost 800K. I've tried reducing it with mbedtls_config,h, but it is not entirely clear to me which #defines do what. I tried one of the sample configs which by it;s name looked promising (crypto-config-ccm-aes-sha256.h), and it reduced the size of the library by 90%, but left me with link errors for all of the above functions. Going one #define at a time manually to see if it saves or grows is slow, and so I hoped I could find some assistance here. Thanks in advance

2 months, 4 weeks

2
2
0 0

Question about random number g

by Zhang, Hao

Hi TF-M and mbedtls community, I am new to TF-M, I have a few questions about CryptoCell and random number generation. Thank you in advance. 1. I figure there seems to have two CryptoCell 312 implementations within TF-M. One under lib/ext/cryptocell-312-runtime and the other under platform/ext/accelerator/cc312/cc312-rom. What are the difference between these two? 2. For lib/ext/cryptocell-312-runtime, it does not define MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG whereas /ext/accelerator/cc312/cc312-rom does. Does that mean cryptocell-312-runtime is initiating RNG cryptodriver by using mbedtls_entropy_add_source whereas cc312-rom is using mbedtls_psa_external_get_random<https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/8df9cc8baf462…>. If so, may I ask why these two cryptocells take two different approaches? I read from one of the documentation that mbedtls_psa_external_get_random is used when entropy is sufficient. So if entropy is sufficient, is it always preferred to have MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG defined and implements mbedtls_psa_external_get_random? What are the differences between the two approaches. 3. I also found cryptocell-312-runtime defines the entry point function cc3xx_init_random<https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/8df9cc8baf462…>. But since PSA random number entry point funciton is not complete, the cc3xx_init_random is not being called anywhere, right? [https://opengraph.githubassets.com/17cdebc400b0ed807c620b586b21f3f77ff9c5d3…]<https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/8df9cc8baf462…> trusted-firmware-m/platform/ext/accelerator/cc312/cc312-rom/psa_driver_api/src/cc3xx_psa_random.c at 8df9cc8baf46252fd188bba1d87333a8daa9a5e8 · zephyrproject-rtos/trusted-firmware-m<https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/8df9cc8baf462…> Zephyr repository tracking https://git.trustedfirmware.org/trusted-firmware-m.git/ - zephyrproject-rtos/trusted-firmware-m github.com 4. I know random number generation PSA entry point function is in development, may I ask when that would be expected to complete? Thank you very much! Best regards, Hao

3 months

1
0
0 0

Request for feedback about Mbed TLS 4: DRBG interfaces

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (TF-PSA-Crypto 1.0 + Mbed TLS 4.0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/107 Should TF-PSA-Crypto 1.0 (and thus Mbed TLS 4.0) have an interface for *pseudo*-random generation? It will, of course, still have a pseudorandom generator (= deterministic random bit generator = DRBG) internally, to power psa_generate_random(), psa_generate_key(), etc. The question is whether there will still be a public interface to create other DRBG instances, and if so, with what interface. If you want to be able to create instances of HMAC_DRBG and CTR_DRBG from application code in TF-PSA-Crypto 1.0, please let us know what your use case is. In particular, what parameters do you need (HMAC_DRBG and CTR_DRBG have many)? Do you need reseeding, and if so under whose control (the DRBG, or the caller)? In the absence of feedback, it is likely that HMAC_DRBG and CTR_DRBG will not be publicly available. Best regards, -- Gilles Peskine Mbed TLS developer

3 months

1
0
0 0

mbedtls 3.6.0: zero-sized array gives compiler warning (is undefined behavior)

by Almut Herzog

Hi all, I have a custom configuration where MBEDTLS_ECDSA_C is defined but MBEDTLS_PSA_CRYPTO_C and MBEDTLS_PSA_CRYPTO_CONFIG are not. This leads to a compiler warning in e.g. psa_util.c because a zero-sized array is declared (because PSA_VENDOR_ECC_MAX_CURVE_BITS is defined as 0). As of C99, §6.7.5.2 Array declarators: "If the expression is a constant expression, it shall have a value greater than zero." psa_util.c: #if defined(MBEDTLS_PSA_UTIL_HAVE_ECDSA) // Line 368 int mbedtls_ecdsa_raw_to_der(...) // Line 433 unsigned char r[PSA_BITS_TO_BYTES(PSA_VENDOR_ECC_MAX_CURVE_BITS)]; // Line 436 --> becomes in my config: unsigned char r[0]; MBEDTLS_PSA_UTIL_HAVE_ECDSA is automatically defined in my configuration due to the following code in config_adjust_legacy_crypto.h: #if defined(MBEDTLS_ECDSA_C) || (defined(MBEDTLS_PSA_CRYPTO_C) && \ (defined(PSA_WANT_ALG_ECDSA) || defined(PSA_WANT_ALG_DETERMINISTIC_ECDSA))) #define MBEDTLS_PSA_UTIL_HAVE_ECDSA #endif PSA_VENDOR_ECC_MAX_CURVE_BITS only receives a non-zero value if a PSA_WANT_<CURVE>, e.g. PSA_WANT_ECC_BRAINPOOL_P_R1_256, is defined. PSA_WANT_<CURVE> only gets defined in crypto_config.h if MBEDTLS_PSA_CRYPTO_CONFIG is defined (which it is not in my configuration). I have worked around it by explicitly defining e.g. PSA_WANT_ECC_BRAINPOOL_P_R1_256 in my configuration. But I believe there is some mismatch in the defines, at least in this example case, because mbedtls_ecdsa_raw_to_der() is only used in pk_wrap.c if MBEDTLS_USE_PSA_CRYPTO is defined. Impact: * In general, zero-sized arrays have undefined behavior in C (but are allowed by some compiler extensions) and thus behave differently for different compilers --> you might want to review PSA_VENDOR_ECC_MAX_CURVE_BITS and PSA_VENDOR_FFDH_MAX_KEY_BITS (and possibly more definitions) that fall through to 0 and are used as array sizes. * In my particular case, I believe code is compiled that is not needed (defines in psa_util.c and pk_wrap.c do not seem to match)

3 months

2
1
0 0

Request for feedback about Mbed TLS 4: size_t printing with %zu

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (Mbed TLS 4.0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/mbedtls/issues/9307 Mbed TLS requires a C99 platform, with some pragmatic restrictions. One restriction is that we do not require printf and friends to support %zu for size_t printing. Starting with Mbed TLS 4.0, we are considering requiring printf() and friends (or the mbedtls_printf() and friends alternatives if overridden) to support %zu. This only affects the TLS library, not X.509 and crypto. Is it still necessary in 2025 to support platforms where printf() does not support the z modifier? Best regards, -- Gilles Peskine Mbed TLS developer

3 months

1
0
0 0

Request for feedback about Mbed TLS 4 and TF-PSA-Crypto: build system

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (TF-PSA-Crypto 1.0 + Mbed TLS 4.0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/106 We are evaluating build systems for TF-PSA-Crypto, and this will influence the Mbed TLS build as well (the Mbed TLS build scripts will call the TF-PSA-Crypto build scripts, whatever they are). Our current thinking is that we would like to have *CMake as the sole build system*. (We're still investigating whether CMake can do all we need.) That would mean that we would no longer provide GNU makefiles or Visual Studio solutions. As this remains a C project, for just building the library, compiling all the .c files with an include path covering all the .h files will keep working in common cases (but, as today, it isn't something we support officially). The main case I can think of where this wouldn't work is when cryptographic accelerator support requires special includes or compiler flags. Are there environments where the use of CMake is a problem? What is the oldest version of CMake that you'd like us to be compatible with? Best regards, -- Gilles Peskine Mbed TLS developer

3 months, 1 week

1
0
0 0

Request for feedback about Mbed TLS 4: RSA decryption cipher suites

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (Mbed TLS 4.0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/mbedtls/issues/8170 We are considering removing support for RSA and RSA-PSK key exchanges in Mbed TLS 4. These are cipher suites that use RSA encryption, as opposed to cipher suites using a key agreement (ECDHE) plus RSA signature. These key exchanges are hard to implement securely (we believe we got it right, but it's very delicate code), and they add significantly to the complexity of the TLS code. They have been formally deprecated for a long time and were removed in TLS 1.3. However, I'm aware that some ecosystems are clinging to RSA key exchange. Are RSA-encryption key exchanges still relevant for Mbed TLS? If you want Mbed TLS 4 to keep supporting RSA-encryption cipher suites in TLS 1.2, please let us know and tell us about your use cases. Best regards, -- Gilles Peskine Mbed TLS developer

3 months, 1 week

1
1
0 0

Request for feedback about Mbed TLS 4: AESNI without compiler intrinsics

by Gilles Peskine

Hello, This is a request for feedback about the next major release of Mbed TLS (TF-PSA-Crypto 1.0 + Mbed TLS 4.0). (Mbed TLS 3.6 LTS will remain supported with its current feature set until at least Q2 2027.) Please reply to this thread or on the GitHub issue linked below. If you wish to leave feedback privately, you can reply privately and your feedback will be anonymized before sharing outside Arm. https://github.com/Mbed-TLS/mbedtls/issues/8231 We currently have two implementations of accelerated AES on x86_64 using AESNI (Intel AES acceleration): using assembly or using compiler intrinsics. The assembly code works with GCC and Clang without any compilation options, but not with MSVC. The intrinsics work with MSVC, but not with ancient GCC/Clang and they require compiling at least aesni.c with suitable CPU variant options (e.g. -maes -mpclmul for Clang). We're considering removing the assembly implementation. Is there still interest in compiling AESNI support with older compilers or with simple build systems that don't pass machine options? Best regards, -- Gilles Peskine Mbed TLS developer

3 months, 1 week

1
0
0 0

How to read ecp private key

by arun.lal＠intel.com

I am generating a ECP key in following way. And now how do I get the private key? TEE_Result gen_ec_keys(mbedtls_pk_context* pk, mbedtls_entropy_f_source_ptr f_source, __maybe_unused TEE_Param params[TEE_NUM_PARAMS]) { int ret = 1; mbedtls_entropy_context entropy; mbedtls_ctr_drbg_context ctr_drbg; const char* pers = "gen_key"; TEE_Result res = TEE_SUCCESS; unsigned char output_buf[16000]; memset(output_buf, 0, 16000); mbedtls_entropy_init(&entropy); mbedtls_ctr_drbg_init(&ctr_drbg); if ((ret = mbedtls_entropy_add_source(&entropy, f_source, NULL, 48, MBEDTLS_ENTROPY_SOURCE_STRONG)) != 0) { params[2].value.a = 1; goto exit; } if ((ret = mbedtls_ctr_drbg_seed(&ctr_drbg, f_entropy, &entropy, (const unsigned char*)pers, strlen(pers))) != 0) { mbedtls_printf(" failed\n ! mbedtls_ctr_drbg_seed returned -0x%04x\n", (unsigned int)-ret); params[2].value.a = 2; goto exit; } if ((ret = mbedtls_pk_setup(pk, mbedtls_pk_info_from_type(MBEDTLS_PK_ECKEY))) != 0) { EMSG(" failed\n ! mbedtls_pk_setup returned -0x%04x", (unsigned int)-ret); params[2].value.a = 3; goto exit; } if ((ret = mbedtls_ecp_gen_key(MBEDTLS_ECP_DP_SECP384R1, mbedtls_pk_ec(*pk), mbedtls_ctr_drbg_random, &ctr_drbg)) != 0) { EMSG(" failed\n ! mbedtls_ecp_gen_key returned -0x%04x", (unsigned int)-ret); params[2].value.a = 4; goto exit; } exit: mbedtls_ctr_drbg_free(&ctr_drbg); mbedtls_entropy_free(&entropy); return res; }

3 months, 2 weeks

4
4
0 0

2024

2023

2022

2021

2020

mbed-tls