New Hybrid Post-Quantum Protocol Specification

The Abdelaziz Hybrid Key Protocol is a hybrid 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 make sure 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 or malformed, or is solved in >450ms, the connection is aborted instantly.

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.

In this section, each "task" and algorithm is explained regarding its functions, how it works, and how it is used in specific areas of the protocol.

It is a "task". Its function is to make clients solve a cryptographic hash that is completely different with each connection, along with different instructions to solve.

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 make sure that the only destination recipient is the server. When a service is booted, a 3-hour rotating ML-DSA certificate is generated. It is required for the client to generate ML-DSA certificates for every connection.

It is an MLWE algorithm that is post-quantum, primarily used to derive the shared secret and encapsulate ciphertext . Its function in the protocol is to derive a SS (Shared Secret) and encapsulate ciphertext. When a service is booted up, they use 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.

It is a classical cryptographic algorithm that is primarily used to derive the shared secret . Its function in the protocol is to derive an SS if ML-KEM has a flaw or fails. Even if it does not fail or does not have a flaw, the X25519 shared secret MUST be derived for more security.

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 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. The || or double pipes refer to binary byte concatenation.

It is an XOF algorithm that outside the protocol is primarily used to stretch and extend bytes, generate seeds, and derive the final key used for decryption of other encryption algorithms . Its function in the protocol is to derive the final AES key for decryption. However, developers SHOULD add seeds if the purpose is towards more security.

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 <450ms. If the client fails to do so, solves the PoW >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 there are suspicious behaviors checked by the server, it MUST abandon the handshake. The server checks the HWID in BLK or the blacklist. If whitelisted, then continue, 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 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 signatures are verified, the client generates an ML-KEM and X25519 keypair. Both send the public keys and encapsulate the ciphertext using ML-KEM. To prevent further MITM attacks, ML-DSA MUST sign both the X25519 and ML-KEM keypair. to verify signature and use the keypairs to derive the SS using SHAKE256(X25519(32) || ML-KEM(32) || CONTEXT(16)) to form the final key required 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, then 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 TAG.

POW means Proof of work. The double pipes (||) refer to binary byte concatenation. TMS means timestamp. RNGNON means nonces generated via CSPRNGs. TAG means the AEAD tag of AES-256-GCM. COUNTNON means the counting nonce of AES-256-GCM.

Due to the ML-KEM and X25519 keys, the ML-DSA certificates, and other content, expect the packet size to be 6-10KB. For primary MTU sizes, it is RECOMMENDED to be within 1450-1500. However, if not possible, it is in the 1400-1280 range to allow for packet fragmentation. If firewalls are behind the server, the firewalls MUST allow fragmented packets regardless.

Timestamping protects against replay but does not protect against side-channel attacks. The same applies to CSPRNGs and counting nonces. Other vulnerabilities different from side-channel attacks may go unnoticed. To prevent this, the protocol MUST implement these 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 with 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 by doing 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 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 combatting 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 X25519 keys. They can also send malformed ML-DSA certificates. This leaves a massive door open for vulnerabilities like downgrading and eavesdropping. To prevent this, the server MUST look if the ML-DSA certificate was created very recently, within the last 30 seconds, and matches its expected form, and if it matches a specific ID generated by both the client and server. The same applies for the keys: look 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 that, if anything in it was modified or injected, instantly self-destructs. This is still vulnerable to Layer 2 attacks such as ARP poisoning, which is external. To prevent this, the protocol MUST see 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, source exhaustion, or coordinated DDoS attacks. To prevent this, if the PoW is sent unsolved and malicious code told 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 be 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 information like IP addresses. This opens a massive door for privacy violations. To prevent this, hash the IP and IMEI or MAC with SHA256 and encrypt them with AES-256-GCM. To prevent spoofing, the packets containing them MUST be in the form AES-256-GCM(PLAINTEXT) to be later decrypted by the server to verify against a 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 generating new keys for every connection for clients already combat this. However, if an attacker takes the final AES key from the connection he has 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 due to the X25519 keys being used. To prevent this, the system will remember this key for 3 hours. It will never look up the keys every time a handshake is made. Once the 3 hours are up, the system does a one-time lookup for the new keys and remembers them. However, this will 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, and completely isolated from the network. It must also be 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 makes sure 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 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, for each packet or fragmented packet, allocate 575ms for processing. If it exceeds this, then the packets are forgotten by the server.

This document requests IANA to assign a dedicated global system port identifier for the Abdelaziz Hybrid 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: ahkp Description: Abdelaziz Hybrid Key Protocol Furthermore, this document requests the creation of a new IANA registry titled the "AHKP 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.