Cryptographic Network Stack

• Cryptographic network stacks are architectures that embed cryptographic processing within network layers to provide end-to-end confidentiality, authentication, and metadata protection.
• They integrate security headers and compositional cryptographic operations, combining point-to-point and application-level security for improved network resilience.
• Implementations range from NIC-rooted trust for attack-surface reduction to quantum and post-quantum layering schemes, offering practical, high-performance security solutions.

A cryptographic network stack is a network stack in which cryptographic processing or security guarantees are integrated into the transport or below, or are treated as an explicit architectural layer rather than a purely application-level library bolted on top of sockets. In the literature, the term covers several related constructions: pushing authentication, access control, and service cloaking into programmable NICs before the OS and applications see any traffic; inserting an explicit security layer and an extension layer into the operational Internet stack; and treating the full chain of per-layer message transformations as a single object whose confidentiality, authentication, and metadata protection compose across layers (0804.3796, Paillisse et al., 2022, Kundu et al., 9 Apr 2026).

1. Architectural models of the stack

A recurrent theme is that the classic TCP/IP picture no longer faithfully describes operational networks. One formalization observes that “about 70% of traffic on the Internet is encrypted,” mostly at L3 or L4, and that protocol ossification at L3/L4 has pushed new functionality into upper layers. To capture this, the stack is extended with two recurring headers: a security header for confidentiality, integrity, and authentication, and an extension header for functionality such as identity, QoE, policy, mobility, labels, and tokens (Paillisse et al., 2022).

In an L3-centric formulation, the encapsulation can be written as

$$H_{\text{L2}} \,\|\, H_{\text{IP}} \,\|\, H_{\text{sec}} \,\|\, H_{\text{ext}} \,\|\, H_{\text{L4}} \,\|\, H_{\text{HTTP}} \,\|\, \text{data},$$

where $H_{\text{sec}}$ corresponds to mechanisms such as IPsec or WireGuard and $H_{\text{ext}}$ corresponds to overlay or policy metadata such as VXLAN, MPLS, VPN identifiers, or APN labels. In an L7-centric formulation, the encapsulation becomes

$$H_{\text{L2}} \,\|\, H_{\text{IP}} \,\|\, H_{\text{L4}} \,\|\, H_{\text{TLS}} \,\|\, H_{\text{HTTP-ext}} \,\|\, \text{app data}.$$

The two formulations are not mutually exclusive in practice, and real systems often combine them in the same end-to-end path (Paillisse et al., 2022).

This layer insertion changes the semantics of the stack. L3 security is typically point-to-point between network elements and is often operated by the network or security infrastructure; L4+/L7 security is typically end-to-end between applications or between a user and a service. The literature explicitly notes that these two security headers are “not generally speaking interchangeable,” even though systems such as Zero Trust Networking blur the distinction through concatenated TLS tunnels with HTTPS proxies in between (Paillisse et al., 2022).

2. Cross-layer composition and security semantics

A more formal treatment models communication as a sequence of message transformations from application to link layer:

$$M_{\mathrm{out}} = L_2\big(L_3(\cdots L_7(M_{\mathrm{app}})\cdots)\big).$$

Each active layer is decomposed into cryptographic operations such as KEX, AUTH, ENC, INT, and KDF, and each operation is classified into one of four post-quantum status categories:

$$C\text{-Unsafe} < Q\text{-Unsafe} < Q\text{-Weakened} < Q\text{-Safe}.$$

This yields a lattice-theoretic description of the stack, with confidentiality composing differently from authentication (Kundu et al., 9 Apr 2026).

At layer $L_i$, the effective confidentiality status is

$$\mathcal{C}_{L_i} = \min\big(\sigma(\mathrm{KEX}_i), \sigma(\mathrm{ENC}_i)\big),$$

and the effective authentication status is

$\mathcal{A}_{L_i} = \sigma(\mathrm{AUTH}_i).$

