I meet a problem when I call function `psa_crypto_init`, it return error code -148 that was PSA_ERROR_INSUFFICIENT_ENTROPY.
I track this function step by step and found it caused by MBEDTLS_ERR_ENTROPY_NO_SOURCES_DEFINED. Code in entropy.c, if( ctx->source_count == 0 ), return this error.
My question:
I run code on Ubuntu, it runs well. But in some arm board, it returns this error. Why this count will be 0 sometimes? What is the root cause of this error.
Hi All,
A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum
is next Monday at 4:30 PM UK time. Invite details can be found on the
online calendar here <https://www.trustedfirmware.org/meetings/>.
If you have any topics, please let Dave Rodgman know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hi,
I have developed a TLS and EST client application. Where the EST server issues the certificate in PKCS#7 format. It seems mbedtls library not support certificates in PKCS#7 format.
Is there any plan to support PKCS#7 in future?
Thanks,
Gopi Krishnan
Hi All,
A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech
forum is next *Monday, Oct 10 at 10:00am UK time*. Invite details can be
found on the online calendar here
<https://www.trustedfirmware.org/meetings/>.
If you have any topics, please let Dave Rodgman, cc'd, know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hello
Please note that this is a repost from my previous message from yesterday
as it seemd to have bugged (empty text + html attachement) when viewed
from the archive. Apologies.
Short question :
how do i output an in-memory mbedtls_x509_crt chain to PEM text ?
Context :
I have a project where the user provides a PEM bundle to be used for HTTPS
As it is provided by a user, may be incomplete or malformed :
- no private key
- more than 1 private key
- no certificate at all
- duplicate certificates
- no certificate matching the private key
- broken chain
- extraneous certificates not part of the chain…
So i want to full validate user input.
Here is what i have succeeded so far :
- parse the bundle into atomic parts, based on « BEGIN/END » labels
- try to mbedtls_x509_crt_parse / mbedtls_pk_parse_key each part (no chain)
- check that i only have one private key in the bundle
- search for the certificat C matching the private key
- starting from that atomic certificate, verify it against each other
candidate certificate
- if it validates, add it to the chain of C, and repeat until no
candidate validates
- then check that there are no remaining certificate (which never
validated anything)
- finally print and store the chain (as it’s now deemed correct and minimal)
Now i want to store it in PEM format for later use.
But i do not understand the way to do it :
- there are no write functions for mbedtls_x509_crt
- the mbedtls_x509write_cert structure shares few members with mbedtls_x509_crt
- i have not found yet how to get/convert many of the missing members
- as memory is tight i have have cleaned the « atomic parts » text buffers
(but if there is no other way, i'll keep and reuse them)
I guess it should be pretty simple, but i cannot wrap my head around it.
Thanks in advance for your help
Nicolas
PS : if steps 1-8 could be done more elegantly, please do not
hesitate to point me in the right direction.
Hi,
In mbedTLS road map, there is a future task to remove legacy cipher API (https://developer.trustedfirmware.org/w/mbed-tls/roadmap/). Does that mean all existing mbedtls crypto APIs will not be supported anymore?
mbedTLS is used for both its TLS and crypto library. I am curious how the planned changes will affect both set of users.
* Are the crypto library users expected to only use PSA crypto APIs and key IDs?
* Are the TLS library users expected to see API changes to TLS functions to support key IDs?
Thank,
Archanaa
Hi guys,
I use mbedtls for years (since 2.10 IIRC) upgrading to latest available as time goes by. For DTLS that is.
I remember a case in the past where a link would have a small MTU (around 500 bytes) and I had to tune ssl_context.handshake.mtu to a lower value to successfully complete handshakes.
I do not remember exactly why, but I did not want to actually restrict maximum value via mbedtls_ssl_set_mtu, maybe it was even ignored back then for handshakes… but
Now when working on migration to 3.2.1 (gave some time to 3x releases to stabilize) I noticed that the whole ssl_context.handshake member is now private and inaccessible, which I guess is fine.
Could somebody with more knowledge of the code recommend what is the best strategy for DTLS app where MTU may not always be 1400?
thanks a lot for your time,
Martin
Hi All,
A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum
is next Monday at 4:30 PM UK time. Invite details can be found on the
online calendar here <https://www.trustedfirmware.org/meetings/>.
If you have any topics, please let Dave Rodgman know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
