Hi,
As suggested by @Gilles Peskine , I did try enabling MBEDTLS_ENTROPY_FORCE_SHA256 , but even after enabling this mbedtls_ctr_drbg_seed was still returning 0X0034 (MBEDTLS_ERR_CTR_DRBG_ENTROPY_SOURCE_FAILED ), please note that I'm using NVRAM for Seeding. I'm attaching my config.h file along with this mail for you reference.
PFA
-----Original Message-----
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of mbed-tls-request(a)lists.trustedfirmware.org
Sent: Thursday, January 28, 2021 1:19 AM
To: mbed-tls(a)lists.trustedfirmware.org
Subject: mbed-tls Digest, Vol 11, Issue 7
This message is from an external sender. Be cautious, especially with links and attachments.
Send mbed-tls mailing list submissions to
mbed-tls(a)lists.trustedfirmware.org
To subscribe or unsubscribe via the World Wide Web, visit
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
or, via email, send a message with subject or body 'help' to
mbed-tls-request(a)lists.trustedfirmware.org
You can reach the person managing the list at
mbed-tls-owner(a)lists.trustedfirmware.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of mbed-tls digest..."
Today's Topics:
1. Re: ENTROPY_SOURCE_FAILED :0x0034 (Gilles Peskine)
2. Re: Reduce mbedTLS memory and storage footprint (Gilles Peskine)
----------------------------------------------------------------------
Message: 1
Date: Wed, 27 Jan 2021 20:36:18 +0100
From: Gilles Peskine <gilles.peskine(a)arm.com>
To: mbed-tls(a)lists.trustedfirmware.org
Subject: Re: [mbed-tls] ENTROPY_SOURCE_FAILED :0x0034
Message-ID: <9fcd3d55-ad54-05cf-63f9-7f3d09f3ee0d(a)arm.com>
Content-Type: text/plain; charset=windows-1252
Hello,
The entropy module uses a hash to mix the entropy. It uses SHA-512 if present and SHA-256 otherwise. Depending on the hash function, the entropy module can return either up to 64 bytes (SHA-512) or 32 bytes (SHA-256). The CTR_DRBG module knows about this and requests only 32 bytes at a time if the entropy module only delivers 32 bytes at a time.
It looks like something goes wrong when CTR_DRBG tries to request 64 bytes. This could be, for example, because a buffer is too small somewhere, or because of a limitation of the entropy source. You would need to debug the call to mbedtls_entropy_func to know more.
As a workaround, you can enable MBEDTLS_ENTROPY_FORCE_SHA256. Then the entropy module will use SHA-256 (even if MBEDTLS_SHA512_C is enabled) and only return 32 bytes at a time, and CTR_DRBG understands this and will only request 32 bytes.
--
Gilles Peskine
Mbed TLS developer
On 27/01/2021 06:08, T V LIJIN (EXT) via mbed-tls wrote:
> Hi,
> After enabling *MBEDTLS_NO_PLATFORM_ENTROPY* and*MBEDTLS_SHA512_C* ,
> /mbedtls_ctr_drbg_seed/ is returning *0x0034
> */(MBEDTLS_ERR_CTR_DRBG_ENTROPY_SOURCE_FAILED)/
> But if I just enable *MBEDTLS_NO_PLATFORM_ENTROPY* and keep
> *MBEDTLS_SHA512_C* disabled, it does not return any error for
> /mbedtls_ctr_drbg_seed./ / / My project uses certificates with SHA384
> signature, so it requires***MBEDTLS_SHA512_C *to be enabled.
> /*MBEDTLS_NO_PLATFORM_ENTROPY* and*MBEDTLS_SHA512_C* /both needs to be
> enabled in my project , but Iam facing issue with
> mbedtls_ctr_drbg_seed returning 0x0034. Please guide me on this. What
> might be the reason for mbedtls_ctr_drbg_seed to fail while
> enabling/////*MBEDTLS_SHA512_C.*/////
> How to overcome this issue?
>
>
> Thanks,
> LIJIN T V
>
------------------------------
Message: 2
Date: Wed, 27 Jan 2021 20:48:27 +0100
From: Gilles Peskine <gilles.peskine(a)arm.com>
To: mbed-tls(a)lists.trustedfirmware.org
Subject: Re: [mbed-tls] Reduce mbedTLS memory and storage footprint
Message-ID: <b59f3e91-ae60-fae6-5fca-402894b0a890(a)arm.com>
Content-Type: text/plain; charset=windows-1252
Hello,
The most important thing is to make sure you've disabled all the features you don't need in config.h. The default configuration enables most cryptographic mechanisms, but typical constrained systems usually only need a few.
If your toolchain supports it, use link-time optimization (e.g. gcc -Os -flto or clang -Oz -flto). I've seen that this makes a significant improvement for Mbed TLS (I got -30% on one build, obviously the numbers depend heavily on the configuration and the compiler). (In contrast LTO when optimizing for performance doesn't seem to improve anything.)
MBEDTLS_MPI_WINDOW_SIZE, MBEDTLS_MPI_MAX_SIZE and MBEDTLS_ECP_MAX_BITS only impact memory usage (stack and heap), not code size.
--
Gilles Peskine
Mbed TLS developer
On 27/01/2021 05:36, T V LIJIN (EXT) via mbed-tls wrote:
> Hi,
> I'm trying to optimize the size of my binary file by making the
> following changes in "*mbedtls/config.h*"
>
> #define MBEDTLS_MPI_WINDOW_SIZE 1
> #define MBEDTLS_MPI_MAX_SIZE 32
> #define MBEDTLS_ECP_MAX_BITS 256
> #define MBEDTLS_SHA256_SMALLER
>
> Even after making the above changes I couldn't see any change in the
> binary size.
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftls.
> mbed.org%2Fkb%2Fhow-to%2Freduce-mbedtls-memory-and-storage-footprint&a
> mp;data=04%7C01%7Clijin.tv%40kone.com%7C1a138332ca084342827b08d8c2fc9d
> b9%7C2bb82c642eb143f78862fdc1d2333b50%7C0%7C0%7C637473737538267015%7CU
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiLCJXVCI6Mn0%3D%7C1000&sdata=ql17fsSC0eX7Hq5ofrsWAe%2BEenOc2piLq
> 4jBix%2Bjr20%3D&reserved=0
> - This is the link I referred to follow the above-mentioned steps.
> Is there anything else I can try to reduce my final binary file size
> (ROM size) ?
>
>
> Thanks,
> LIJIN T V
>
------------------------------
Subject: Digest Footer
mbed-tls mailing list
mbed-tls(a)lists.trustedfirmware.org
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
------------------------------
End of mbed-tls Digest, Vol 11, Issue 7
***************************************
Hello,
The most important thing is to make sure you've disabled all the
features you don't need in config.h. The default configuration enables
most cryptographic mechanisms, but typical constrained systems usually
only need a few.
If your toolchain supports it, use link-time optimization (e.g. gcc -Os
-flto or clang -Oz -flto). I've seen that this makes a significant
improvement for Mbed TLS (I got -30% on one build, obviously the numbers
depend heavily on the configuration and the compiler). (In contrast LTO
when optimizing for performance doesn't seem to improve anything.)
MBEDTLS_MPI_WINDOW_SIZE, MBEDTLS_MPI_MAX_SIZE and MBEDTLS_ECP_MAX_BITS
only impact memory usage (stack and heap), not code size.
--
Gilles Peskine
Mbed TLS developer
On 27/01/2021 05:36, T V LIJIN (EXT) via mbed-tls wrote:
> Hi,
> I'm trying to optimize the size of my binary file by making the
> following changes in "*mbedtls/config.h*"
>
> #define MBEDTLS_MPI_WINDOW_SIZE 1
> #define MBEDTLS_MPI_MAX_SIZE 32
> #define MBEDTLS_ECP_MAX_BITS 256
> #define MBEDTLS_SHA256_SMALLER
>
> Even after making the above changes I couldn't see any change in the
> binary size.
> https://tls.mbed.org/kb/how-to/reduce-mbedtls-memory-and-storage-footprint
> - This is the link I referred to follow the above-mentioned steps.
> Is there anything else I can try to reduce my final binary file size
> (ROM size) ?
>
>
> Thanks,
> LIJIN T V
>
Hello,
The entropy module uses a hash to mix the entropy. It uses SHA-512 if
present and SHA-256 otherwise. Depending on the hash function, the
entropy module can return either up to 64 bytes (SHA-512) or 32 bytes
(SHA-256). The CTR_DRBG module knows about this and requests only 32
bytes at a time if the entropy module only delivers 32 bytes at a time.
It looks like something goes wrong when CTR_DRBG tries to request 64
bytes. This could be, for example, because a buffer is too small
somewhere, or because of a limitation of the entropy source. You would
need to debug the call to mbedtls_entropy_func to know more.
As a workaround, you can enable MBEDTLS_ENTROPY_FORCE_SHA256. Then the
entropy module will use SHA-256 (even if MBEDTLS_SHA512_C is enabled)
and only return 32 bytes at a time, and CTR_DRBG understands this and
will only request 32 bytes.
--
Gilles Peskine
Mbed TLS developer
On 27/01/2021 06:08, T V LIJIN (EXT) via mbed-tls wrote:
> Hi,
> After enabling *MBEDTLS_NO_PLATFORM_ENTROPY* and*MBEDTLS_SHA512_C* ,
> /mbedtls_ctr_drbg_seed/ is returning *0x0034
> */(MBEDTLS_ERR_CTR_DRBG_ENTROPY_SOURCE_FAILED)/
> But if I just enable *MBEDTLS_NO_PLATFORM_ENTROPY* and keep
> *MBEDTLS_SHA512_C* disabled, it does not return any error for
> /mbedtls_ctr_drbg_seed./
> /
> /
> My project uses certificates with SHA384 signature, so it
> requires***MBEDTLS_SHA512_C *to be enabled.
> /*MBEDTLS_NO_PLATFORM_ENTROPY* and*MBEDTLS_SHA512_C* /both needs to be
> enabled in my project , but Iam facing issue with
> mbedtls_ctr_drbg_seed returning 0x0034. Please guide me on this. What
> might be the reason for mbedtls_ctr_drbg_seed to fail while
> enabling/////*MBEDTLS_SHA512_C.*/////
> How to overcome this issue?
>
>
> Thanks,
> LIJIN T V
>
Hi,
After enabling MBEDTLS_NO_PLATFORM_ENTROPY and MBEDTLS_SHA512_C , mbedtls_ctr_drbg_seed is returning 0x0034 (MBEDTLS_ERR_CTR_DRBG_ENTROPY_SOURCE_FAILED)
But if I just enable MBEDTLS_NO_PLATFORM_ENTROPY and keep MBEDTLS_SHA512_C disabled, it does not return any error for mbedtls_ctr_drbg_seed.
My project uses certificates with SHA384 signature, so it requires MBEDTLS_SHA512_C to be enabled.
MBEDTLS_NO_PLATFORM_ENTROPY and MBEDTLS_SHA512_C both needs to be enabled in my project , but Iam facing issue with mbedtls_ctr_drbg_seed returning 0x0034. Please guide me on this. What might be the reason for mbedtls_ctr_drbg_seed to fail while enabling MBEDTLS_SHA512_C.
How to overcome this issue?
Thanks,
LIJIN T V
Hi,
I'm trying to optimize the size of my binary file by making the following changes in "mbedtls/config.h"
#define MBEDTLS_MPI_WINDOW_SIZE 1
#define MBEDTLS_MPI_MAX_SIZE 32
#define MBEDTLS_ECP_MAX_BITS 256
#define MBEDTLS_SHA256_SMALLER
Even after making the above changes I couldn't see any change in the binary size.
https://tls.mbed.org/kb/how-to/reduce-mbedtls-memory-and-storage-footprint - This is the link I referred to follow the above-mentioned steps.
Is there anything else I can try to reduce my final binary file size (ROM size) ?
Thanks,
LIJIN T V
Dear,
In our project, our device should act as both client and server. Is it
possible for both TLS and DTLS? If yes, how about the certificate? Do we
need only 2 certs for this divice (one for the server role and one for
the client role)?
Best regards,
Farhad
Hello,
There is work in progress by community members to implement PKCS#7
SignedData parsing and generation.
https://github.com/ARMmbed/mbedtls/pull/3970https://github.com/ARMmbed/mbedtls/pull/3431
Arm has no particular plans in this area, but if you need other parts of
PKCS#7, we'd be happy to accept more contributions. We'll can't commit
to doing any development, but we'll assist with submissions and review
code as usual.
--
Gilles Peskine
Mbed TLS developer
On 13/01/2021 07:31, Subramanian Gopi Krishnan via mbed-tls wrote:
>
> Hi,
>
>
>
> Is there a plan to support PKCS#7 Certificate in
> future? We are work with rfc7030 service, which issues certificate in
> PKCS#7 format.
>
>
>
> Thanks,
>
> Gopi Krishnan
>
>
Hi,
Is there a plan to support PKCS#7 Certificate in future? We are work with rfc7030 service, which issues certificate in PKCS#7 format.
Thanks,
Gopi Krishnan
This is a notice that Mbed TLS 2.7 will no longer be supported or maintained after February 5th 2021. Mbed TLS 2.7.0 was released on February 5th 2018 with a three year support period.
The current version of Mbed TLS 2.7 is 2.7.18, which was released on December 11th 2020. There are no pending bug or security fixes, so unless new issues arise during the next month, there will not be another release of 2.7. We do not plan to merge any non-critical backports to 2.7 in the next month.
We recommend that where practical, users upgrade to either 2.16, which will be supported until the end of 2021, or to the development branch, which will be released as an LTS in mid 2021, with an expected support period until mid 2024.
Dave Rodgman
Hi,
Hanno suggested me to post our discussion here:
We use mbedtls in Facebook family apps. One of missing features is the ability to delegate cert verification to application. Hanno has pointed us to a similar ask in https://github.com/ARMmbed/mbedtls/pull/2091
We implemented cert verification process in Android/java and iOS/objective-C. Having this feature enables us to use the OS module for cert verification. The motivation is reduced maintenance cost. Some mobile APPs use OS TLS stack (rather than bundle mbedtls or openssl in the binary), so we have to maintain our OS-specific cert verification modules anyways. It’ll be ideal if we only keep the Android and iOS implementations as source of truth.
Any thoughts on supporting this?
Thanks,
Junqi