Across the full transformation chain, confidentiality composes as a join,

$$\mathcal{C}_{\mathrm{chain}} = \bigvee_i \mathcal{C}_{L_i} = \max_i \mathcal{C}_{L_i},$$

authentication composes as a meet,

$H_{\text{sec}}$0

and metadata protection depends solely on the outermost active layer,

$H_{\text{sec}}$1

The immediate consequence is the result emphasized in the abstract: a single post-quantum layer suffices for payload confidentiality, but every layer must migrate for complete authentication, and metadata protection depends solely on the outermost layer (Kundu et al., 9 Apr 2026).

This compositional view also produces non-intuitive outcomes. One finding is that WPA2-Personal provides strictly better PQC posture than both WPA3-Personal and WPA2-Enterprise, because the addition of elliptic-curve mechanisms improves classical security while simultaneously introducing Shor-vulnerable attack surfaces (Kundu et al., 9 Apr 2026). The result is not a claim that one protocol dominates the others in all threat models; rather, it shows that a cryptographic network stack must be analyzed as a composition of transformations rather than by inspecting a single layer in isolation.

3. Link-layer enforcement and NIC-rooted trust

One concrete realization of a cryptographic network stack is to push the trust boundary down to the data link layer. In “service cloaking,” a programmable NIC enforces a default policy of dropping everything at Layer 2, and a host’s services become invisible to unauthenticated peers. The NIC maintains a Filter Table keyed by

$H_{\text{sec}}$2

handles ARP in hardware, and only after a successful knock authentication carried inside an ICMP packet and encrypted using a shared key does it allow matching traffic to reach the host stack. Failed or invalid knocks elicit no response, so unauthorized hosts see no open ports, no SYN-ACK, and no application-layer banners. The design is explicitly described as complementary to IPsec, TLS/SSL, and traditional firewalls (0804.3796).

The same work ties this to attack-surface reduction. Because unauthenticated frames are dropped at the NIC, the OS network stack, firewall, and applications are not exposed to that input path, and ARP poisoning attempts are ineffective because ARP replies do not reach the OS stack in the first place. The authors further claim that “services will be immune to zero-day vulnerabilities due to the minimal code execution paths,” meaning, more precisely, that exposure to zero-day vulnerabilities is greatly reduced for unauthenticated traffic because the entry point is a small NIC firmware rather than a large OS kernel and application stack (0804.3796).

A more recent NIC-centered architecture replaces general-purpose host trust with a formally verified silicon root of trust. TNIC builds a minimal, formally verified SmartNIC stack for Byzantine cloud environments around two properties: transferable authentication and non-equivocation. Its attestation kernel computes

$H_{\text{sec}}$3

using HMAC-SHA-384, appends device identity and a per-connection monotonic counter, and verifies both token and exact-next counter on reception. The result is a network-visible behavior in which any accepted message was previously sent by some genuine TNIC endpoint and messages cannot be accepted twice or out of order. The architecture is explicitly host CPU-agnostic, uses a silicon root of trust at the network interface level, and reports up to $H_{\text{sec}}$4 performance improvement compared to CPU-centric TEE systems (Giantsidi et al., 7 Feb 2025).

4. Domain-specific cryptographic sublayers

Not all cryptographic network stacks are organized around IP and NICs alone. In network coding, one proposal treats confidentiality as a sublayer of the coding layer itself. Secure Practical Network Coding (SPOC) splits packet coefficients into unlocked coefficients $H_{\text{sec}}$5, sent in the clear, and locked coefficients $H_{\text{sec}}$6, encrypted as

$H_{\text{sec}}$7

Each packet header becomes

$H_{\text{sec}}$8

