New Pure Post-Quantum Protocol Specification

Introduction The Abdelaziz Pure Key Protocol is a pure PQC protocol designed to protect systems against transport layer attacks using post-quantum algorithms. It was designed with privacy and security in mind. The protocol uses a variety of algorithms and techniques to ensure the protocol is heavily secured. This can be used in any service, including VPNs, finance services, etc. Every packet going into the service MUST be timestamped and nonced. The clients that connect MUST also solve the PoW. If the PoW is missing, malformed, or takes >450ms to solve, the connection is aborted instantly.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Explanation of Each 'Task' and Algorithm In this section, each "task" and algorithm's functions and operations are explained, along with how they are used in specific areas of the protocol.

Cryptographic-Based PoW Solving It is a "task". Its function is to make clients solve a cryptographic hash that is completely different for each connection, along with different instructions to solve.

ML-DSA It is an MLWE Digital Signature Algorithm primarily used outside the protocol for mutual authentication. Its function in the protocol is to sign and verify to ensure that the server is the only destination recipient. When a service is booted, a 3-hour rotating ML-DSA certificate is generated. It is required for the client to generate an ML-DSA certificate for every connection.

ML-KEM-768 It is a post-quantum MLWE algorithm primarily used to derive the shared secret and encapsulate ciphertext. Its function in the protocol is to derive an SS (Shared Secret) and encapsulate ciphertext. When a service is booted up, it uses ephemeral 3-hour rotating ML-KEM keypairs. It is also required for the client to generate rotating ML-KEM keypairs every time a connection is made.

HQC-256 It is an algorithm used with ML-KEM. HQC-256 is also used to encapsulate ciphertext but adds intended noise to the ciphertext. HQC is also used with ML-KEM to generate the final master keys for AES.

AES-256-GCM It is an encryption algorithm primarily used outside the protocol for encrypting plaintext. Its function in the protocol, after a successful handshake, is to encrypt packets in the form: AES-256-GCM(PLAINTEXT || METADATA || INTENDPROTOCOL)+TMS+COUNTNON+TAG where: * PLAINTEXT refers to the plain data being sent. * INTENDPROTOCOL refers to the intended protocol (like TLS). Due to early testing, developers MUST add INTENDPROTOCOL. However, in future services, developers MAY use it without intending a protocol provided INTENDPROTOCOL is labelled "AHKP". This does not mean INTENDPROTOCOL is removed, as it is required. It operates in Galois/Counter Mode . * The || or double pipes refer to binary byte concatenation.

SHAKE256 It is an XOF algorithm that, outside the protocol, is primarily used to stretch and extend bytes, generate seeds, and derive the output to be fed into the HKDF to get the final key used for the decryption of other encryption algorithms. Its function in the protocol is to derive the output for HKDF. However, developers SHOULD add seeds if the purpose is towards more security. The only exception is for HKDF, where seeds are REQUIRED as the IKM of the HKDF-Extract.

HKDF via SHA-384 + salting It is an HMAC-based algorithm used for deriving the final keys for AES-256-GCM. The output of SHAKE-256 is hashed to obtain the PRK to create the final AES keys.

Handshake and Connection Establishment The handshake first begins when a client sends a hello to the server. The server replies with a PoW for the client to solve. The client MUST solve the PoW in <450ms. If the client fails to do so, solves the PoW in > 450ms, or uses a wrong answer, the handshake is aborted. The PoW MUST be different with different instructions for each connection. Then, the client sends the HWID to the server. If the HWID is malformed or corrupt, or if there are suspicious behaviors checked by the server, it MUST abandon the handshake. The server checks the HWID against a BLK (blacklist). If whitelisted, the connection continues, and vice versa. Then, the client generates an ML-DSA certificate. It signs the packet using the private key and sends it to the server. The packet is REQUIRED to be in the form of ML-DSA(METADATA || UNIQUE_ID || POW || SERVER_PUB_IP_AND_PORT). The server does not check the POW twice. If any fields are missing or the signature is corrupt, safely abandon the handshake and drop the remaining packets. The server verifies the signature using the public key. The server responds using its 3-hour ML-DSA private key to sign the certificate. The public IP and port MUST be grabbed from the system and MUST NOT be grabbed from the database. If the source code is modified to grab from the database or the IP is spoofed, instantly drop the connection. Once the signatures are verified, the client generates an ML-KEM and HQC keypair. Both MUST send the public keys and encapsulate the ciphertext in accordance with Section 8.1 ("Vulnerabilities and Fixes") in this document. To prevent further MITM attacks, ML-DSA MUST sign both the HQC and ML-KEM keypairs to verify the signature and derive the SS using SHAKE256(HQC-SS(32) || ML-KEM-SS(32) || ML-KEM-CT || HQC-CT || CONTEXT(16)). HKDF via SHA-384 MUST be used in accordance with , which is used to create the final keys to decrypt the AES encrypted packets. Once formed, both send packets in the form AES-256-GCM(PLAINTEXT || METADATA || INTENDPROTOCOL)+TMS+COUNTNON+TAG. If the final key is entirely different, errors will occur. To detect if the final key is different, a minimum and maximum of 1 error regarding the key MUST be detected to abort the connection. Every packet from the start of the handshake to the end of the handshake MUST be sent with RNGNON and TMS, and every packet from the start of the connection to the end of the connection MUST be sent with TMS, COUNTNON, and formatted with AEAD in accordance with .

