Repository navigation
mbedTLS 4 support on 2_x_dev — plans? #812
Description
Context
PR #782 landed mbedTLS 4 (PSA Crypto) support on main, which has since been renamed to libsrtp3 (v3.0.0). The 2.x line on 2_x_dev stayed on the legacy <mbedtls/aes.h> / <mbedtls/gcm.h> path, so v2.8.0 and later 2.x consumers still cannot build against mbedTLS 4.
This is starting to bite for the embedded / IoT world: ESP-IDF v6 (currently in pre-release, GA imminent) ships mbedTLS 4 by default. Anything still on the libsrtp 2.x line — and that's the mainstream of WebRTC consumers today, including the AWS Kinesis Video Streams C SDK — can't compile against IDF v6.
Question
What is the project's position on backporting PSA Crypto / mbedTLS 4 support to 2_x_dev?
Specifically:
- Is
2_x_devconsidered feature-frozen (security fixes only), with 3.x expected as the migration path? - If a backport gated on
MBEDTLS_VERSION_MAJOR >= 4(or>= 3for the full PSA path) is acceptable in principle, we'd be happy to send a PR. A direct cherry-pick of mbedtls files changed and cmake instruction added to support MbedTLS … #782 isn't clean — the 3.x release also changed the internal cipher signature (in-place → src/dst buffers), so the backport needs adaptation to keep the 2.x cipher API intact for existing consumers.
Either answer is fine — we just want to know whether to invest the work or accept the v6 ceiling on the 2.x line.
Happy to share the conflict list and a backport sketch if it helps the conversation.
Activity
pabuhler commentedon May 27, 2026
Hi, @vikramdattu as state in #669 I think supporting mdedtls 4 in the 2_x branch would be fine. The internal libSRTP API has not changed that much that I think it should not be that difficult.
I think my preference would be to do a full port to mbedtll 4, removing support for 3 in order to limit code and testing requirements, but am open to hear what you or other user of this think is best.
Feel free to create a PR even an incomplete one and I can help test etc.
vikramdattu commentedon May 28, 2026
@pabuhler thanks for the clarity.
I think, let me invest some time to backport mbedtls4.x on this version. Given the SDKs still not adopting to srtp3 and mbedtls 4 already being mainstream, it's only worthwhile to add this support.
Will raise a Draft PR in a day or two. With continuation to your discussion, if we get on a same page on tests and documentation, then we can go ahead with the merging the same next.
vikramdattu commentedon Jun 1, 2026
WIP draft up at #813 — both mbedTLS 3.6.4 and 4.0.0 pass 10/10 ctest locally. cc @pabuhler
mbedtls: add mbedTLS 4 / PSA Crypto support (WIP, gated)
seyednasermoravej commentedon Sep 16, 2026
Thank you for your interest in my previous work. I there anything I can help ether on the libSRTP side or on the ESP-IDF side?
About your question, in-place->src/dst buffers. No there not in-place. In fact, that's an MbedTLS known bug. But they don't have any on-going plan to fix it. Please check this:
Mbed-TLS/TF-PSA-Crypto#711
You should set this config in your MbedTLS
MBEDTLS_PSA_ASSUME_EXCLUSIVE_BUFFERS=n, other thesrtp_initfunction fails.