- mbed-tls - lists.trustedfirmware.org

Re: [mbed-tls] Mbed TLS: long term support versions

by Gilles Peskine

Off-by-one error! The current 2.x release is 2.27.0. Most development work is happening on 3.x but there will be at least one more 2.x release: 2.28.0. The last 2.x release will become an LTS. -- Gilles Peskine Mbed TLS developer On 29/07/2021 15:05, Dave Rodgman via mbed-tls wrote: > > Hi Matteo, > > > > We expect to release an LTS later this year. It’s likely to be 2.27, > and very likely will be supported for the usual LTS period of 3 years. > > > > So if you are considering updating to a new LTS, you could use 2.26 > for prototyping in the short term until the LTS becomes available. The > upcoming LTS will be API-compatible with 2.26. > > > > Hope this helps, > > > > Dave > > > > *From: *mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on > behalf of "matteo.cogi--- via mbed-tls" > <mbed-tls(a)lists.trustedfirmware.org> > *Reply to: *"matteo.cogi(a)alice.it" <matteo.cogi(a)alice.it> > *Date: *Tuesday, 27 July 2021 at 07:44 > *To: *"mbed-tls(a)lists.trustedfirmware.org" > <mbed-tls(a)lists.trustedfirmware.org> > *Subject: *[mbed-tls] Mbed TLS: long term support versions > > > > Dear all, > I wish to know which are the future LTS (Long Term Support) versions > for Mbed TLS. > In these last years I have been working with the 2.16.x, but I read it > will be maintained until at least the end of 2021 ( > https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md#current-bra… > <https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md#current-bra…> > ), so I am considering an update to a newer LTS version. > However I don’t find which are the next LTS version and for how much > time they will be maintained. > Thanks in advance. > Regards, > Matteo > >

3 years, 2 months

1
0
0 0

Re: [mbed-tls] Mbed TLS: long term support versions

by Dave Rodgman

Hi Matteo, We expect to release an LTS later this year. It’s likely to be 2.27, and very likely will be supported for the usual LTS period of 3 years. So if you are considering updating to a new LTS, you could use 2.26 for prototyping in the short term until the LTS becomes available. The upcoming LTS will be API-compatible with 2.26. Hope this helps, Dave From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of "matteo.cogi--- via mbed-tls" <mbed-tls(a)lists.trustedfirmware.org> Reply to: "matteo.cogi(a)alice.it" <matteo.cogi(a)alice.it> Date: Tuesday, 27 July 2021 at 07:44 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Mbed TLS: long term support versions Dear all, I wish to know which are the future LTS (Long Term Support) versions for Mbed TLS. In these last years I have been working with the 2.16.x, but I read it will be maintained until at least the end of 2021 ( https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md#current-bra… ), so I am considering an update to a newer LTS version. However I don’t find which are the next LTS version and for how much time they will be maintained. Thanks in advance. Regards, Matteo

3 years, 2 months

1
0
0 0

Mbed TLS: long term support versions

by matteo.cogi＠alice.it

Dear all, I wish to know which are the future LTS (Long Term Support) versions for Mbed TLS. In these last years I have been working with the 2.16.x, but I read it will be maintained until at least the end of 2021 ( https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md#current-bra… <https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md#current-bra…> ), so I am considering an update to a newer LTS version. However I don’t find which are the next LTS version and for how much time they will be maintained. Thanks in advance. Regards, Matteo

3 years, 2 months

1
0
0 0

Re: [mbed-tls] May I know why SHA224 is mandatory with SH256?

by Gilles Peskine

Hello, Mbed TLS has never supported a build with SHA-256 but not SHA-224. In Mbed TLS 2.x, enabling MBEDTLS_SHA256_C enables both SHA-256 and SHA-224. Likewise, MBEDTLS_SHA512_C enables both SHA-512 and SHA-384. The reason for this design is that SHA-256 and SHA-224 have essentially the same code but different constants, and likewise for SHA-512 and SHA-384. What changed in Mbed TLS 3.0 is that there are now separate configuration options for each of the four SHA2 variants. It is not possible yet to enable SHA-384 without SHA-512, SHA-224 without SHA-256 or SHA-256 without SHA-224. These are implementation limitations due to missing #ifdef in various places. We expect to lift these limitations in one of the next 3.x releases. Best regards, -- Gilles Peskine Mbed TLS developer On 19/07/2021 14:50, David Hu via mbed-tls wrote: > > Hi, > > ï¿½ > > It seems that SHA224 is mandatory if SHA256 is selected, in Mbed TLS > latest version, according to this new check below: > > ï¿½ > > #if defined(MBEDTLS_SHA256_C) && !defined(MBEDTLS_SHA224_C) > > #error "MBEDTLS_SHA256_C defined without MBEDTLS_SHA224_C" > > #endif > > ï¿½ > > May I know why SHA224 must be enabled with SHA256? > > Could you please point me to any reference/document? > > ï¿½ > > Best regards, > > Hu Ziji > >

3 years, 2 months

2
3
0 0

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

by Shariful Alam

Hi Gilles, Thank you very much, for your reply. Sorry to bother you again. I am trying to follow your instructions. I have a question regarding your suggestions. You said "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." I'm a little confused here. Say, if I call mbedtls_memory_buffer_alloc_init() with a buffer in the main thread, how did all other threads use this memory (or how do all the threads know which memory block to use)? After calling mbedtls_memory_buffer_alloc_init() in the main thread, I can get the address of the buffer and pass it to the threads, do I have to call mbedtls_memory_buffer_alloc_init() again inside each thread? Thanks, Shariful On Mon, Jul 19, 2021 at 3:48 AM Gilles Peskine via mbed-tls < mbed-tls(a)lists.trustedfirmware.org> wrote: > 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 > > > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls >

3 years, 2 months

2
1
0 0

May I know why SHA224 is mandatory with SH256?

by David Hu

Hi, It seems that SHA224 is mandatory if SHA256 is selected, in Mbed TLS latest version, according to this new check below: #if defined(MBEDTLS_SHA256_C) && !defined(MBEDTLS_SHA224_C) #error "MBEDTLS_SHA256_C defined without MBEDTLS_SHA224_C" #endif May I know why SHA224 must be enabled with SHA256? Could you please point me to any reference/document? Best regards, Hu Ziji

3 years, 2 months

1
0
0 0

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, 2 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, 2 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, 2 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, 2 months

2
2
0 0

2024

2023

2022

2021

2020

mbed-tls