- mbed-tls - lists.trustedfirmware.org

R: Re: Mbed TLS: long term support versions

by matteo.cogi＠alice.it

Hi Dave and Gilles, Perfect, so I will wait for the last 2.x (presumably the 2.28.x) strand of the version later this year. Thanks again. Regards, Matteo ------ Messaggio Originale ------ Da: mbed-tls(a)lists.trustedfirmware.org A: Gilles.Peskine(a)arm.com; mbed-tls(a)lists.trustedfirmware.org Inviato: giovedì 29 luglio 2021 15:33 Oggetto: Re: [mbed-tls] Mbed TLS: long term support versions Sorry, just realised that myself! Gilles is correct, I should have said 2.28. Thanks Dave On 29/07/2021, 14:25, "mbed-tls on behalf of Gilles Peskine via mbed-tls" <mbed-tls-bounces(a)lists.trustedfirmware.org on behalf of mbed-tls(a)lists.trustedfirmware.org> wrote: 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 > > -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

3 years, 11 months

1
0
0 0

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

by Gilles Peskine

(Note: I'm replying to the list. Please keep list conversations on the list.) Writing memory allocators is a specialty. It's not my specialty, and apparently it's not your specialty either, so if we design a memory allocator we're likely to end up with poor performance. On most systems, the standard library malloc is designed by experts, and often fine-tuned for the type of platform and usage (e.g. large or small pools, with or without MMU, with or without cache). memory_buffer_alloc uses an array to implement malloc. One possible explanation for poor performance is if your allocator doesn't align data nicely. Some platforms supports unaligned accesses (e.g. accessing a 4-byte value at an address that isn't a multiple of 4) but with a significant performance penalty (most others just crash). If there's a cache, alignment with cache line boundaries can also help. Another potential reason in a multithreaded program is not doing synchronization efficiently, or doing it too often. Note that you do NOT need synchronization if each thread has its own memory pool and no thread ever modifies the data of another thread. Note, however, that Mbed TLS caches some data in public/private key objects, so doing an operation with a key modifies the key object, therefore each thread would need to have its own copy of the key. There are undoubtedly other likely reasons that I'm not thinking of. Best regards, -- Gilles Peskine Mbed TLS developer On 29/07/2021 22:38, Shariful Alam wrote: > Hi Gilles, > Hope you are well. The project that I'm currently working on requires > static memory allocation instead of dynamic memory allocation. I was > trying to use "memory_buffer_alloc()". Since memory_buffer_alloc() > doesn't support multiple memory pools, seems like I can't use this > function in my project. > > I have a working version of a modified bignum.c & bignum.h, where > malloc is replaced with an array. The library is working. However, the > performance is poor (~4 times slower). I was wondering what could > cause this slow performance. I mean, I understand it will be slow, but > I did not expect it to be 4 times slower. > > Is there any version, where an array was used instead of malloc? Or if > you could point out some of the reasons for this library to slow down > while using an array, I will be very grateful. > > Best regards, > Shariful > > > On Tue, Jul 20, 2021 at 2:22 PM Gilles Peskine <gilles.peskine(a)arm.com > <mailto:gilles.peskine@arm.com>> wrote: > > Hi Shariful, > > You just call mbedtls_calloc() (or let other functions call it). > It will use the memory pool set by mbedtls_memory_buffer_alloc_init(). > > The memory_buffer_alloc module does not support multiple memory > pools. If you want a separate pool for each thread's allocation > for performance reasons on a multicore system, you'd better rely > on your platform's built-in calloc(). It's likely to be > fined-tuned for multicore operation. The built-in allocator in > Mbed TLS is intended for highly resource-constrained systems where > the basic platform doesn't even include an allocator. > > Best regards, > > -- > Gilles Peskine > Mbed TLS developer > > On 20/07/2021 22:10, Shariful Alam wrote: >> 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 >> <mailto:mbed-tls@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> >> <https://pastebin.com/uyW3vknt <https://pastebin.com/uyW3vknt>> >> > >> > Thanks, >> > Shariful >> > >> >> -- >> mbed-tls mailing list >> mbed-tls(a)lists.trustedfirmware.org >> <mailto:mbed-tls@lists.trustedfirmware.org> >> https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls >> <https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls> >> >

3 years, 11 months

1
0
0 0

Could memory leak or heap fragmentation be the issue?

by Alan Chen

