Missing files during installation #237
Comments
|
Sorry for that. I think this is a bug we fixed in the current development branch: 52a5079 Unfortunately, there was also a bug in our CMakeLists.txt that caused install to fail, so there is no obvious workaround except applying the above patch, using the development branch (which should be safe, it's only bug fixes for now), or copying those files manually. |
|
Ah, great. Thanks! |
ghost
closed this as
Patater
pushed a commit
to Patater/mbedtls
that referenced
this issue
Aug 30, 2019
According to SP800-90A, the DRBG seeding process should use a nonce of length `security_strength / 2` bits as part of the DRBG seed. It further notes that this nonce may be drawn from the same source of entropy that is used for the first `security_strength` bits of the DRBG seed. The present HMAC DRBG implementation does that, requesting `security_strength * 3 / 2` bits of entropy from the configured entropy source in total to form the initial part of the DRBG seed. However, some entropy sources may have thresholds in terms of how much entropy they can provide in a single call to their entropy gathering function which may be exceeded by the present HMAC DRBG implementation even if the threshold is not smaller than `security_strength` bits. Specifically, this is the case for our own entropy module implementation which only allows requesting at most 32 Bytes of entropy at a time in configurations disabling SHA-512, and this leads to runtime failure of HMAC DRBG when used with Mbed Crypto' own entropy callbacks in such configurations. This commit fixes this by splitting the seed entropy acquisition into two calls, one requesting `security_strength` bits first, and another one requesting `security_strength / 2` bits for the nonce. Fixes Mbed-TLS#237.
Patater
pushed a commit
to Patater/mbedtls
that referenced
this issue
Aug 30, 2019
According to SP800-90A, the DRBG seeding process should use a nonce of length `security_strength / 2` bits as part of the DRBG seed. It further notes that this nonce may be drawn from the same source of entropy that is used for the first `security_strength` bits of the DRBG seed. The present HMAC DRBG implementation does that, requesting `security_strength * 3 / 2` bits of entropy from the configured entropy source in total to form the initial part of the DRBG seed. However, some entropy sources may have thresholds in terms of how much entropy they can provide in a single call to their entropy gathering function which may be exceeded by the present HMAC DRBG implementation even if the threshold is not smaller than `security_strength` bits. Specifically, this is the case for our own entropy module implementation which only allows requesting at most 32 Bytes of entropy at a time in configurations disabling SHA-512, and this leads to runtime failure of HMAC DRBG when used with Mbed Crypto' own entropy callbacks in such configurations. This commit fixes this by splitting the seed entropy acquisition into two calls, one requesting `security_strength` bits first, and another one requesting `security_strength / 2` bits for the nonce. Fixes Mbed-TLS#237.
gilles-peskine-arm
pushed a commit
to gilles-peskine-arm/mbedtls
that referenced
this issue
Sep 3, 2019
According to SP800-90A, the DRBG seeding process should use a nonce of length `security_strength / 2` bits as part of the DRBG seed. It further notes that this nonce may be drawn from the same source of entropy that is used for the first `security_strength` bits of the DRBG seed. The present HMAC DRBG implementation does that, requesting `security_strength * 3 / 2` bits of entropy from the configured entropy source in total to form the initial part of the DRBG seed. However, some entropy sources may have thresholds in terms of how much entropy they can provide in a single call to their entropy gathering function which may be exceeded by the present HMAC DRBG implementation even if the threshold is not smaller than `security_strength` bits. Specifically, this is the case for our own entropy module implementation which only allows requesting at most 32 Bytes of entropy at a time in configurations disabling SHA-512, and this leads to runtime failure of HMAC DRBG when used with Mbed Crypto' own entropy callbacks in such configurations. This commit fixes this by splitting the seed entropy acquisition into two calls, one requesting `security_strength` bits first, and another one requesting `security_strength / 2` bits for the nonce. Fixes Mbed-TLS#237.
hanno-becker
pushed a commit
to hanno-becker/mbedtls
that referenced
this issue
May 4, 2021
…89_Review_EE_Parsing_Client Review fix for client side EncryptedExtensions parsing
iameli
pushed a commit
to livepeer/mbedtls
that referenced
this issue
Dec 5, 2023
…aning test/rtp_decoder.c spring cleaning
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When I unzip the mbed TLS 2.0.0 tarball, do a make and make install, the only file I see in /usr/local/lib is libmbedtls.a. The files libmbedcrypto.a and libmbedx509.a are missing. Why is this?
The Hiawatha webserver has an option to use the mbed TLS library that is already installed on the system, instead of the one shipped with Hiawatha. But it won't compile, unless those two missing files are manually copied to /usr/local/lib.
Please, advice.
The text was updated successfully, but these errors were encountered: