July 2021 - mbed-tls - lists.trustedfirmware.org

Re: [mbed-tls] How to setup config.h to make memory_buffer_alloc_init() thread-safe?

by Gilles Peskine

Hi Shariful, First, please note that the library called PolarSSL with functions like rsa_private() and memory_buffer_alloc_init() has not been supported for several years. You should upgrade to Mbed TLS, with functions like mbedtls_rsa_private() and mbedtls_memory_buffer_alloc_init(). That being said, the memory_buffer_alloc module works in the same way. Normally, applications call mbedtls_memory_buffer_alloc_init() in the startup code of the initial thread, before creating other threads. The alloc/free functions are thread-safe, but the initialization and deinitialization functions aren't. If you must call mbedtls_memory_buffer_alloc_init() after creating other threads, make sure that no thread calls mbedtls_calloc until mbedtls_memory_buffer_alloc_init() has returned. The same principle applies to other parts of Mbed TLS that are thread-safe. For example, only the RSA operations (encryption, decryption, signature, verification, and also the low-level functions mbedtls_rsa_public() and mbedtls_rsa_private()) are protected. So you must finish setting up the RSA key inside one thread before you pass a pointer to other threads. Similarly, only mbedtls_xxx_drbg_random() is thread-safe, and the RNG setup (including mbedtls_xxx_drgb_seed()) should be done as part of the initial application startup. Finally, note that mbedtls_rsa_private() alone cannot decrypt a message: all it does it to apply the private key operation. To decrypt a simple message encrypted with RSA-OAEP, call mbedtls_rsa_rsaes_oaep_decrypt() or mbedtls_rsa_pkcs1_decrypt() with a key set up for MBEDTLS_RSA_PKCS_V21 encoding. To use the legacy PKCS#1v1.5 mechanism, call mbedtls_rsa_rsaes_pkcs1_v15_decrypt() or mbedtls_rsa_pkcs1_decrypt() with a key set up for .MBEDTLS_RSA_PKCS_V15. To decrypt a message using a RSA FDH hybrid scheme, you do need to call mbedtls_rsa_private() since Mbed TLS doesn't support it natively, but what this gives you is the intermediate secret from which you then need to derive a symmetric key, not the message itself. Best regards, -- Gilles Peskine Mbed TLS developer On 18/07/2021 07:16, Shariful Alam via mbed-tls wrote: > Hello, > I have a simple example code to decrypt an encrypted message using > *rsa_private()*. I use *memory_buffer_alloc_init(), *in order to use > a static memory for the computation. I want to run my code > concurrently. My code works with a single pthread. However, when I try > to run more than one thread my program fails to decrypt. > > ** I check the same code without *memory_buffer_alloc_init(), *it > works concurrently, without any issues at all. > > Therefore, I believe, the issue that I'm facing is coming from the use > of static memory(e.g. *memory_buffer_alloc_init()*). The documentation > of memorry_buffer_alloc.h shows, > > /** > > * \brief Initialize use of stack-based memory allocator. > > * The stack-based allocator does memory management > inside the > > * presented buffer and does not call malloc() and free(). > > * It sets the global polarssl_malloc() and > polarssl_free() pointers > > * to its own functions. > > * (Provided polarssl_malloc() and polarssl_free() are > thread-safe if > > * POLARSSL_THREADING_C is defined) > > * > > * \note This code is not optimized and provides a straight-forward > > * implementation of a stack-based memory allocator. > > * > > * \param buf buffer to use as heap > > * \param len size of the buffer > > * > > * \return 0 if successful > > */ > > > So, I added the following configuration to the *config.h* file > > 1. #define POLARSSL_THREADING_PTHREAD > 2. #define POLARSSL_THREADING_C > > But I'm still getting errors while decrypting. Any help on how to fix > this? or what else should I add into the config.h file to > make *memory_buffer_alloc_init() *thread-safe? Here is my sample > code: https://pastebin.com/uyW3vknt <https://pastebin.com/uyW3vknt> > > Thanks, > Shariful >

3 years, 4 months

1
0
0 0

How to setup config.h to make memory_buffer_alloc_init() thread-safe?

by Shariful Alam

