Summary

  • RFC 9180’s Base mode establishes encryption for the holder of a recipient KEM private key. A successful Open() is evidence that the ciphertext validated in that context; it is not evidence that the remote party had a named identity or mandate.
  • PSK, Auth and AuthPSK modes add bounded evidence of possession of configured secret material. They do not automatically provide a complete message envelope, replay window, identity registry, key-revocation decision, authorization rule or safe-action policy.
  • Leaders should preserve an evidence chain from recipient-key selection through mode, suite, context and decryption to application framing, authorization and observed effect. Each handoff has a different owner and a different failure mode.

The encrypted note arrives at a service that owns a private key. Its cryptographic library accepts the encapsulated value, derives a context and opens the ciphertext. The payload looks well formed. A dashboard now records a green event: message protected; message received.

That event can be true and still be dangerously incomplete. In HPKE Base mode, the sender needed only the recipient’s public key. The message may be confidential to the private-key holder, but the construction does not identify the sender. It does not say which system supplied that public key, whether the recipient key was current for the claimed purpose, what external envelope carried the ciphertext, whether a previous message was replayed, or whether the resulting plaintext may authorize a consequential operation.

The missing distinction is easy to conceal because all the objects have a cryptographic appearance. There is a public key, an encapsulation, a ciphersuite identifier, a derived secret, additional authenticated data and an authentication tag. A successful operation feels like a completed protocol. RFC 9180 is more disciplined. It defines Hybrid Public Key Encryption as a way to combine a key encapsulation mechanism, a key-derivation function and authenticated encryption. It is not a universal identity system, message transport, approval workflow or consequence engine.

That restraint is the point. A good common layer solves the one problem it can make interoperable and deterministic. It should not smuggle local policy into a primitive where neither the data model nor the evidence can sustain it. The operational failure begins when an organization promotes a successful cryptographic transition into claims the transition did not make.

What Base mode actually establishes

HPKE has two broad stages. The sender constructs a shared encryption context; the sender then seals one or more plaintexts under that context. The recipient reconstructs the context with its private key and the received encapsulated value, then opens the ciphertext. A ciphersuite names one KEM, one KDF and one AEAD. Each component supplies a bounded function: encapsulation/decapsulation, key derivation, or authenticated encryption of a plaintext with associated data.

In Base mode, the basic setup takes a recipient public key pkR and application-supplied info. The sender encapsulates to pkR; the recipient decapsulates with the matching skR. The shared secret is then processed through the key schedule, and the AEAD context handles the content.

The resulting property is important: material encrypted under the selected construction can be opened by the holder of that recipient private key, subject to the normal primitive assumptions. But that sentence does not contain a sender identity. RFC 9180’s own mode table treats Base mode as providing message and export secrecy without a sender-authentication property.

The difference is not philosophical. Imagine an internal endpoint whose public key is visible to several approved services and to any party able to observe the key directory. Any holder of that public key can form a Base-mode ciphertext for the recipient. If the recipient opens it, the cryptographic event tells the recipient that its context accepted the bytes. It does not distinguish an approved workload from an unapproved one merely because both could obtain the same public key.

An application may place an account number, tenant name, request identifier or organization label inside the plaintext. That can be useful application data. It is not self-authenticating in Base mode. The recipient must still establish who was entitled to place that claim in the message, which external transport delivered it, which authorization record governed it and whether the claim was current.

The same discipline applies to additional authenticated data. AEAD lets an application bind selected data so that the ciphertext will not validate if that data differs. It does not choose the data, define its semantics or make the data true. A well-bound but incorrectly supplied account field is still an incorrectly supplied account field. Cryptography can protect the integrity of the chosen statement; it cannot decide whether the statement came from an authorized speaker.

Authentication has modes—and a boundary

RFC 9180 does not ignore authentication. It provides three modes beyond Base. PSK mode gives the recipient evidence that the sender possessed the configured pre-shared key. Auth mode gives the recipient bounded evidence that the sender possessed the KEM private key corresponding to a configured sender public key. AuthPSK combines both kinds of material.

Those are valuable upgrades when a system has correctly provisioned, selected and protected the relevant secrets. They should nevertheless be read precisely.

First, they authenticate possession of material, not every identity that an enterprise may attach to that material. A key can be assigned to a service, a person, a hardware module, a workflow or a shared role. The mapping is an application and governance fact. It requires issuance records, lifecycle ownership, rotation and revocation decisions that HPKE does not carry inside its generic construction.

Second, Auth mode authenticates the sender key pair, not an arbitrary identity label. RFC 9180 explicitly directs an application that needs to bind a sender address, domain name or other identifier to include it in info. That is an excellent design signal. It recognizes that cryptographic key possession and the identity an application wants to rely on are separate claims that need a deliberate binding.

Third, the assurance has a stated qualification. The DHKEM Auth/AuthPSK variants documented in RFC 9180 have a key-compromise-impersonation limitation under the RFC’s recipient-key compromise conditions. An Auth result is therefore neither a timeless proof of human authorship nor a universal non-repudiation record. It is a mode-specific cryptographic assurance whose value depends on key custody, the time of compromise and the surrounding protocol.