I posted the question on the mbedTLS forum, only to realized that mbedTLS is now maintained by the project's mailing list. Here is the copy of what I wrote: *Occasionally* I am getting MBEDTLS_ERR_SSL_ALLOC_FAILED from mbedtls_ssl_setup() during repeated HTTP partial content download. Since this problem happens very rarely, it is a bit difficult to troubleshoot. I am running mbedTLS on a Microchip PIC32MZ MCU, connected to a LTE-M/NB-IoT modem. I have 128K static memory reserved for the library with MBEDTLS_PLATFORM_MEMORY defined in the config.h file. The MCU runs two main tasks - MQTT client, talking to the AWS MQTT broker, and HTTPS client, for downloading new firmware image from the AWS S3 bucket over the air. Due to the slowness and limited bandwidth of the LTE-M and NB-IoT technologies, the HTTP file download has to use the partial content GET, basically 2KB per request, until all ~700KB of data are received. During the course of the file download, one can see as many as 30 disconnect and reconnect, and each time the TLS session would close down and re-open once the cell network is established. Here are some of my functions: ``` #define MBEDTLS_MAX_MEMORY_ALLOCATED (1024 * 128) static uint8_t tls_memory_buf[MBEDTLS_MAX_MEMORY_ALLOCATED]; // called in main() void mbedtls_mem_init(void) { mbedtls_memory_buffer_alloc_init(tls_memory_buf, sizeof tls_memory_buf); } void HTTPS_TLS_CLOSE(void) { if (server_fd_https.fd != -1) { mbedtls_entropy_free(&entropy_https); mbedtls_x509_crt_free(&cacert_https); mbedtls_ctr_drbg_free(&ctr_drbg_https); mbedtls_ssl_config_free(&conf_https); mbedtls_ssl_free(&ssl_https); server_fd_https.fd = -1; } } bool HTTPS_TLS_OPEN(void) { int ret; const char *pers = "https_tls_wrapper"; server_fd_https.fd = 1; mbedtls_debug_set_threshold(1); mbedtls_ssl_init(&ssl_https); mbedtls_ssl_config_init(&conf_https); mbedtls_ctr_drbg_init(&ctr_drbg_https); mbedtls_x509_crt_init(&cacert_https); mbedtls_entropy_init(&entropy_https); mbedtls_entropy_add_source(&entropy_https, my_https_entropy, NULL, sizeof my_https_random, MBEDTLS_ENTROPY_SOURCE_STRONG); ret = mbedtls_ctr_drbg_seed(&ctr_drbg_https, mbedtls_entropy_func, &entropy_https, (const unsigned char *)pers, strlen(pers)); if (ret != 0) { printf("%s: mbedtls_ctr_drbg_seed ERROR -0x%x\r\n", __FUNCTION__, -ret); return false; } ret = mbedtls_x509_crt_parse(&cacert_https, TRUSTED_ROOT_CA, TRUSTED_ROOT_CA_SIZE); if (ret != 0) { printf("%s: mbedtls_x509_crt_parse cacert ERROR -0x%x\r\n", __FUNCTION__, -ret); return false; } ret = mbedtls_ssl_config_defaults(&conf_https, MBEDTLS_SSL_IS_CLIENT, MBEDTLS_SSL_TRANSPORT_STREAM, MBEDTLS_SSL_PRESET_DEFAULT); if (ret != 0) { printf("%s: mbedtls_ssl_config_defaults ERROR -0x%x\r\n", __FUNCTION__, -ret); return false; } mbedtls_ssl_conf_verify(&conf_https, NULL, NULL); mbedtls_ssl_conf_authmode(&conf_https, MBEDTLS_SSL_VERIFY_REQUIRED); mbedtls_ssl_conf_rng(&conf_https, mbedtls_ctr_drbg_random, &ctr_drbg_https); mbedtls_ssl_conf_dbg(&conf_https, my_https_debug, stdout); mbedtls_ssl_conf_ca_chain(&conf_https, &cacert_https, NULL); mbedtls_ssl_conf_read_timeout(&conf_https, TLS_TIMEOUT_MS); HTTPS_SetHostname(); /* calling mbedtls_ssl_set_hostname */ ret = mbedtls_ssl_setup(&ssl_https, &conf_https); if (ret != 0) { printf("%s: mbedtls_ssl_setup ERROR -0x%x\r\n", __FUNCTION__, -ret); return false; } mbedtls_ssl_set_bio(&ssl_https, &server_fd_https, mbedtls_https_send, mbedtls_https_recv, NULL); return true; } ``` Can someone please tell me if I am doing something inappropriate here? I am speculating that perhaps there is a memory leak or the heap becomes so fragmented that it fails on mbedtls_calloc(). The exact error message in my case is: > ../mbedtls_lib/ssl_tls.c:5661: alloc(16717 bytes) failed Thanks. Alan Chen ________________________________ [https://secureimages.mcafee.com/common/affiliateImages/mfe/logo.png]<https://home.mcafee.com/utm_medium=email&utm_source=link&utm_campaign=sig-e…> Scanned by McAfee<https://home.mcafee.com/utm_medium=email&utm_source=link&utm_campaign=sig-e…> and confirmed virus-free.

3 years, 11 months

1
0
0 0

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

by Dave Rodgman

Sorry, just realised that myself! Gilles is correct, I should have said 2.28. Thanks Dave On 29/07/2021, 14:25, "mbed-tls on behalf of Gilles Peskine via mbed-tls" <mbed-tls-bounces(a)lists.trustedfirmware.org on behalf of mbed-tls(a)lists.trustedfirmware.org> wrote: 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 > > -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

3 years, 11 months

1
0
0 0

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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 12 months

1
0
0 0

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