Hello, I have a simple example code to decrypt an encrypted message using *rsa_private()*. I use *memory_buffer_alloc_init(), *in order to use a static memory for the computation. I want to run my code concurrently. My code works with a single pthread. However, when I try to run more than one thread my program fails to decrypt. ** I check the same code without *memory_buffer_alloc_init(), *it works concurrently, without any issues at all. Therefore, I believe, the issue that I'm facing is coming from the use of static memory(e.g. *memory_buffer_alloc_init()*). The documentation of memorry_buffer_alloc.h shows, /** * \brief Initialize use of stack-based memory allocator. * The stack-based allocator does memory management inside the * presented buffer and does not call malloc() and free(). * It sets the global polarssl_malloc() and polarssl_free() > pointers * to its own functions. * (Provided polarssl_malloc() and polarssl_free() are thread-safe > if * POLARSSL_THREADING_C is defined) * * \note This code is not optimized and provides a straight-forward * implementation of a stack-based memory allocator. * * \param buf buffer to use as heap * \param len size of the buffer * * \return 0 if successful */ So, I added the following configuration to the *config.h* file 1. #define POLARSSL_THREADING_PTHREAD 2. #define POLARSSL_THREADING_C But I'm still getting errors while decrypting. Any help on how to fix this? or what else should I add into the config.h file to make *memory_buffer_alloc_init() *thread-safe? Here is my sample code: https://pastebin.com/uyW3vknt Thanks, Shariful

3 years, 4 months

1
1
0 0

question about sslv3 alert certificate unknown

by Ron Eggler

Hi, I'm working on a client application that will connect to an FTPS server (vsftpd) to download files. Now, I have ca-cert, cert and key files all setup to work with curl like: curl -3 -k -v --ftp-ssl --tlsv1.2 --ftp-ssl-reqd --ftp-pasv --verbose \ --ssl \ --cert ./en-cert.pem \ --cert-type PEM \ --key ./en-cert.key \ --key-type PEM \ --cacert ./ca-cert \ ftp://user:pass@10.10.100.1/test.txt -O Now, I use the same cert, key & ca-cert with mbedtls but am unable to handshake, mbedtls_ssl_handshake() keeps giving me an error, what is done in order: - init cert, ca-cert, key, entropy, drbg, ssl, config - parse ca-cert, cert & key - seed RNG - mbedtls_ctr_drbg_seed with mbedtls_hardware_poll - set config defaults MBEDTLS_SSL_IS_CLIENT, MBEDTLS_SSL_TRANSPORT_STREAM, MBEDTLS_SSL_PRESET_DEFAULT - mbedtls_ssl_conf_ca_chain - mbedtls_ssl_conf_rng with mbedtls_ctr_drbg_random - mbedtls_ssl_conf_dbg - mbedtls_ssl_conf_own_cert - mbedtls_ssl_setup - mbedtls_ssl_set_bio - mbedtls_ssl_handshake which up to the handshake all seems to go through without any issues. When I look at it with wireshark, I see something like: Response: 234 Proceed with negotiation. Request:looks like the certificate jumbled up Response 500 OOPS: Response :SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown Any hints on how I best go about troubleshooting this? I have confirmed that ca-cert, cert & key are identical to the ones that are used for the above curl command. Thanks,

3 years, 4 months

1
0
0 0

Re: [mbed-tls] Question about dynamic linking, versioning and API/ABI stability

by Janos Follath

