QVTP/1 Protocol Reference

QVTP/1 is the Quantum VPN Transport Protocol. It keeps the shape of a modern VPN handshake and replaces the two parts that a quantum computer breaks: the Diffie Hellman key exchange becomes ML-KEM-1024, and the RSA or ECDSA identity proof becomes ML-DSA-87.

Cipher Suite

QVTP_MLKEM1024_MLDSA87_AES256GCM_SHA256
Role Algorithm Standard What it provides
Key encapsulation ML-KEM-1024 FIPS 203 Establishes the shared secret without ever sending it. Replaces Diffie Hellman.
Mutual authentication ML-DSA-87 FIPS 204 Each endpoint signs the transcript so neither can be impersonated.
Record encryption AES-256-GCM FIPS 197 / SP 800 38D Encrypts and authenticates every record on the wire.
Key derivation HKDF-SHA-256 RFC 5869 Expands the master secret into per direction traffic keys and the session ID.

Handshake

Four messages carry the tunnel from nothing to established. The client speaks first with an ephemeral key it will throw away, and the tunnel is not usable until both sides have verified a signature over the transcript. 

  Client                                                    Server
    |                                                         |
    |  1. ClientHello                                         |
    |     ML-KEM-1024 ephemeral public key   (1568 bytes)     |
    |     ML-DSA-87 signing key              (2592 bytes)     |
    | ------------------------------------------------------> |
    |                                                         |
    |                                        2. ServerHello   |
    |          ML-KEM-1024 ciphertext        (1568 bytes)     |
    |          ML-DSA-87 server signature    (4627 bytes)     |
    | <------------------------------------------------------ |
    |                                                         |
    |  3. ClientFinished                                      |
    |     ML-DSA-87 client signature         (4627 bytes)     |
    |     HMAC verify data                                    |
    | ------------------------------------------------------> |
    |                                                         |
    |                                     4. ServerFinished   |
    |          HMAC verify data                               |
    | <------------------------------------------------------ |
    |                                                         |
    |            tunnel established, records flow             |
    |  <===================================================>   |
MessageSenderCarriesEstablishes
ClientHello Client Ephemeral ML-KEM-1024 public key and the client ML-DSA-87 signing key Offers the key the server will encapsulate against
ServerHello Server ML-KEM-1024 ciphertext encapsulating the shared secret, plus the server signature Shared secret is now known to both sides, server identity proven
ClientFinished Client Client ML-DSA-87 signature over the transcript and HMAC verify data Client identity proven, session keys derived
ServerFinished Server HMAC verify data Both transcripts agree, tunnel is established

Key and Signature Sizes

ML-KEM-1024 public key
1568 bytes
ML-KEM-1024 ciphertext
1568 bytes
ML-DSA-87 public key
2592 bytes
ML-DSA-87 signature
4627 bytes
Session ID
16 bytes, derived through HKDF-SHA-256
Record nonce
12 bytes, sequence number combined with the static IV

These sizes are larger than the classical equivalents they replace. That cost is paid once per tunnel during the handshake, not per record.

Frame Format

Once the tunnel is up, every record carries a short cleartext header and an encrypted payload. Each direction has its own traffic key, and the nonce is the record sequence number combined with that direction static IV, the construction TLS 1.3 uses. 

  0        1        2        3        5                        N
  +--------+--------+--------+--------+------------------------+
  |  type  |  ver   |     length      |    ciphertext + tag    |
  +--------+--------+--------+--------+------------------------+
  |  1 B   |  1 B   |      2 B        |   length bytes         |

  type      0x17 application data, 0x16 handshake, 0x15 alert
  ver       0x01 for QVTP/1
  length    payload length including the 16 byte GCM tag
  keys      c2s and s2c traffic keys derived separately
  nonce     12 byte static IV combined with the 64 bit sequence number

Classical VPN Compared With QVPN

Property Classical VPN (IKEv2 / ECDH) QVPN (QVTP/1)
Key exchange ECDH on P 256 or Curve25519 ML-KEM-1024 encapsulation
Authentication RSA 2048 or ECDSA P 256 certificates ML-DSA-87 signatures, both directions
Record encryption AES-256-GCM AES-256-GCM
Forward secrecy Yes, against a classical adversary only Yes, and it holds against a quantum adversary
Quantum resistance None. Shor algorithm recovers the ECDH secret and forges the certificate signature Both the key exchange and the identity proof rest on lattice problems
Recorded handshake Decryptable later once a quantum computer exists Stays closed. Nothing recorded today becomes readable

The last row is the reason QVPN exists. Traffic captured today under a classical VPN can be stored and decrypted when the hardware arrives, an exposure known as harvest now, decrypt later. ML-KEM-1024 closes it, and because the ephemeral key is destroyed at the end of the handshake, compromising the long term identity key later does not open past sessions either.