diff --git a/src/pages/blog/zero-dependency-encryption-x25519-aes-gcm.astro b/src/pages/blog/zero-dependency-encryption-x25519-aes-gcm.astro index 63739d1..8e835d3 100644 --- a/src/pages/blog/zero-dependency-encryption-x25519-aes-gcm.astro +++ b/src/pages/blog/zero-dependency-encryption-x25519-aes-gcm.astro @@ -262,7 +262,28 @@ Message delivered
For how encryption integrates with Pilot's trust model and Ed25519 identity system, see Secure AI Agent Communication With Zero Trust. For the full protocol architecture including addressing, transport, and services, see How Pilot Protocol Works. For real-world applications of this encryption in sensitive environments, see Secure Research Collaboration: Share Models, Not Data and Building a Private Agent Network for Your Company.
+X25519 key exchange is often paired with AES-128-GCM rather than AES-256-GCM. TLS 1.3 defines TLS_AES_128_GCM_SHA256 as its mandatory-to-implement cipher suite, and WireGuard's Noise-based handshake also derives a 128-bit symmetric key for its ChaCha20-Poly1305 transport. Seeing X25519 next to AES-128-GCM in a protocol spec or a TLS handshake trace is common, and it is a deliberate, well-reasoned choice in those designs -- a 128-bit key already provides a security margin considered adequate against classical cryptanalysis, and a smaller key can mean marginally less work per block cipher round.
Pilot Protocol's key derivation from X25519 produces a 32-byte (256-bit) shared secret, and the daemon uses the full 32 bytes as the AES-256-GCM key rather than truncating to 16 bytes for AES-128-GCM. Go's crypto/aes package selects the cipher variant purely from key length -- aes.NewCipher returns an AES-128 cipher for a 16-byte key and an AES-256 cipher for a 32-byte key, with no separate code path required. Since X25519's ECDH output is already 32 bytes, using all of it for AES-256 avoids a truncation or key-derivation step that AES-128-GCM would otherwise need.
| Aspect | AES-128-GCM | AES-256-GCM (Pilot) |
|---|---|---|
| Key size | 16 bytes | 32 bytes |
| Rounds (AES block cipher) | 10 | 14 |
| Common pairing | TLS 1.3 default suite, WireGuard-style handshakes | TLS 1.3 optional suite, protocols that use the full X25519 ECDH output directly |
| Hardware acceleration | AES-NI / ARMv8 Crypto Extensions | AES-NI / ARMv8 Crypto Extensions (same instruction set, more rounds executed) |
| Authentication | GCM tag, same construction | GCM tag, same construction |
Both variants use the identical GCM authenticated-encryption construction described above -- the same nonce format, the same 16-byte authentication tag, the same Seal/Open API in Go's standard library. The only difference is how many AES rounds the block cipher runs and how large the key is. Pilot's choice of AES-256-GCM is not a rejection of AES-128-GCM as insecure; it is simply the more direct fit for a design that already produces a 256-bit ECDH shared secret from X25519 and wants to use it in full, with a single, uniform key size across every tunnel, protocol version, and platform the daemon runs on.
For how encryption integrates with Pilot's trust model and Ed25519 identity system, see Secure AI Agent Communication With Zero Trust. For the full protocol architecture including addressing, transport, and services, see How Pilot Protocol Works. For real-world applications of this encryption in sensitive environments, see Secure Research Collaboration: Share Models, Not Data and Building a Private Agent Network for Your Company. For a broader look at how this encrypted transport fits into peer discovery and reachability, see Overlay Network for AI Agents: Architecture and Trust Model.