Verification At Scale: Secure Protocol Composition, Dynamic Corruption, and TLS 1.3 ECH

Thu, 02 Jul 2026 09:00:00 +0000

In most branches of formal methods, life is beautiful: You model a system to prove its properties, then you model another system and prove its properties. Afterwards, you combine both systems to create a third one, and you know that this combined system still has all the properties of the two original systems.

When we analyse security protocols, we don’t have this luxury: Even if two protocols are perfectly secure, simply running them one after the other might break all their security guarantees. The problem here is the adversary: They can read, block and manipulate all messages sent over the network, and even fabricate entirely new messages from their knowledge. If two protocols are now used to assemble a new protocol – we say that the protocols are composed – the adversary can use the messages sent from both original protocols to break their respective guarantees.

The adversary is also the reason why classical composition results are not applicable to security protocols: Technically, we are not only composing two protocols, but parts of two systems with a third. The two systems under composition each consist of the actual protocol and the adversary, both under infinite replication, executed in parallel. The composed system however consists of the two protocols and the adversary, all three of which are not only executed in parallel, but also under infinite replication. This contrived setup is not covered by classical composition results.

Overall, this makes it very cumbersome to formally analyse large security protocols. Without composition results, we always have to verify the protocol monolithically. While there are powerful verifiers like Tamarin [TAM] or ProVerif [PV] which can handle highly complex protocols, there are real-world protocols that make them reach their limits (see, e.g., [SPDM]). We need new approaches to the formal verification of security protocols, and using composition results is one of them.

Of course, this is not a particularly new insight, and the community has been looking into secure protocol composition since the 1990s. There are in fact quite a few composition theorems which state conditions under which it is safe to compose security protocols. However, they are very rarely used in protocol verification. A common argument is that their requirements are unrealistic and hard to meet in practice. Many results require the two protocols to be composed to use disjoint primitives, i.e., if one of the protocols uses a cryptographic primitive, the same primitive cannot be used by the other protocol. Additionally, these results are not able to reason about all relevant security properties. Notably, Forward Secrecy (FS) and Post-Compromise Security [PCS] are not covered by existing composition theorems.

We tackle both problems in our paper Secure Protocol Composition under Dynamic Corruption: Scaling Up Symbolic Analysis for Real-World Security Protocols [SPC], which will appear at USENIX Security next month. In it, we do two things:

We use the Applied Pi-Calculus to describe and prove a composition theorem in the symbolic model of cryptography; the theorem is applicable even if we consider an adversary capable of dynamic corruption, which is necessary to specify FS and PCS.
We demonstrate that even though our theorem requires disjoint primitives, it can be used to compositionally verify a large-scale, real-world security protocol by proving FS of TLS 1.3 with the ECH extension.

In this post, we will have a look at what we have proven and how we have applied it to TLS 1.3 ECH. We will not go into the nitty-gritty technical details here; rather, the goal is to give an overview of our work and some first orientation for anyone who wants to take a closer look at our paper. This means that we will use as little formal notation as possible; we will even abstain from using Applied Pi or any other process calculus! If this disappoints you, then just have a look at our paper – there is plenty of both in there.

The Composition Theorem

We just promised to use as little formal notation as possible, so let’s briefly define a few things and then be (almost) done with it. We consider two protocols P and Q, where P uses some output of Q; to make this explicit, we write P[] if we consider protocol P on its own and P[Q] for the composition of P with Q. Slightly oversimplified: P uses the output of Q. P could be some data exchange or messaging protocol and Q a key-exchange protocol. If P and Q are simply executed in parallel, we denote this by P ∥ Q; if there is no cryptographic primitive and no data item (e.g., encryption key) that is used by both protocols, then P ∥ Q is called a disjoint composition. Security properties are denoted by α. Finally, a trace is a record of all outputs a protocol makes to and inputs it receives from the public network during its execution.

First of all, we have to make precise what we mean by dynamic corruption. In our paper, we define it as follows.