while the payload remains a linear combination $H_{\text{sec}}$9. Intermediate nodes perform ordinary RLNC over $H_{\text{ext}}$0 without decrypting anything, so confidentiality is obtained by encrypting only the decoding coefficients rather than the entire payload. A later hybrid universal network-coding cryptosystem (HUNCC) generalizes this logic: it combines an $H_{\text{ext}}$1 individually secure linear code with public-key cryptography on only $H_{\text{ext}}$2 links, and states that, to guarantee a computational security level $H_{\text{ext}}$3, it is sufficient to encrypt a single link using a computational post-quantum scheme; the information rate approaches $H_{\text{ext}}$4 as the number of communication links increases (0807.0610, Cohen et al., 2020).

In networked control systems, the stack is reorganized around encrypted control loops rather than around packets alone. One design uses an inner Paillier layer for additive homomorphic computation and an outer RSA layer for component isolation. The composite operators are

$H_{\text{ext}}$5

with inverse decoding

$H_{\text{ext}}$6

Controllers operate in an encrypted state space, and the design is justified by a separation principle: cryptographic techniques address confidentiality requirements while control algorithms satisfy performance requirements. In the linear MIMO case, stability is expressed by

$H_{\text{ext}}$7

showing exponential convergence to an $H_{\text{ext}}$8 neighborhood determined by quantization resolution (Yan et al., 2020).

For constrained IoT nodes, the stack can be specialized further at the MAC layer. A lightweight 6LoWPAN stack replaces AES in IEEE 802.15.4 MAC security with the LiCi-2 block cipher. LiCi-2 is a 25-round classical Feistel cipher with 64-bit block size and 128-bit key length, and the reported implementation uses 1856 bytes of FLASH, 1272 bytes of RAM, around 25 mW of power, and 1051 GEs. The motivation is the 6LoWPAN environment itself: IEEE 802.15.4 frames are only 127 bytes, MAC security overhead can be as high as 21 bytes, and devices are described as having few kilobytes of RAM and flash memory, low power in the order of mW, and limited processing capability (Khairnar et al., 9 Oct 2025).

5. Quantum and post-quantum layering

Quantum and post-quantum networking has produced one of the clearest explicitly layered cryptographic network stacks. A PQC-enhanced QKD network is organized as: physical/quantum links, ETSI GS QKD 014 key access, hop-wise WireGuard tunnels with periodically rotated pre-shared keys sourced from QKD, Rosenpass performing a PQC key exchange, a second end-to-end WireGuard tunnel secured with the Rosenpass-derived key, and finally ordinary IP applications running unchanged over the resulting secure path. The design uses Classic McEliece and CRYSTALS-Kyber inside Rosenpass, rotates keys every 120 s with a 60 s grace window, and is intentionally fail-safe: if QKD keys or PQC rekeying fail, random keys are injected and tunnels are forced down rather than silently extended. Measured setup times are 10.27 s for 10 trusted nodes and 10.62 s for 100 trusted nodes, 9.93 s for a dual-path dual-Rosenpass deployment, and mean time to data tunnel disruption is 548.42 s after QKD failure (Spooren et al., 7 Apr 2026).

A different quantum-network line of work argues that standard repeater protocols are cryptographically fragile in adversarial environments. For the BBPSSW distillation protocol, an adversarial input

$H_{\text{ext}}$9

induces a recurrence

$$H_{\text{L2}} \,\|\, H_{\text{IP}} \,\|\, H_{\text{L4}} \,\|\, H_{\text{TLS}} \,\|\, H_{\text{HTTP-ext}} \,\|\, \text{app data}.$$0

