- mbed-tls - lists.trustedfirmware.org

How can I get plaintext rsa private key from .pem format?

by Shariful Alam

Hello, I found that, /programs/pkeyrsa_genkey.c creates a plaintext rsa private key. Is there any way I can generate the keys in the same format from a .pem format? Regards, Shariful Alam

4 years, 11 months

1
0
0 0

-0x7880 "error" after successful failed download

by Ron Eggler

Hi, I'm getting the following errors printed: tls : error : [2021/06/21 21:43:12.360] [id = 10]: ../../src/../externals/mbedtls/mbedtls/library/ssl_tls.c(4369): mbedtls_ssl_handle_message_type() returned -30848 (-0x7880) tls : error : [2021/06/21 21:43:12.360] [id = 11]: ../../src/../externals/mbedtls/mbedtls/library/ssl_tls.c(8335): mbedtls_ssl_read_record() returned -30848 (-0x7880) after a file is successfully downloaded. It looks like MBEDTLS_ERR_SSL_PEER_CLOSE_NOTIFY gets interpreted and printed as error. How can I fix this? Is this a configuration thing or do I edit the ssl_tls.c source code? Thank you, Ron mbedtls 2.16.0

4 years, 12 months

1
0
0 0

Re: [mbed-tls] FTPS: Bad Record Mac on login

by Ron Eggler

On 2021-08-16 11:11 a.m., Ron Eggler via mbed-tls wrote: > Hi, > > I am working on a client where I need to login to a FTPS server > (vsftpd). I establish the connection, exchange Hellos, certificate & > key exchange and all seems succesful and are happening fine. > > I am able to send "PBSZ 0" to the server which gets acknowledged with > "200 PBSZ set to 0." (as seen in Wireshark). > > Then, when it comes to sending "PROT P", I cannot see it encoded in > Wireshark. it just says "Application Data" and the next frame reads > "Alert (Level: Fatal, Description: Bad Record Mac)". I have > investigated my code (mostly for differences between "PBSZ 0" and > "PROT P" but came up empty) and have searched the web but have failed > to find the resolution to my problem, as of yet. It seems obvious that > the problem must be in my code but I seem to be unable to put my > finger on it! I thought I should check if someone here may have any > other hints that will help me resolve the problem. > > I have temporarily set "mbedtls_ssl_conf_authmode( &ctxt.conf, > MBEDTLS_SSL_VERIFY_NONE);" to make sure that the CA is not the causing > any issues. > I have been able to resolve this. It was caused by usage of different context structure pointers.

4 years, 12 months

1
0
0 0

FTPS: Bad Record Mac on login

by Ron Eggler

Hi, I am working on a client where I need to login to a FTPS server (vsftpd). I establish the connection, exchange Hellos, certificate & key exchange and all seems succesful and are happening fine. I am able to send "PBSZ 0" to the server which gets acknowledged with "200 PBSZ set to 0." (as seen in Wireshark). Then, when it comes to sending "PROT P", I cannot see it encoded in Wireshark. it just says "Application Data" and the next frame reads "Alert (Level: Fatal, Description: Bad Record Mac)". I have investigated my code (mostly for differences between "PBSZ 0" and "PROT P" but came up empty) and have searched the web but have failed to find the resolution to my problem, as of yet. It seems obvious that the problem must be in my code but I seem to be unable to put my finger on it! I thought I should check if someone here may have any other hints that will help me resolve the problem. I have temporarily set "mbedtls_ssl_conf_authmode( &ctxt.conf, MBEDTLS_SSL_VERIFY_NONE);" to make sure that the CA is not the causing any issues. Thank you!

5 years

1
0
0 0

record and no record delemma

by Dave Plater