Meanings

Abbreviation	Meaning
POW	Proof of Work
TMS	Timestamp
RNGNON	Nonces generated via CSPRNGs
TAG	AEAD tag of AES-256-GCM
COUNTNON	Counting nonce of AES-256-GCM

Networking and Packet Forms Due to the ML-KEM and HQC keys, the ML-DSA certificates, and other content, the expected packet size is 22-27KB. This introduces challenges where it may collide with the issues outlined in Section 8.1 ("Vulnerabilities and Fixes") in this document. To prevent this, split the UDP packets in accordance with and number them so the server knows how to reorganize them. APKP that uses UDP adheres to the best current practices as defined in , Packet encapsulation may be subject to standards such as . All protocol metadata, such as message type indicators and numbering adhere to the formats in

TCP and UDP TCP prioritizes organization over speed , using three-way handshakes (SYN, SYN-ACK, ACK). TCP also tracks the number of bytes that are sent, and if any packets are lost or corrupted, TCP requires retransmission. However, TCP may bundle multiple messages into one packet (also called packetization) and may delay sending small messages to group them into one. This may cause errors with the messages. To prevent this, add an MTI or Message Type Indicator to each message. TCP is also vulnerable to TCP SYN flood attacks. To mitigate this, APKP MUST implement SYN flood control in accordance with . UDP prioritizes speed over organization , leading to congestion and, due to disorganization, servers getting confused. To prevent this, number each message and payload and indicate its type by MTI before reaching the server. The protocol MUST implement congestion control using CUBIC. This implements a reliable transport shim over UDP. ensuring TCP-friendly bandwidth, while manintaing the speed and flexiability of UDP. The packets are in the form of the source and destination IP, the source MAC address and the context of the payload, all encapsulated in a Wi-Fi or Ethernet frame and signed with the initial keys to prevent modification or injection into the packet.

Benefits over Existing Protocols like TLS TLS 1.3 is known to use X25519 in its protocol and ECDSA , but ML-DSA will be finalized into TLS 1.3. Even PQ-TLS uses a hybrid mix of ML-KEM and X25519. Since TLS 1.3 uses X25519, an attacker with a quantum computer can and will downgrade TLS 1.3 even if it is post-quantum. TLS 1.3 already prevents this and therefore does not count for APKP as a benefit. However, using HQC as a replacement for X25519 is a benefit to TLS because HQC-256 is a post-quantum KEM algorithm that is secure against quantum computers. This eliminates the risk of a hybrid protocol being cracked if downgraded to X25519. TLS has already dropped support for RSA and other weak algorithms in its suite and mandated PFS. APKP's way of approaching PFS is to generate an hourly-rotating initial session for the server, and generated every time the user launches the client application. It then uses these initial keys to sign, decapsulate, and acquire the actual public key used for the derivation of the SS. This provides a benefit because, first, instead of an attacker targeting one keypair, an attacker must target two post-quantum keypairs; and second, because the initial keypairs are REQUIRED to decrypt and acquire the public key used for the connection. This process is entirely out of DH key exchange and ECDH. APKP MUST NOT use a suite of tools to prevent any advanced downgrade. APKP also MUST protect the keys in accordance with Section 8.1 ("Vulnerabilities and Fixes") in this document. When a client in TLS initiates a ClientHello, the server instantly commits its memory and CPU to do heavy math. This results in DDoS. The PoW fixes this. By mandating that PoWs be solved in < 450ms and blocking connections to botnets detected spamming invalid PoW solutions, it prevents DDoS attacks. This is also a benefit to APKP.