by Gilles Peskine

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, -- Gilles Peskine Mbed TLS developer On 05/07/2021 18:10, Danny Backx via mbed-tls wrote: > > Hi, > > I must be missing something obvious but my code (on an ESP32) fails to > accept an incoming connection. > > I tried the same certificate on an ESP32 sample, and it appears to > work there. > > Does anyone have a clue where to look next ? > > Danny > > I (16:06:51.481) esp_https_server: performing session handshake > E (16:06:51.483) x509_crt: x509_crt_parse_der_core -> 0x2180 > E (16:06:51.484) esp_tls_mbedtls: set_pki_context: public_cert > 0x3ffdb924, len 5750 -> ret 0x2180 > E (16:06:51.493) esp-tls-mbedtls: mbedtls_x509_crt_parse returned -0x2180 > E (16:06:51.501) esp-tls-mbedtls: Failed to set server pki context > E (16:06:51.508) esp-tls-mbedtls: Failed to set server configurations > E (16:06:51.515) esp-tls-mbedtls: create_ssl_handle failed > E (16:06:51.521) esp_https_server: esp_tls_create_server_session failed > W (16:06:51.528) httpd: httpd_accept_conn: session creation failed > W (16:06:51.538) httpd: httpd_server: error accepting new connection > > -- > Danny Backx - dannybackx(a)telenet.be - http://danny.backx.info >

3 years, 12 months

1
0
0 0

mbedtls_x509_crt_parse returned -0x2180

by Danny Backx

Hi, I must be missing something obvious but my code (on an ESP32) fails to accept an incoming connection. I tried the same certificate on an ESP32 sample, and it appears to work there. Does anyone have a clue where to look next ? Danny I (16:06:51.481) esp_https_server: performing session handshake E (16:06:51.483) x509_crt: x509_crt_parse_der_core -> 0x2180 E (16:06:51.484) esp_tls_mbedtls: set_pki_context: public_cert 0x3ffdb924, len 5750 -> ret 0x2180 E (16:06:51.493) esp-tls-mbedtls: mbedtls_x509_crt_parse returned -0x2180 E (16:06:51.501) esp-tls-mbedtls: Failed to set server pki context E (16:06:51.508) esp-tls-mbedtls: Failed to set server configurations E (16:06:51.515) esp-tls-mbedtls: create_ssl_handle failed E (16:06:51.521) esp_https_server: esp_tls_create_server_session failed W (16:06:51.528) httpd: httpd_accept_conn: session creation failed W (16:06:51.538) httpd: httpd_server: error accepting new connection -- Danny Backx - dannybackx(a)telenet.be - http://danny.backx.info

3 years, 12 months

1
0
0 0

Hardware CCM decrypt failure

by Navin Reddy

Hello everyone, I am currently evaluating SSL with a local server and an STM32 device. I'm unable to figure out why the decryption fails with CCM as the cipher suite. FYI: I am using MbedTLS *v2.14.1.* *Setup*: I'm using *x86 local server* with *STM32* device as a client. Here is what happens- 1. Software CCM implementation on the client: When I use the *software* implementation of the CCM. Handshake and decryption is *successful*. Therefore, I can stream the data from STM32 and read it on the local server. 2. Hardware CCM implementation with MBEDTLS_CCM_ALT: I have used ccm_alt.c provided from STM32Cube v1.9.0. Here, the handshake is successful. But *decrypting* the message *fails*. The errors are: ssl_decrypt_buf() returned -29056 (-0x7180) mbedtls_ssl_read_record() returned -29056 (-0x7180) Checks performed: - Same certificates are used for SW and HW implementations. - CCM self test returns '0' for both HW and SW CCM implementations. - I have reserved enough heap, no memory issues. Please find all the necessary data in the attachment provided. I have added the logs from the server and the client. I have added the certificates and the code files as well. It would be of great help if somebody could point at what might be going wrong. Thank you! Best regards, Navin

3 years, 12 months

1
0
0 0

Re: [mbed-tls] Is the a version that can use the EdDSA signature algorithm currently?

by Janos Follath

Hi Shudong, Mbed TLS currently does not provide EdDSA. The contribution by @aurel32 is a first step in this direction. The work leading up to a fully functional EdDSA implementation is tracked here: https://github.com/ARMmbed/mbedtls/projects/2#column-11150355 Kind regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Shudong Zhang via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Date: Wednesday, 30 June 2021 at 07:28 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Is the a version that can use the EdDSA signature algorithm currently? Hello, I want to use EdDSA signature algorithm, but I did’t find API for it in 2.26.0.Then I searched in the issue of Github and I found @aurel32 contributed some code about ed25519.But I am still not sure whether there are any versions under development that provide interface functions for EdDSA signature algorithm. Can someone help me answer my question? Thanks and kind regards, Shudong

4 years

1
0
0 0

Is the a version that can use the EdDSA signature algorithm currently?

by Shudong Zhang

Hello, I want to use EdDSA signature algorithm, but I did’t find API for it in 2.26.0.Then I searched in the issue of Github and I found @aurel32 contributed some code about ed25519.But I am still not sure whether there are any versions under development that provide interface functions for EdDSA signature algorithm. Can someone help me answer my question? Thanks and kind regards, Shudong

4 years

1
0
0 0

2025

2024

2023

2022

2021

2020

mbed-tls