Abstract

OpenSSL 3 replaced the ENGINE extension mechanism with providers: loadable modules that supply algorithm implementations through dispatch tables and that are selected at run time by name and property query. The stated motivation for that redesign was cryptographic agility — the ability to introduce an algorithm without modifying the library that uses it. Transport Layer Security is the most demanding test of that claim, because a TLS connection does not consume a single algorithm. It consumes a coordinated set: an authenticated encryption algorithm for record protection, a hash function that drives the key schedule and the transcript, a key-exchange group, and a signature algorithm for authentication.

This paper studies how that coordinated set can be supplied from a provider, and what a system must do to make a new cipher suite usable in an actual TLS 1.3 handshake. It examines the four distinct extension paths that TLS exposes to a provider — algorithm implementation, the TLS-GROUP capability, the TLS-SIGALG capability, and cipher suite registration — and shows that they are not equivalent in mechanism, in configuration, or in the degree to which they are reachable from provider code alone.

The contribution is a design: a provider architecture that supplies a block cipher operating in an AEAD mode, an elliptic-curve group for key agreement, and a hash function for the key schedule, together with the configuration, property-query policy and negotiation behaviour needed to select them during a handshake. The design is specified in enough detail to be implemented — dispatch tables, parameter exchange, context lifecycle, and the ordering constraints the handshake imposes — and is accompanied by a security analysis, a proposed validation strategy, and an interoperability discussion.

The paper deliberately separates three kinds of statement. Descriptions of the OpenSSL provider and TLS machinery are verified against the openssl-3.5.5 and openssl-3.5.8 source trees, with file and line references. Design proposals are identified as proposals. Reports of the author's implemented capability are attributed as such. No measurements are reported, because none were taken: Chapter 18 gives a performance evaluation methodology rather than results, and Chapter 19 gives a test plan rather than a test log. This follows the practice of the companion paper, which likewise separated proposed methodology from executed experiment.

Keywords: OpenSSL, provider architecture, TLS 1.3, cipher suite, authenticated encryption, elliptic-curve cryptography, key schedule, cryptographic agility, property query, dispatch table.