[RFC] Secure TCP (STCP): Rust-based encrypted transport protocol for kernel integration

[RFC] Secure TCP (STCP): Rust-based encrypted transport protocol for kernel integration

[Lauri Jakku, CEO Of Paxsudos IT]

Hello all,

I have been developing a new Secure TCP (STCP) implementation written 
primarily in Rust, designed for kernel-space integration. It provides an 
authenticated and encrypted transport layer that can operate alongside 
or replace traditional TCP, and is implemented as a loadable kernel 
module with Rust userspace hooks.

The project includes:
   - Kernel-side Rust module (out-of-tree)
   - Fully static userspace Rust library
   - Secure handshake and AES-GCM transport
   - C ABI bridge for compatibility

Repository: https://github.com/MiesSuomesta/STCP/tree/main/kernel-module

I would appreciate feedback from the Rust-for-Linux and netdev 
communities on integration strategy and long-term direction.

Regards,
Lauri Jakku / Paxsudos IT

.---<[ Paxsudos IT / Security Screening ]>---------------------------------------------------------------->
| Known viruses: 8708706
| 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: 19.142 sec (0 m 19 s)
| Start Date: 2025:11:10 19:24:17
| End Date:   2025:11:10 19:24:36
| SPAM hints: []
| SPAM hints: []
| Message not from DMARC.
`-------------------------------------------------------------------->

Re: [RFC] Secure TCP (STCP): Rust-based encrypted transport protocol for kernel integration

[Greg KH]

On Mon, Nov 10, 2025 at 05:24:12PM +0200, Lauri Jakku, CEO Of Paxsudos IT wrote:
> Hello all,
> 
> I have been developing a new Secure TCP (STCP) implementation written
> primarily in Rust, designed for kernel-space integration. It provides an
> authenticated and encrypted transport layer that can operate alongside or
> replace traditional TCP, and is implemented as a loadable kernel module with
> Rust userspace hooks.
> 
> The project includes:
>   - Kernel-side Rust module (out-of-tree)
>   - Fully static userspace Rust library
>   - Secure handshake and AES-GCM transport
>   - C ABI bridge for compatibility
> 
> Repository: https://github.com/MiesSuomesta/STCP/tree/main/kernel-module
> 
> I would appreciate feedback from the Rust-for-Linux and netdev communities
> on integration strategy and long-term direction.

Why not just submit patches like any other normal kernel feature/submission?

thanks,

greg k-h

Re: [RFC] Secure TCP (STCP): Rust-based encrypted transport protocol for kernel integration

[Miguel Ojeda]

On Mon, Nov 10, 2025 at 11:27 PM Lauri Jakku, CEO Of Paxsudos IT
<lauri.jakku@paxsudos.fi> wrote:
>
> I would appreciate feedback from the Rust-for-Linux and netdev
> communities on integration strategy and long-term direction.

Sounds good -- I would suggest Cc'ing netdev, since they are the ones
that will decide if they want this. I would also suggest Cc'ing the
relevant maintainers directly, not just the list.

In general, as Greg said, you will likely want to have at least
patches for a prototype that can be applied upstream, i.e. to the
mainline kernel.

Cheers,
Miguel

Re: [RFC] Secure TCP (STCP): Rust-based encrypted transport protocol for kernel integration

[Lauri Jakku, CEO Of Paxsudos IT]

Hi,

   Nice, I'll do just that then. I'll clean up the code for patch 
submission.

--Lauri

Miguel Ojeda kirjoitti 11.11.2025 klo 23.25:
> On Mon, Nov 10, 2025 at 11:27 PM Lauri Jakku, CEO Of Paxsudos IT
> <lauri.jakku@paxsudos.fi> wrote:
>> I would appreciate feedback from the Rust-for-Linux and netdev
>> communities on integration strategy and long-term direction.
> Sounds good -- I would suggest Cc'ing netdev, since they are the ones
> that will decide if they want this. I would also suggest Cc'ing the
> relevant maintainers directly, not just the list.
>
> In general, as Greg said, you will likely want to have at least
> patches for a prototype that can be applied upstream, i.e. to the
> mainline kernel.
>
> Cheers,
> Miguel
> .---<[ Paxsudos IT / Security Screening ]>---------------------------------------------------------------->
> | Known viruses: 8708713
> | 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 1.00:1)
> | Time: 18.996 sec (0 m 18 s)
> | Start Date: 2025:11:11 22:26:09
> | End Date:   2025:11:11 22:26:28
> | SPAM hints: []
> | SPAM hints: []
> | Message not from DMARC.
> `-------------------------------------------------------------------->
.---<[ Paxsudos IT / Security Screening ]>---------------------------------------------------------------->
| Known viruses: 8708713
| 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 1.00:1)
| Time: 22.838 sec (0 m 22 s)
| Start Date: 2025:11:12 06:04:13
| End Date:   2025:11:12 06:04:36
| SPAM hints: []
| SPAM hints: []
| Message not from DMARC.
`-------------------------------------------------------------------->

Re: [RFC] Secure TCP (STCP): Rust-based encrypted transport protocol for kernel integration

[Lauri Jakku, CEO Of Paxsudos IT]

Hi,

   Now i've cleaned the code from warnings, the code now is at:

https://github.com/MiesSuomesta/STCP/tree/main/kernel/OOT/linux


   The STCP module is brand new addition to kernel, and it upgrades any 
ordinary TCP connection to very secure TCP

   connection, just by a protocol number change from IPPROTO_TCP to 
IPPROTO_STCP.


   I've done it for userspace also, but I tought that kernel module is 
more practical and the effort to use the encrypted

   TCP would be minimal, just a change the socket creation from TCP => STCP.


   Next: I'll create patch for submission ..

--Lauri Jakku / Paxsudos IT


Lauri Jakku, CEO Of Paxsudos IT kirjoitti 12.11.2025 klo 6.04:
> Hi,
>
>   Nice, I'll do just that then. I'll clean up the code for patch 
> submission.
>
> --Lauri
>
> Miguel Ojeda kirjoitti 11.11.2025 klo 23.25:
>> On Mon, Nov 10, 2025 at 11:27 PM Lauri Jakku, CEO Of Paxsudos IT
>> <lauri.jakku@paxsudos.fi> wrote:
>>> I would appreciate feedback from the Rust-for-Linux and netdev
>>> communities on integration strategy and long-term direction.
>> Sounds good -- I would suggest Cc'ing netdev, since they are the ones
>> that will decide if they want this. I would also suggest Cc'ing the
>> relevant maintainers directly, not just the list.
>>
>> In general, as Greg said, you will likely want to have at least
>> patches for a prototype that can be applied upstream, i.e. to the
>> mainline kernel.
>>
>> Cheers,
>> Miguel
>> .---<[ Paxsudos IT / Security Screening 
>> ]>---------------------------------------------------------------->
>> | Known viruses: 8708713
>> | 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 1.00:1)
>> | Time: 18.996 sec (0 m 18 s)
>> | Start Date: 2025:11:11 22:26:09
>> | End Date:   2025:11:11 22:26:28
>> | SPAM hints: []
>> | SPAM hints: []
>> | Message not from DMARC.
>> `-------------------------------------------------------------------->
.---<[ 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.238 sec (0 m 12 s)
| Start Date: 2025:12:22 15:31:53
| End Date:   2025:12:22 15:32:05
| SPAM hints: []
| SPAM hints: []
| Message not from DMARC.
`-------------------------------------------------------------------->

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

[Lauri Jakku]

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.
`-------------------------------------------------------------------->

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

[Jakub Kicinski]

On Mon, 22 Dec 2025 20:13:40 +0200 Lauri Jakku wrote:
> 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.

We tend to merge transport crypto protocol support upstream if:
 - HW integration is needed; or
 - some network filesystem/block device needs it.
Otherwise user space is a better place for the implementation.

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

[Lauri Jakku]

Hi All,

Jakub Kicinski kirjoitti 3.1.2026 klo 1.49:
> On Mon, 22 Dec 2025 20:13:40 +0200 Lauri Jakku wrote:
>> 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.
> We tend to merge transport crypto protocol support upstream if:
>   - HW integration is needed; or
>   - some network filesystem/block device needs it.
> Otherwise user space is a better place for the implementation.

  I got Nordic Semiconductor contact, that asked if it is upcoming 
feature for kernel, the need is there (For modem use).


> .---<[ Paxsudos IT / Security Screening ]>---------------------------------------------------------------->
> | Known viruses: 3627095
> | 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: 11.383 sec (0 m 11 s)
> | Start Date: 2026:01:03 01:50:02
> | End Date:   2026:01:03 01:50:13
> | SPAM hints: []
> | SPAM hints: []
> | Message not from DMARC.
> `-------------------------------------------------------------------->
.---<[ Paxsudos IT / Security Screening ]>---------------------------------------------------------------->
| Known viruses: 3627110
| 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.740 sec (0 m 12 s)
| Start Date: 2026:01:05 17:38:31
| End Date:   2026:01:05 17:38:43
| SPAM hints: []
| SPAM hints: []
| Message not from DMARC.
`-------------------------------------------------------------------->

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

[Jakub Kicinski]

On Mon, 5 Jan 2026 17:38:28 +0200 Lauri Jakku wrote:
> Jakub Kicinski kirjoitti 3.1.2026 klo 1.49:
> > On Mon, 22 Dec 2025 20:13:40 +0200 Lauri Jakku wrote:  
> >> 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.  
> > We tend to merge transport crypto protocol support upstream if:
> >   - HW integration is needed; or
> >   - some network filesystem/block device needs it.
> > Otherwise user space is a better place for the implementation.  
> 
>   I got Nordic Semiconductor contact, that asked if it is upcoming 
> feature for kernel, the need is there (For modem use).

Please come back once it's actually adopted and deployed somewhere.