I'd like to know if there is some way to retrieve the currently available number of bytes of application data without calling mbedtls_ssl_read()?
I'm writing a "TLS socket" for higher layers to use and would like to notify them when new application data is available, tell them how much it is, but leave it up to them when and how much to retrieve.
I'd like to prevent having to buffer all application data inside my TLS socket, because that would mean copying it once from mbedtls' buffer to my socket and then again from there to the application whenever it actually requests the data.
After a quick look into the sources, it seems like, if at all, this might be possible for single records. But all related fields are private and I could not find any API for this.
Issue #551  seems related, but is more about peeking into the application data, while I would be fine with knowing just the size of available application data.
Thanks for any hints on how I could achieve this.
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
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?
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,
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. :)
TrustedFirmware Community Manager
We're seeing pretty much the same issue on 3.0.0 ARM. However, if I build the ssh_client2 tool on my host machine (x64) and try to mimic the config as close as possible, it works just fine.
Do you think we're seeing the same problem? Will try with a newer version next week.
I am wondering if there are APIs for Hmac and Cmac verification?
from md.h and cmac.h, Hmac and Cmac generation functionalities are provided
in a single and streaming approach. But is there a plan to add verification
APIs for future releases maybe?
What is the difference between these two macros in
In other words, why would I have two different user configuration files? Or
I misunderstand the difference between such files.
I am verifying a signature generated using ecdsa secp256r1. The signature is getting verified but the time taken by the verification step is too long. It takes 4-5 seconds to verify the signature. The implementation is bare metal i.e. no RTOS (one realizes the use of RTOS but still the time is too long). Can you please guide a way around for this issue. How to make it work faster , the ideal verification time would be 30ms - 60ms.
Here is a gist of my code
mbedtls_ecp_curve_info *curve_info = NULL;
curve_info = mbedtls_ecp_curve_info_from_tls_id(23); /// 23 is tls_id of secp256r1
result = mbedtls_ecp_point_read_binary(
public_key_data, // public key data in uncompressed format i.e. including leading 0x04
/// 32 /// 71
status_verify_signature = mbedtls_ecdsa_read_signature(&ecdsa_context, hash, sizeof(hash), signature, sizeof(sig)); /// converts the signature data to ASN1, verifies the signature
Thank you :)
Can please provide me with any example on "how to achieve Mutual
authentication(Client and server certificate validation)" in mbed-tls.
Please help me with this.It is a little urgent.