Hi, Semantic versioning applies only to API compatibility but not for ABI. When we break the ABI we increase the SO version for that part of the library and this is how linux distributions normally track our ABI compatibility. Additionally, we try very hard not to break ABI at all in LTS versions. You can find a detailed description what Mbed TLS promises regarding API/ABI compatibility: https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md Kind regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Hugues De Valon via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Date: Wednesday, 14 July 2021 at 17:09 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Question about dynamic linking, versioning and API/ABI stability Hello, We are using Mbed Crypto in our Parsec project through the psa-crypto Rust crate (https://github.com/parallaxsecond/rust-psa-crypto). We currently have Mbed Crypto through Mbed TLS 2.25.0 which we build statically from scratch by default. We also offer the option to dynamically link with an Mbed Crypto library available on the system. Ideally, this would offer an easy and simple way to patch bug fixes without having to recompile everything. However, as we observed API (and probably ABI) breaking changes over the past versions of Mbed TLS we were wondering if this (dynamic linking) was a model we should promote at all. Is there a semantic versioning process currently applied in Mbed TLS? If we use Mbed TLS 3.0.0 in our crate, can we be sure than 3.x.y versions won’t contain any API/ABI breaking changes or is there nothing of the sort? I believe that Mbed Crypto is catching up to be fully compliant with PSA Crypto 1.0.1. Once that will be the case, will its API/ABI be stable and follow the PSA Crypto semantic versioning? It might be that the good solution is that we shouldn’t dynamically link with Mbed Crypto but always compile it from scratch as we do by default. I am just sending this email so that we follow the good approach! Kind regards, Hugues

3 years, 4 months

2
2
0 0

Question about dynamic linking, versioning and API/ABI stability

by Hugues De Valon

Hello, We are using Mbed Crypto in our Parsec project through the psa-crypto Rust crate (https://github.com/parallaxsecond/rust-psa-crypto). We currently have Mbed Crypto through Mbed TLS 2.25.0 which we build statically from scratch by default. We also offer the option to dynamically link with an Mbed Crypto library available on the system. Ideally, this would offer an easy and simple way to patch bug fixes without having to recompile everything. However, as we observed API (and probably ABI) breaking changes over the past versions of Mbed TLS we were wondering if this (dynamic linking) was a model we should promote at all. Is there a semantic versioning process currently applied in Mbed TLS? If we use Mbed TLS 3.0.0 in our crate, can we be sure than 3.x.y versions won't contain any API/ABI breaking changes or is there nothing of the sort? I believe that Mbed Crypto is catching up to be fully compliant with PSA Crypto 1.0.1. Once that will be the case, will its API/ABI be stable and follow the PSA Crypto semantic versioning? It might be that the good solution is that we shouldn't dynamically link with Mbed Crypto but always compile it from scratch as we do by default. I am just sending this email so that we follow the good approach! Kind regards, Hugues

3 years, 4 months

1
0
0 0

serial communication in FTP

by Sunil Jain

Hello, we are using the mbed-tls for secure communication for FTP. FTP server is handling the client hello serially one at a time, one communication is blocking other clients to communicate. What could be the reason and how to solve this issue. -- Thanks and Regards, Sunil Jain

3 years, 4 months

1
0
0 0

Mbed TLS: Release of Mbed TLS 3.0.0, 2.27.0, and 2.16.11

by Dave Rodgman

Hi Mbed TLS users, We are pleased to announce the release of Mbed TLS versions 3.0.0, 2.27.0 and 2.16.11. These releases of Mbed TLS address several security issues, and provide bug fixes and enhancements. Mbed TLS 3.0.0 also brings many API-breaking changes. Full details, including security advisories, are available in the release notes: https://github.com/ARMmbed/mbedtls/releases/tag/v3.0.0 https://github.com/ARMmbed/mbedtls/releases/tag/v2.27.0 https://github.com/ARMmbed/mbedtls/releases/tag/v2.16.11 We recommend all users to consider whether they are impacted, and to upgrade appropriately. Dave Rodgman

3 years, 4 months

1
0
0 0

Mbed TLS: Release of Mbed TLS 3.0.0, 2.27.0, and 2.16.11

by Dave Rodgman

Hi Mbed TLS users, We are pleased to announce the release of Mbed TLS versions 3.0.0, 2.27.0 and 2.16.11. These releases of Mbed TLS address several security issues, and provide bug fixes and enhancements. Mbed TLS 3.0.0 also brings many API-breaking changes. Full details, including security advisories, are available in the release notes: https://github.com/ARMmbed/mbedtls/releases/tag/v3.0.0 https://github.com/ARMmbed/mbedtls/releases/tag/v2.27.0 https://github.com/ARMmbed/mbedtls/releases/tag/v2.16.11 We recommend all users to consider whether they are impacted, and to upgrade appropriately. Dave Rodgman

3 years, 4 months

1
0
0 0

Re: [mbed-tls] mbedtls_x509_crt_parse returned -0x2180

by Danny Backx

Gilles, Thanks for getting me to try to read DER files. There must definitely be something wrong in that area. I am speficying support for PEM in the build but reading DER gets me past that error. Searching further :-) Again, thanks Danny On 05/07/2021 20:27, Gilles Peskine via mbed-tls wrote: > Hello, > > The first thing when you see an unexpected error code is to look up the > corresponding error message. Mbed TLS comes with a utility for that: > > programs/util/strerror 0x2180 > Last error was: -0x2180 - X509 - The CRT/CRL/CSR format is invalid, > e.g. different type expected > > You can also search the error code in the source code: > > grep 0x2180 include/mbedtls/*.h > include/mbedtls/x509.h:#define > MBEDTLS_ERR_X509_INVALID_FORMAT -0x2180 /**< The > CRT/CRL/CSR format is invalid, e.g. different type expected. */ > > At first glance it looks like there's only one case for which CRT > parsing return MBEDTLS_ERR_X509_INVALID_FORMAT as opposed to > (MBEDTLS_ERR_X509_INVALID_FORMAT + low_level_error_code), and that's if > the certificate doesn't parse like a DER format at the top level. A > plausible reason for that is that the certificate is in PEM format and > your build has PEM support turned off. If that's the case, convert the > certifcate to DER when you copy it to the device. You can use the Mbed > TLS utility programs/util/pem2der for that. > > Best regards, > -- Danny Backx - dannybackx(a)telenet.be - http://danny.backx.info

3 years, 4 months

1
0
0 0

SHA NI support in mbedtls

by Lu, Jingdong

Hi, mbedtls experts I note that there is AES NI support (aesni.c) on x86 platform. I'm wondering why there is no SHA NI support for SHA1 and SHA256? How can I get SHA NI support? Should I choose another crypto library? Thanks, Jingdong

3 years, 4 months

1
0
0 0

2024

2023

2022

2021

2020

mbed-tls July 2021