| Internet-Draft | Hybrid PQ Protocol | June 2026 |
| Muhammad | Expires 15 December 2026 | [Page] |
The Abdelaziz Hybrid Key Protocol, a.k.a AHKP was designed to protect new systems with hybrid, post quantum mechanics.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 15 December 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
The Abdelaziz Hybrid Key Protocol is a hybrid PQC protocol was designed to protect systems against transport layer attacks using post quantum algorithms. It was designed with the mind of privacy and security. The protocol uses a variety of algorithms and techniques to make sure the protocol is heavily secured. This can be used in any service even if they are 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 >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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
In this section, each "task" and algorithms are explained its functions and how it works, and 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 every connection.¶
It is an MLWE algorithm that is post quantum primarily used to derive the shared secret. Its function in the protocol is to derive a SS (Shared Secret) and encapsulate packets. 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 it 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:¶
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 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 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 to derive the SS from using the private key in the packet form of SS = ML-KEM || X25519. Then that SS is fed into SHAKE256 in the form SHAKE256(ML-KEM_SS(32) || X25519_SS(32) || CONTEXT(16)) to form the final key required to decrypt the AES encrypted packets. Once formed, both send packets in 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 start of handshake to end of handshake MUST be sent with RNGNON and TMS and every packet from start of connection to end of connection MUST be sent with TMS, COUNTNON and TAG.¶
POW means Proof of works. The double pipes (||) refers 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.¶
Timestamping protects from replay but does not protect from side channel attacks. Same for CSPRNG and counting nonces. In order to fix this along with other vulnerabilities, the protocol MUST implement these fixes.¶
1. 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. 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 SHOULD 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 doing basic arithmetic tasks. If done in the GPU, it MUST be hidden in a protected environment.¶
2. 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 450ms. If the 450ms 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 attacks. Nonces and timestamps already prevent this.¶
3. 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, look if the ML-KEM or X25519 keys match their expected form and check for any anomalies like a different HWID, MAC or 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.¶
4. 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 a 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.¶
5. 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.¶
6. An attacker can and will collect a user's sensitive information like IP addresses. This opens a massive door for privacy violations and easier spoofing. 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 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.¶
7. 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 rotatings, blacklists and every connection generation 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 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 claves.¶
8. 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. The memory is required to be read-only and be limited to prevent buffer overflow, and completely isolated from the main memory.¶
9. 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.¶
10. The time could drift 1 minute off. 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 network.¶
11. 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. And to prevent attackers from abusing this tuning, the client checks for client side and server side internet speed throttlers and ping throttlers except those of ISPs. In normal conditions, where the speed > 40Mbps and the pinging of test servers is < 150ms, the floor and ceiling is 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. And it MUST add this identifier and if it is missing or malformed or does not match its expected form of being with a metadata about the connection time, the packet will be instantly rejected along with the connection being dropped.¶
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:¶
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.¶