netdev - [RFC] STCP: secure-by-default transport (kernel-level, experimental)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <aceecca9-61ae-454f-957f-875c740c0686@lja.fi>
Date: Mon, 22 Dec 2025 20:13:40 +0200
From: Lauri Jakku <lja@....fi>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: rust-for-linux@...r.kernel.org, netdev@...r.kernel.org
Subject: [RFC] STCP: secure-by-default transport (kernel-level, experimental)

STCP is an experimental, TCP-like transport protocol that integrates 
encryption and authentication directly into the transport layer, instead 
of layering TLS on top of TCP.

The motivation is not to replace TCP, TLS, or QUIC for general Internet 
traffic, but to explore whether *security-by-default at the transport 
layer* can simplify certain classes of systems—particularly embedded, 
industrial, and controlled environments—where TLS configuration, 
certificate management, and user-space complexity are a significant 
operational burden.

Key properties:

  * Connection-oriented, TCP-like semantics

  * Explicit cryptographic handshake during connection setup

  * Encrypted payloads handled at the protocol level

  * No plaintext fallback after handshake

  * Minimal configuration surface

  * Kernel-level implementation (Linux), primarily in Rust

STCP currently uses:

  * ECDH-based key exchange

  * AEAD symmetric encryption (e.g., AES-GCM)

  * Explicit, length-prefixed record framing (64-bit BE length + IV +
    ciphertext)

The project is implemented as a *real, running kernel module*, not a 
paper design. It is *experimental*, not production-ready, and not 
proposed as an Internet standard or upstream replacement.

STCP does *not* aim to:

  * Replace TCP globally

  * Compete with TLS or QUIC for web traffic

  * Provide backward compatibility with existing TCP stacks

Intended discussion points for netdev feedback:

  * Does this class of “secure-by-default transport” have valid
    kernel-level use cases?

  * Are the design trade-offs reasonable compared to TCP+TLS or QUIC?

  * Are there obvious architectural, security, or integration pitfalls?

  * Does this kind of experimentation belong in-kernel, and if so, how
    should it be structured? I got very interested parties (Big IoT
    companies and such) that wait for the module to mature.

Full design RFC (including wire format) is available here:

https://github.com/MiesSuomesta/STCP/blob/main/kernel/OOT/linux/RFC.md *
*
Feedback—critical or otherwise—is very welcome.

--Lauri Jakku
.---<[ Paxsudos IT / Security Screening ]>---------------------------------------------------------------->
| Known viruses: 3626996
| Engine version: 1.4.3
| Scanned directories: 0
| Scanned files: 1
| Infected files: 0
| Data scanned: 0.00 MB
| Data read: 0.00 MB (ratio 0.00:1)
| Time: 12.668 sec (0 m 12 s)
| Start Date: 2025:12:22 20:13:45
| End Date:   2025:12:22 20:13:57
| SPAM hints: []
| SPAM hints: []
| Message not from DMARC.
`-------------------------------------------------------------------->