Consider a protocol P that uses some secret data item d. An adversary is capable of dynamic corruption of d if they can gain knowledge of d at any point in time during the execution of P.

By this definition, dynamic corruption is a capability of the adversary and thus part of a threat model. If we have to assume that an adversary is able to reveal a secret d whenever they like (or need), we assume dynamic corruption. This is not unrealistic: Regularly, users are careless with their passwords, courts order secrets to be handed over to law-enforcement agencies, and cryptographic material is simply stolen as the result of a successful attack on a vulnerable system. In all these cases we want to know what a person or party can do with our secret data, and specifically, what protected information they can learn with it; in other words, what security properties a protocol has. To model these properties, we also have to model dynamic corruption, which we do by slightly manipulating the protocols we are investigating.

Let’s assume a protocol P and some data ω which we assume an adversary might get hold of. Since for our purposes, ω is a set of variables, we call it a set of corruptible variables. In our modification, we add an operation to P for every item in ω which can be executed at any time; this operations simply sends the respective item to the network, and with it, to the adversary. We call this event a leak; the modified protocol is denoted as ς(P, ω) (this is the last new bit of formal notation, we promise).

That’s it already. With this tiny modification we can specify FS and PCS and any other property that might be relevant under dynamic corruption. What these properties look like is not important for us, since our composition theorem does not depend on a specific security property. It simply states that if some property α holds for the individual protocols, then it also holds for their composition even if the adversary is capable of dynamic corruption. We merely assume two protocols P[] and Q, two sets of corruptible variables ω_P and ω_Q, and any security property α. They have to fulfill five requirements:

P[] and Q have to use disjoint primitives. As mentioned already, this means that the two protocols cannot use the same cryptographic primitives. While this seems like a very severe restriction (more on that in the following section where we discuss our case study), it makes life harder for the adversary: The protocols are mutually unintelligible now, so the adversary cannot abuse messages from one of the protocols to confuse the other.
P[] and Q have to abide by some syntactic requirements which enforce that Q is actually able to provide all data it is supposed to send to P, and that all data shared between P[] and Q is either corruptible in both protocols or in neither. Since anything else would imply an inconsistent threat model between the analysis of the two protocols, this is a natural assumption anyways.
This is a more technical one: P[] and Q may not use shared data to exchange channel names; i.e., they may not open any new, possibly secret, communication channels. This avoids unintended behavior of P[Q] that is not present in the two individual protocols alone.
Shared data has to be kept secret in the uncorrupted versions of both P[] and Q. Otherwise, the adversary could use some of the shared data to retrieve information from one of the protocols they could not otherwise (imagine P[] using some key k for encryption, but Q just blurting k out to the network).
This is a very technical one: Data shared between P[] and Q has to consist entirely of fresh variables. The reason for this is also very technical; essentially, we need this in our proof to keep track of shared data and whether it has been leaked to the adversary.

If these all hold, then the following implication holds as well.

If α holds for ς(P[], ω_P), and α holds for ς(Q, ω_Q), then α holds for ς(P[Q], ω_P ∪ ω_Q).

To prove this, we show that every attack on P[Q] already contains an attack on either P[] or Q alone. For this, we first show that we can repeat leaks without any ramifications; notably, we cannot “fix” an attack by giving the same information to an adversary twice. Then, we show that for any trace of P[Q] where leaks are instantly repeated, there is a corresponding trace of the disjoint composition P ∥ Q which shares the same properties. We conclude by using a well-known composition result which states that two disjoint protocols can be securely composed.

This last step actually required us to generalize said result. So far, it was only proven that disjoint composition works if the two protocols use a limited, specific set of cryptographic protocols – we lift this to arbitrary primitives.

Both proofs can be found in full length in [SPC].

A Real-World Case Study

A composition theorem is all nice and well, but what can we actually do with it? Can we use it to perform a compositional analysis of a large-scale, real-world protocol using an automated protocol verifier? If yes, how much do we actually benefit from using a composition theorem? We mentioned earlier that composition theorems are often considered too difficult to apply if they require disjoint primitives, which is exactly what we do. Still, we found a prominent protocol that matches the requirements of our composition theorem: TLS 1.3.