Hi, I wonder if anyone can tell me what I'm doing wrong. I use a modified client1.c for getting payment objects from an aws address, curl says that the connection uses "SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256" if it's any use. I can retrieve any single payment object which has a content length of about 443 but when I try to get the entire record of payments of which I only need the first or latest payment to check that I'm in sync, I get "Last error was: -28928 - SSL - Bad input parameters to function". This started at a certain point in the payment object accumulation don't quite know when, the current record of all payments is 22526 and it grows with every transaction. The GET request for the all the payment objects ends in "/payments/" and for a single object /payments/ has the objects id appended to it. There must be a way to receive a truncated record of all payments. Here is my latest config.h: #ifndef MBEDTLS_CONFIG_H #define MBEDTLS_CONFIG_H /* System support */ //#define MBEDTLS_HAVE_ASM #define MBEDTLS_HAVE_TIME #define MBEDTLS_NO_PLATFORM_ENTROPY #define MBEDTLS_NO_DEFAULT_ENTROPY_SOURCES #define MBEDTLS_TEST_NULL_ENTROPY #define MBEDTLS_ERROR_C #define MBEDTLS_PLATFORM_C //#define MBEDTLS_PLATFORM_EXIT_ALT //#define MBEDTLS_PLATFORM_TIME_ALT //#define MBEDTLS_PLATFORM_FPRINTF_ALT //#define MBEDTLS_PLATFORM_PRINTF_ALT //#define MBEDTLS_PLATFORM_SNPRINTF_ALT //#define MBEDTLS_PLATFORM_VSNPRINTF_ALT //#define MBEDTLS_PLATFORM_NV_SEED_ALT //#define MBEDTLS_PLATFORM_SETUP_TEARDOWN_ALT /* mbed TLS feature support */ #define MBEDTLS_CIPHER_MODE_CBC #define MBEDTLS_PKCS1_V15 #define MBEDTLS_KEY_EXCHANGE_RSA_ENABLED #define MBEDTLS_SSL_PROTO_TLS1_2 #define MBEDTLS_SSL_CLI_C #define MBEDTLS_SSL_TLS_C #define MBEDTLS_ENTROPY_C #define MBEDTLS_NO_DEFAULT_ENTROPY_SOURCES //experiment #define MBEDTLS_KEY_EXCHANGE_RSA_ENABLED #define MBEDTLS_KEY_EXCHANGE_ECDHE_RSA_ENABLED #define MBEDTLS_ECDH_C #define MBEDTLS_ECP_C #define MBEDTLS_ECP_DP_SECP192R1_ENABLED #define MBEDTLS_RSA_C #define MBEDTLS_OID_C #define MBEDTLS_PKCS1_V15 #define MBEDTLS_X509_CRT_PARSE_C #define MBEDTLS_CIPHER_C #define MBEDTLS_MD_C #define MBEDTLS_BIGNUM_C #define MBEDTLS_SHA256_C #define MBEDTLS_PK_PARSE_C #define MBEDTLS_PK_C #define MBEDTLS_ASN1_PARSE_C /* mbed TLS modules */ #define MBEDTLS_AES_C /* #define MBEDTLS_ASN1_WRITE_C #define MBEDTLS_BIGNUM_C #define MBEDTLS_CIPHER_C #define MBEDTLS_CTR_DRBG_C #define MBEDTLS_DES_C #define MBEDTLS_MD_C #define MBEDTLS_MD5_C //#define MBEDTLS_RSA_C #define MBEDTLS_SHA1_C #define MBEDTLS_SHA256_C */ #define MBEDTLS_X509_USE_C /* For test certificates */ #define MBEDTLS_BASE64_C #define MBEDTLS_CERTS_C #define MBEDTLS_PEM_PARSE_C /* Limit memory use*/ #define MBEDTLS_SSL_MAX_CONTENT_LEN 16384 /* For testing with compat.sh */ //#define MBEDTLS_FS_IO #include "check_config.h" #endif /* MBEDTLS_CONFIG_H */ Thanks, Dave P

5 years

1
0
0 0

Compare certs' RSA keys, subjects etc..

by Nassim Eddequiouaq

Hi, I'd like to compare a signing cert in a cert chain against a pinned cert. Given two mbedtls_x509_crt (or two mbedtls_rsa_context), what is the recommended way to compare them? Thanks! -- Nassim Eddequiouaq

5 years

1
0
0 0

Re: [mbed-tls] Could memory leak or heap fragmentation be the issue?

by Gilles Peskine

Hello, I don't see anything obviously wrong with the code. Heap fragmentation is a possibility. A memory leak is also a possibility; we do fairly extensive testing for memory leaks in unit tests, but this doesn't catch unusual conditions (especially not recovering after a low-memory condition). I think the first tool to investigate is to enable MBEDTLS_MEMORY_DEBUG. This has a small cost in code size and gives you access to some introspection functions mbedtls_memory_buffer_alloc_status() and mbedtls_memory_buffer_alloc_max_get(). Call these functions on an error, and also perhaps at other times for comparison. There's also an option MBEDTLS_MEMORY_BACKTRACE which creates extremely verbose logs. Those logs might be helpful, but they're so verbose that they often aren't practical in a real-world application. I notice that the allocation is for a little over 16kB. The default size of the SSL input/output buffers is 16kB because that's the maximum size of a message according to the specification. However you can usually get away with a lot less, especially on IoT networks where the infrastructure is geared towards much smaller messages. See https://tls.mbed.org/kb/how-to/controlling_package_size <https://tls.mbed.org/kb/how-to/controlling_package_size> for more information on message sizes and buffer sizes. If the problem is a memory leak, smaller buffers will only delay the failure. But if the problem is that the application just needs a bit more heap space, this could solve the problem. Concretely, try setting MBEDTLS_SSL_IN_CONTENT_LEN and MBEDTLS_SSL_OUT_CONTENT_LEN in the compile-time configuration to much lower values. MBEDTLS_SSL_OUT_CONTENT_LEN can be as low as you like as long as the handshake messages fit. MBEDTLS_SSL_IN_CONTENT_LEN has to be large enough for the messages that you're sent. Alternatively, enable the option MBEDTLS_SSL_VARIABLE_BUFFER_LENGTH, which results in smaller buffers but can make fragmentation worse due to reallocations. Hope this helps. -- Gilles Peskine Mbed TLS developer On 01/08/2021 22:40, Alan Chen via mbed-tls wrote: > > 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://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. > >

5 years

1
0
0 0

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

5 years

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> >> >

5 years

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.

5 years

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

5 years

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 > >

5 years

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

5 years

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

5 years

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 > >

5 years

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 >

5 years

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

5 years

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 >

5 years

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

5 years

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,

5 years, 1 month

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

5 years, 1 month

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

5 years, 1 month

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

5 years, 1 month

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

5 years, 1 month

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

5 years, 1 month

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

mbed-tls