This is where labels become hazardous. A log field called authenticated_sender=true might accurately describe a successful Auth-mode check. If it is then read as “the organization approved the transaction,” three unproved steps have been inserted: which organization controls the key, whether that key had authority for this message, and whether the message met an application policy. A truthful low-level label became a false high-level conclusion.

Context is not a message envelope

HPKE gives applications several places to supply auxiliary authenticated information. info applies during context setup. Associated data applies during Seal() and Open() operations. Exporter context applies to the secret-export interface. The division is useful: recurring context belongs at setup; per-message context belongs with the message operation.

But HPKE does not define the external encoding of an HPKE message. RFC 9180 says applications must specify an unambiguous format containing, at minimum, the encapsulated value, ciphertext or ciphertexts, their order where applicable, and any non-implicit info values. A recipient that holds multiple public keys may also need the selected recipient public key made explicit.

That requirement is not clerical. Framing decides which bytes are one message, where an encapsulation ends, which suite and mode are in force, whether the context data is reconstructed correctly and which recipient key is supposed to receive the message. If a different application layer supplies those facts ambiguously, a correct HPKE implementation cannot repair the ambiguity by decrypting successfully.

The same is true of message meaning. A plaintext can be an enrollment request, a routing instruction, a release authorization or a harmless status update. HPKE does not classify it. A recipient needs a schema, expected fields, type restrictions, version rules, an authorization subject, a policy decision and an execution boundary. Each of those must reject malformed or unauthorized inputs before a decrypted byte becomes a command.

This is a practical reason to keep the security record stratified. Do not store only “HPKE valid.” Retain the selected KEM/KDF/AEAD identifiers, mode, recipient-key identifier, sender key or PSK identifier where applicable, a safe reference to info, a digest of the associated-data context, the external message identifier, parser result, authorization decision and resulting effect. The record should permit an investigator to ask which earlier fact authorized the later one.

Time, replay and key lifetime remain local decisions

Encryption does not create freshness. RFC 9180 offers limited replay protection only when ciphertexts from one context are presented to the recipient in the same sequence in which the sender sealed them. Outside that stream, it provides no replay protection. Multi-message applications must enforce order; RFC 9180 points them toward framing and sequence information, with the relevant ordering material bound as associated data.

The consequences reach beyond networking. A decrypted instruction might be cryptographically intact and semantically well formed but stale. A reset request from yesterday may not be valid today. A policy acceptance tied to a previous account state may no longer be authorized. An application must decide what time, nonce, sequence, replay cache or idempotency rule proves freshness for its own risk. HPKE cannot choose that window.

Algorithm selection is similarly external. The RFC assumes sender and recipient agree which algorithms to use. Depending on how a system negotiates them, an intermediary may be able to force weaker choices. The HPKE ciphersuite identifiers tell the implementation which primitive triple was selected; they do not prove that selection was protected by a wider negotiation policy.

Recipient-key compromise creates another time boundary. RFC 9180 states that HPKE ciphertexts are not forward secret with respect to recipient compromise: because the recipient uses long-term secret material, compromise can permit decryption of past ciphertexts encrypted for that key. This is not evidence that any endpoint has been compromised. It is a design property that should shape key rotation, retention, incident review and the decision about what ciphertext archives make retrospectively readable.

There is also a difference between confidentiality and reversibility. Deleting a compromised recipient key may prevent future normal decryptions, but it cannot change plaintext already read, prevent a copied ciphertext from being analyzed by someone who retained the key, or undo an action an application already took after decryption. Key lifecycle, data retention, authorization rollback and operational recovery require separate controls.

The evidence chain that turns a primitive into a service

A responsible operator can map the full path without inflating any link.

At key selection, preserve the recipient key identifier, issuance and revocation state, approved purpose, distribution channel and owner. The public key is an encryption target; its presence in a directory is not proof that every sender may use it for every class of message.

At sender preparation, record the selected mode and suite, the source of any sender key or PSK, the construction of info, the associated data, the outer framing and any negotiation evidence. A PSK or sender key may be valid cryptographic material while still being wrong for the requested role or tenant.

At receiving and opening, record the received encapsulation and ciphertext by safe digest or durable identifier, the recipient key, mode, suite, context result and decryption outcome. Treat a failure as a bounded cryptographic failure; treat success as a bounded cryptographic success. Neither verdict should overwrite the application’s parser, policy or execution logs.

At application interpretation, preserve schema version, message type, authorization subject, freshness check, replay decision, policy result and the reason for refusal or acceptance. A ciphertext can be valid but rejected because its sender key is retired, its tenant is wrong, its sequence is stale, its operation is disallowed or its payload violates a semantic rule. That is not a failure of HPKE. It is the application correctly owning the decision HPKE declined to make.

At effect, record the action requested, the action authorized, the action completed, the external system that observed it and any rollback. These are different events. An approved request may fail to execute. An executed change may have effects that require separate verification. A decrypt event alone belongs nowhere near the end of that chain.

The resulting model is more useful in an incident. It lets a team say: a ciphertext was presented for key K under suite S; the context opened; its framing parsed as request R; the sender-key binding was or was not recognized; the replay gate accepted or rejected it; policy P allowed or refused action A; system X observed outcome O. Each statement has an owner, a log source and a limitation.