But how can this large, complex protocol match our composition theorem?

First of all, “disjoint primitives” sounds worse than it is. It does not require cryptographic primitives to be completely and conceptually different, just that they are sufficiently different to be modeled as two different function symbols in the symbolic model. In practice this already is the case if two hash functions produce hashes of different length (say, 256bit and 512bit hashes) or two HKDFs use different constant tags. This distinction enables us to apply our composition theorem to TLS 1.3 ECH.

TLS 1.3 ECH can roughly be split into three parts: An initial Key Exchange, an Authentication Phase, and a Data Exchange. For the key exchange, TLS 1.3 ECH uses HPKE, modular exponentiation, and three different KDFs KDF0, KDFhs, and KDFms. During the Authentication Phase and the Data Exchange the protocol uses symmetric encryption, signatures, MACs, and the KDFs KDFk and KDFpsk. So even though KDFs are used across the entire protocol, we can still take out the Key Exchange from the rest of the protocol, keeping the primitives disjoint, and do a compositional analysis!

That is, of course, if we can model it such that the remaining four requirements are also fulfilled, and if there is a protocol verifier that is compatible with our composition theorem. Since we used the Applied Pi-Calculus for our result, we actually have two options: ProVerif and SAPIC+ [SAPIC]. Both use dialects of the Applied Pi-Calculus that are equivalent to the plain Applied Pi-Calculus (proven in [PVe] for ProVerif and [SAPIC] for SAPIC+). Even better, there already is a comprehensive ProVerif model of TLS 1.3, even including the Encrypted Client Hello extension, covering a plethora of different scenarios: [TLS]. We skip over the very technical details here, but this model also fulfills requirements 2 through 5 of our composition theorem!

We therefore based our analysis on this model, enhanced it with a composition mode which analyses the two parts of TLS 1.3 separately, and added a query for FS of TLS 1.3 ECH’s master secret. Then, for all relevant scenarios, we performed a compositional analysis and compared the respective resource consumption. Let’s have a look at the results of a few of the 32 scenarios we analysed; the first four columns encode the respective scenarios.

scenario	monolithic		compositional		improvement
	(hh:mm)	(GB)	(hh:mm)	(GB)	time	memory
2 2 2 2	00:11	02.64	0:06	0.66	45%	75%
2 2 2 4	00:16	03.49	0:07	0.76	56%	78%
2 2 3 2	00:48	08.08	0:06	0.79	88%	90%
2 2 3 4	01:22	12.25	0:08	0.79	90%	94%
7 2 3 2	14:10	32.65	2:50	4.62	80%	86%
7 2 3 4	16:29	43.10	3:32	5.31	79%	88%
9 2 2 2	25:01	49.53	2:51	4.62	89%	91%
9 2 2 4	28:51	65.67	3:30	4.62	88%	93%
9 2 3 2	timeout	132.06	2:54	4.62
9 2 3 4	timeout	151.72	3:41	5.31
10 2 3 2	timeout	132.06	3:02	4.62
10 2 3 4	timeout	151.71	3:39	5.31

Unsurprisingly, ProVerif needs much less time and memory if it only has to consider parts of the model; on average, the compositional analysis was 71% faster and needed 86% less memory than the monolithic analysis. Both improvements are very consistent – there is a substantial speed-up in almost all scenarios, and memory consumption is at least 90% lower in half the scenarios, never dropping below 57%. ProVerif is even able to prove Forward Secrecy in all scenarios considered, while the monolithic analysis times out after 48h in four cases.

We observed four outliers in which the compositional analysis is only a tiny bit faster, exactly as fast, and even slightly slower than the monolithic analysis.

scenario	monolithic		compositional		improvement
	(hh:mm)	(GB)	(hh:mm)	(GB)	time	memory
7 2 2 2	02:55	10.66	2:47	4.62	05%	57%
7 2 2 4	03:22	12.25	3:22	4.62	00%	62%
8 2 2 2	02:51	10.66	2:50	4.62	01%	57%
8 2 2 4	03:22	12.25	3:30	4.62	-4%	62%

