Feature that allows single-pass processing of authentication + encryption

[TrinityTonic]

Note: This is just a template, so feel free to use/remove the unnecessary things

Description

• Type: Feature Request
• Priority: Minor

---

Enhancement\Feature Request

Single-pass processing for authentication and encryption

Justification - why does the library need this feature?
The feature would enable the use of mbedTLS for high-performance applications running on systems that have cryptographic accelerators for single-pass processing of both the authentication and encryption step.

Suggested enhancement
Some cryptographic accelerators offer authentication and encryption (AEAD is not meant here) in one single step by means of a DMA descriptor and an intelligent crypto unit. Using a non-AEAD ciphersuite such as *_AES128_CBC_SHA256 for example both the authentication and the encryption could be done within one single step saving quite some memory operations on the CPU. As far as I understand the mbedTLS API does not allow a combined encryption and authentication step but rather splits these in sequential operations. Furthermore no alternative implementations can be enabled for a combined authentication and encryption - only for single algorithms by themselves.

Is a feature like this in planning?
Are there even ways at the moment to achieve this with mbedTLS?

---

[gilles-peskine-arm]

We now prioritize the PSA API (psa_xxx functions) for new crypto features in Mbed TLS.

Under the new API, the way to to plug in a combined accelerator for authentication and encryption would be to declare an AEAD algorithm for the desired flavor of CBC+HMAC. We haven't done that because there's only limited demand for CBC+HMAC nowadays.

Is the use case that you're interested in TLS, or some other use of CBC+HMAC?

[TrinityTonic]

My usecase is the implementation of RTE (real-time-ethernet) protocols on top of TLS. These require very low latency and high performance. Answering your question - yes we are using TLS (mbedTLS) on top of those protocols and require CBC + HMAC as support for these ciphersuites are mandated by those protocols.

So did I get it correctly that support for single-pass CBC+HMAC will be available inside the PSA API and will not be inside the "normal" mbedtls_*** API?

[gilles-peskine-arm]

If you need high performance, isn't CCM (if you have AES acceleration but no GHASH acceleration) or GCM (otherwise) better than CBC+HMAC? Especially since TLS CBC+HMAC (without encrypt-then-mac) decryption can't be done quickly due to Lucky Thirteen countermeasures.

It's very unlikely that we'd add the feature under the mbedtls_xxx API. It's undecided whether we'll add the feature under the PSA API and the requisite support in Mbed TLS. CBC+HMAC cipher suites are somewhat deprecated these days since most of the world supports modern AEAD cipher suites. Adding the requisite support to the TLS code is not completely trivial. I'm personally not convinced it's worth the effort.

[TrinityTonic]

Hi, I'd prefer using the AEAD ciphersuites too. But the specification of that specific stack sadly requires CBC+HMAC to be used explicitly. They don't even allow AEAD cipherusites. It's still a high-performance Real-time-ethernet stack ... so performance is of uttermost importance. If it's not going into the current 2.x version, including it into the 3.0 version would really be a useful function for us.

[gilles-peskine-arm]

High-performance, CBC+HMAC cipher suites and low-latency networking are a bad combination.

A straightforward implementation of CBC+HMAC authenticated decryption is vulnerable to the Lucky Thirteen attack which allows an attacker able to monitor and inject traffic to decrypt traffic if they can make sufficiently precise measurements. In a real-time Ethernet environment, I expect even a network-based attacker to be able to make quite precise measurements.

Mbed TLS has progressively moved to a constant-time implementation of CBC+HMAC decryption. This protects even against powerful local attackers (attackers who can observe accesses to shared resources such as the memory cache or the branch predictor), but the cost is that decryption is significantly slower.

Constant-time might be overkill for a purely network-based attacker. If you want both high performance and defense against network-based attackers but not against local attackers, you only need code that performs the whole decryption in constant time, not code that accesses all shared resources in a data-independent manner. We used to have this weak countermeasure in Mbed TLS, and we could bring it back as a non-default option. However, the cost of bringing it back would be significant. It would increase the risk of misconfiguration, increase the testing and review burden, and make the corresponding code harder to maintain (it's bad enough as it is: the complexity of TLS 1.[0-2] cipher suites and extensions makes it hard to keep the code well-structured).

The best defense against Lucky 13 remains to change the protocol: use AEAD ciphersuites, or the encrypt-then-MAC extension. EtM was primarily designed for systems that lack AEAD crypto primitives (GCM or CCM), which today isn't much of an issue anymore.

I'm not familiar with the real-time Ethernet ecosystem. What is the security goal? Is there an effort to move away from CBC+HMAC? What standards/specifications are applicable?

[mpg]

@TrinityTonic

Hi, I'd prefer using the AEAD ciphersuites too. But the specification of that specific stack sadly requires CBC+HMAC to be used explicitly. They don't even allow AEAD cipherusites

Out of curiosity, has the situation changed in the meantime? Are CBC ciphersuites still a requirement in your ecosystem or has a move towards AEAD happened?

[DemiMarie]

I think the best option would be to get the relevant standards changed or to require encrypt-then-MAC.

[gilles-peskine-arm]

@DemiMarie The relevant standards have changed: TLS 1.3 only has cipher suites with proper AEAD. I doubt that TLS 1.2 is going to be updated to forbid CBC-MAC-then-encrypt.

In Mbed TLS (and OpenSSL and many other current TLS implementations), CBC-based cipher suites are secure against timing attacks, but decryption is slow.

[DemiMarie]

@gilles-peskine-arm: “relevant standards” refers to @TrinityTonic’s ecosystem. I would not be surprised if standard practice in this ecosystem is to offload the entire CBC+HMAC processing (including verifying the authentication tag!) to a constant-time hardware accelerator, in which case the poor performance of software implementations is completely irrelevant once this feature is implemented. I would also not be surprised if the need to support such accelerators is the reason that these ciphersuites are required. Treating CBC+HMAC-then-encrypt and CBC-encrypt-then-HMAC as AEADs would allow Mbed TLS to use AEADs for all TLS bulk encryption, eliminating the need to special-case CBC mode.

[gilles-peskine-arm]

@TrinityTonic We are planning a new major version of Mbed TLS in 2025, so the removal of CBC cipher suites is one again on the table. Has anything changed in the RTE ecosystem? Are CBC cipher suites still relevant? With or without encrypt-then-MAC (EtM)?

Discussion in #9202