with $$H_{\text{L2}} \,\|\, H_{\text{IP}} \,\|\, H_{\text{L4}} \,\|\, H_{\text{TLS}} \,\|\, H_{\text{HTTP-ext}} \,\|\, \text{app data}.$$1 for all $$H_{\text{L2}} \,\|\, H_{\text{IP}} \,\|\, H_{\text{L4}} \,\|\, H_{\text{TLS}} \,\|\, H_{\text{HTTP-ext}} \,\|\, \text{app data}.$$2, yet fidelity to a maximally entangled state converges to $$H_{\text{L2}} \,\|\, H_{\text{IP}} \,\|\, H_{\text{L4}} \,\|\, H_{\text{TLS}} \,\|\, H_{\text{HTTP-ext}} \,\|\, \text{app data}.$$3. The claim is that BBPSSW recursively purifies error syndromes rather than entanglement. Because MLE-based verification is also shown to be computationally blind to approximate $$H_{\text{L2}} \,\|\, H_{\text{IP}} \,\|\, H_{\text{L4}} \,\|\, H_{\text{TLS}} \,\|\, H_{\text{HTTP-ext}} \,\|\, \text{app data}.$$4-design adversarial ensembles, the proposed remedy is a Cryptographic Network Stack centered on a trapdoor verification protocol. The verifier uses a secret PRF seed to choose CHSH measurement bases, and for separable inputs the success probability is bounded by

$$H_{\text{L2}} \,\|\, H_{\text{IP}} \,\|\, H_{\text{L4}} \,\|\, H_{\text{TLS}} \,\|\, H_{\text{HTTP-ext}} \,\|\, \text{app data}.$$5

A complementary blind Schur-sampling layer rejects pseudoentangled states with acceptance probability at most $$H_{\text{L2}} \,\|\, H_{\text{IP}} \,\|\, H_{\text{L4}} \,\|\, H_{\text{TLS}} \,\|\, H_{\text{HTTP-ext}} \,\|\, \text{app data}.$$6 (Sadhu et al., 26 Feb 2026).

6. Infrastructure, implementation, and open problems

The stack can also be rearchitected as virtualized infrastructure. NetKernel decouples the network stack from the guest VM and offers it as an independent module, the Network Stack Module (NSM), while preserving the BSD socket API. It does not implement cryptography itself, but it provides a substrate in which TLS-integrated transports, QUIC, or IPsec-like functions could live in operator-managed stack modules rather than in every guest. The paper explicitly notes that “Security impact is minimal because most of the security protocols such as HTTPS/TLS work at the application layer,” while “One exception is IPSec. Due to the certificate exchange issue, IPSec does not work directly in our design.” Testbed evaluation using 100G NICs reports that NetKernel preserves the performance and scalability of both kernel and userspace network stacks and provides the same isolation as the current architecture (Niu et al., 2019).

At the software implementation level, cryptographic network stacks depend on low-level routines whose own execution must remain secure. SecSep addresses speculative-execution leakage by rewriting assembly programs so that secret and public data are partitioned on the stack. The transformation is driven by Octal, a typed assembly language that tracks secret information at byte granularity and rejects tainted load/store addresses and tainted branch conditions. Applied to cryptographic programs such as ChaCha20, Poly1305, SHA-512, X25519, and Ed25519, the reported result is secure speculation with a low average overhead of $$H_{\text{L2}} \,\|\, H_{\text{IP}} \,\|\, H_{\text{L4}} \,\|\, H_{\text{TLS}} \,\|\, H_{\text{HTTP-ext}} \,\|\, \text{app data}.$$7 (Song et al., 10 Sep 2025).

Several unresolved issues recur across the literature. L2 key management is often left unspecified or described as an open issue; one NIC-level design explicitly states that encryption and key management remain open problems, while the Internet-architecture view stresses that L3 and L7 security headers are not generally interchangeable and that observability, management, and ossification reappear at higher layers (0804.3796, Paillisse et al., 2022). Trusted-node QKD architectures remain dependent on physical security and operational discipline, and trusted-NIC architectures intentionally omit confidentiality in favor of integrity, authentication, and non-equivocation (Spooren et al., 7 Apr 2026, Giantsidi et al., 7 Feb 2025). This suggests that a cryptographic network stack is best understood not as a single protocol but as a family of architectures in which layer placement, compositional reasoning, roots of trust, and key-management assumptions determine what security property is actually being provided.