These four scenarios cover barely any post-handshake interaction, however, so compositional and monolithic analysis have to take very similar parts of the model into account. Still, memory consumption is down by roughly 60% in all four cases.

Nonetheless, compositional analysis saves a lot of resources, and sometimes even enables a proof in the first place. For the complete data, see [SPC].

What’s next?

Let’s take a step back: Overall, we identified and proved a composition theorem in the symbolic model that holds under dynamic corruption, and we used it to compositionally prove Forward Secrecy in TLS 1.3 ECH. So where do we go from here?

On the one hand, it would be very interesting to see further, possibly more comprehensive case studies of compositional analyses. Taking a closer look at TLS 1.3 ECH would be viable – we focused on a single out of the many properties TLS guarantees – but also other complex protocols like the aforementioned SPDM. Was TLS 1.3 ECH a lucky outlier or does our result, do composition results in general work with other protocols, too? Do they also work when combining complementary protocols like key-exchanges and data transfer? If they do not, does this mean that there is an attack? As far as we know, this has not been surveyed yet.

On the other hand, improving our current composition result will be helpful. As of now, it only covers situations in which one protocol transfers data to the other, but not vice versa. It might also be valuable to try to replace the disjoint primitives requirement with something else – whatever that might be. A protocol composition survey as described above could be very helpful for identifying possible replacements.

Secure protocol composition still has a lot of open problems, and it might very well be possible that we will never enjoy the same luxuries in security protocol verification as in other branches of formal methods. If we get compositional reasoning to work, however, it can pave the path for automated protocol verification at scale.

For further details, read the full paper.

References

[SAPIC] Vincent Cheval, Charlie Jacomme, Steve Kremer, and Robert Künnemann. 2022. “SAPIC+: Protocol Verifiers of the World, Unite!” Proceedings of the USENIX Security Symposium 2022. https://www.usenix.org/conference/usenixsecurity22/presentation/cheval

[SPC] Cas Cremers, Erik Pallas, and Aleksi Peltonen. “Secure Protocol Composition under Dynamic Corruption: Scaling Up Symbolic Analysis of Real-World Security Protocols.” To appear in the proceedings of the USENIX Security Symposium 2026. IACR ePrint 2026/900

[SPDM] Cas Cremers, Alexander Dax, and Aurora Naska. “Breaking and Provably Restoring Authentication: A Formal Analysis of SPDM 1.2 Including Cross-Protocol Attacks.” Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security. 2025. DOI: 10.1145/3719027.3744865

[TAM] tamarin-prover.com

[TLS] Karthikeyan Bhargavan, Vincent Cheval, and Christopher Wood. 2022. “A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello.” Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security. 2022. DOI: 10.1145/3548606.3559360

[PCS] Katriel Cohn-Gordon, Cas Cremers, and Luke Garratt. 2016. “Post-Compromise Security.” IACR ePrint 2016/221

[PV] https://bblanche.gitlabpages.inria.fr/proverif/

[PVe] Bruno Blanchet. 2016. “Modeling and Verifying Security Protocols with the Applied Pi Calculus and ProVerif.” Foundations and Trends® in Privacy and Security 1, 1–2 (2016), 1–135. DOI: 10.1561/3300000004

Tamarin Prover team wins the Levchin Prize for Real World Cryptography

Mon, 09 Mar 2026 09:00:00 +0000

We are proud to share that the Tamarin Prover team won the International Association for Cryptologic Research (IACR) Real World Cryptography 2026 Levchin Prize for “developing the Tamarin prover, and its use in the analysis of real world security protocols”.

The award ceremony took place at the IACR Real World Crypto (RWC) conference in Taipei, Taiwan. Watch the award ceremony and the keynote on Tamarin given by Cas Cremers.

We are extremely grateful to all of our developers, contributors, and users, who have made Tamarin a success throughout the years. We look forward to many exciting new features and use cases in the future.

Thank you all!