Security Considerations Timestamping protects from replay but does not protect from side-channel attacks. The same goes for CSPRNG and counting nonces. Other vulnerabilities different from side-channel attacks may go unnoticed. To prevent this, the protocol MUST implement these fixes.

Vulnerabilities and Fixes

An attacker can and will craft specialized packets to see how the server responds. This could be a major flaw, revealing the private key through timing. To prevent this, the server MUST respond within exactly 75ms. Or, if under load, extend to 145ms. This only applies to the server execution time. It MUST NOT apply to the client nor the normal server network response time of 150ms or up to 475ms under heavy load. Another flaw is that the chip uses a changing number of CPU cycles that, if measured by power cycles or electromagnetic spikes, could be mapped out and also leak the private key. To prevent this, operations MUST be shuffled randomly using the GPU, an HSM, or TPM, like moving A to C, B to D, F to E. The selected hardware MUST be set and never changed. Masking MUST be applied where sensitive actions are divided into mathematical shares and masked using arithmetic operations. When a security operation is completed in 2ms, the remaining milliseconds MUST be filled with basic arithmetic tasks. If done in the GPU, it is REQUIRED to be hidden in a protected environment.
An attacker can and will capture PoW answers and other important data to fake an authentic connection. To prevent this, make sure the client responds within a specified 375ms. If the 375ms limit is exceeded, drop the connection. This only represents the total round-trip time. Also, limit the number of packets entering to prevent replay. This also aids in combating DDoS and replay attacks. Nonces and timestamps already prevent replay, but limiting packets is a backup if they fail.
An attacker can and will send malformed ML-KEM keys or HQC keys. They can also send malformed ML-DSA certificates and ciphertext. This leaves a massive door open for vulnerabilities like downgrading, man-in-the-middle attacks, and eavesdropping. To prevent this, the server MUST check if the ML-DSA certificate was created very recently (within the last 30 seconds), matches its expected form, and matches a specific ID generated by both the client and server. The same applies for the keys: check if the ML-KEM or X25519 keys match their expected form, and check for any anomalies like a different HWID, MAC, IMEI, or IP address than what was seen before. Implement strict AEAD authentication so that if anything in it was modified or injected, it instantly self-destructs. This is still vulnerable to Layer 2 attacks, such as ARP poisoning, which are external. To prevent this, the protocol MUST check if the HWID is different than before. Also, inspect the ARP packets using DAI. The HWID MUST be signed .
An attacker can and will turn the PoW for the server to solve it instead of the client. This leaves a door for buffer overflow, resource exhaustion, or coordinated DDoS attacks. To prevent this, if the PoW is sent unsolved and a malicious code tells the server to solve it instead, instantly drop the packet and connection, and flag the attacker responsible. This prevents "turning the tables" from happening. The malicious code could be hidden from the server and executed once the POW is inspected. Making the POW read-only is a way to prevent this.
An attacker can and will flood the server with thousands of invalid PoW solutions. This blocks legitimate users and is an alternative way to DDoS a server. To prevent this, if thousands of packets spike suddenly, block connections that send invalid PoW solutions and blacklist them. Check each POW in a group, where a group contains 40 answers. The DDoS attacks could be blended with traffic. Wipe each POW from memory after checking and check if there are more invalid solutions than normal.
An attacker can and will collect a user's sensitive device identifiers if they are transmitted in plaintext. Note that source/destination IP addresses and MAC addresses are inherently visible in unencrypted network and link-layer headers for packet routing, meaning encrypting them inside the application payload does not hide them from network eavesdroppers. However, internal identifiers like the IMEI are not part of standard routing headers and must be protected. Furthermore, hashing identifiers with SHA-256 creates a one-way value that cannot be decrypted back to plaintext by the server. To resolve this, the client MUST encrypt the IMEI and HWID using AES-256-GCM without hashing them first. The payload MUST be in the form AES-256-GCM(IMEI || HWID) to be safely decrypted by the server. The server then validates these decrypted identifiers, along with the actual source IP and MAC addresses extracted directly from the incoming network packet headers, against its blacklist. If there is a massive unnatural surge, block the connections and do not reply.
An attacker can and will try to guess the public and private key on a server. This can lead to users getting spied on without knowing. 3-hour rotating keys, blacklists, and every-connection generation for clients already combat this. However, if an attacker takes the final AES key from the connection they have made and uses it against users, it will lead to a massive amount of people's data being stolen. To prevent this, the final key MUST be wiped and expired every time the connection is ended on both the client and the server. The key also MUST stay hidden from the user in a protected, isolated environment; for example, zeroized memory or ephemeral protected enclaves.
An attacker with a quantum computer can and will exhaust the 3-hour rotating keys. This will leave a door to an advanced downgrade, leading to users getting eavesdropped on. To prevent this, the system will remember this key for 3 hours. This will still be vulnerable to buffer overflow and, if the server is hacked, a full leak. The memory is REQUIRED to be read-only and limited to prevent buffer overflow, completely isolated from the network, and put in a protected enclave.
An attacker can and will disrupt the CSPRNGs. This opens a door for even more DDoS attacks. To prevent this, use hardware-based CSPRNGs. This ensures that even if the server is hit with coordinated DDoS attacks, the hardware never fails. Isolate the CSPRNGs from the network. To ensure the integrity of numbers, implementations MUST adhere to the standards outlined in .
The time could drift off at any given time. If this happens, it will be permanent. To prevent this, an atomic clock SHOULD be used, but it is OPTIONAL. The clock's NTP configuration MUST be updated every 24 hours to prevent time drifts. It also MUST be isolated from the network. To prevent attackers from disrupting the NTP, there should be a separate clock to be updated manually and completely isolated. To prevent time drift, the NTP MUST be managed in accordance with .
Failsafe Tuning: To prevent legitimate users from getting dropped, the client is REQUIRED to measure the speed of the local local network, along with pinging test servers. To prevent attackers from abusing this tuning, the client checks for client-side and server-side internet speed throttlers and ping throttlers. In normal conditions, where the speed is > 40Mbps and the pinging of test servers is < 150ms, the floor and ceiling are exactly still 450ms to prevent further false positives in cases where there is high traffic or network congestion. At this stage, the client appends a special identifier that MUST be sent unencrypted. It MUST add this identifier, and if it is missing, malformed, or does not match its expected form of being with metadata about the connection, the packet will be instantly rejected, along with the connection being dropped.
An attacker can and will send packets and/or fragmented packets. This opens a door for DDoS attacks via memory. To prevent this, allocate 575ms for each packet or fragmented packet. If it exceeds this, then the packets are forgotten by the server.
An attacker can and will exploit cryptanalysis. If done, it will open a door for eavesdropping. To prevent this, implement a PFS-style policy. Both peers MUST generate an initial rotating ML-KEM-768 and HQC-256 keypair. For users, it is generated every time the client application is opened. For servers, it is generated every hour for initial keys and certificates, while for actual connection keys, it will be every three hours. The actual public key that will be used for the connection MUST be encrypted and signed with those initial keypairs and certificates. However, cryptanalysis will be on the initial keys. To mitigate this, as listed in Section 4 ("Handshake and Connection Establishment") in this document, both peers MUST mutually authenticate each other using ML-DSA, and every packet from the start of the handshake to the end MUST be signed.
Bugs may occur if not configured properly, To prevent this, (7, Vulnerabilities and Fixes) and (3, Explanation of Each 'Task' and Algorithm) MUST implement requirements as defined in .

IANA Considerations This document requests IANA to assign a dedicated global system port identifier for the Abdelaziz Pure Key Protocol across both UDP and TCP transport mediums to ensure standardized service identification and packet routing. Associated Port Parameters: * Protocol: UDP and TCP * Port Number: 62192 (Requested for experimental testing) * Service Name: apkp * Description: Abdelaziz Pure Key Protocol Furthermore, this document requests the creation of a new IANA registry titled the "APKP Cryptographic Suite Registry". This registry will manage and track 16-bit identifiers for future hybrid post-quantum algorithm suites, ensuring that extensions or modifications to the baseline algorithm mix can be securely negotiated.