Network Working Group A. Muhammad Internet-Draft Independent Intended status: Experimental 15 June 2026 Expires: 17 December 2026 New Hybrid Post-Quantum Protocol Specification draft-muhammad-ahkp-pqcprotocol-03 Abstract The Abdelaziz Hybrid Key Protocol, a.k.a. AHKP, was designed to protect systems with hybrid, post-quantum mechanics and transition to full PQC in the future. It is used in high-security environments to protect against quantum attacks. Status of This Memo 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 17 December 2026. Copyright Notice 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. Muhammad Expires 17 December 2026 [Page 1] Internet-Draft Hybrid PQ Protocol June 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 3. Explanation of Each "Task" and Algorithm . . . . . . . . . . 2 3.1. Cryptographic based PoW solving . . . . . . . . . . . . . 3 3.2. ML-DSA . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.3. ML-KEM . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.4. X25519 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.5. AES-256-GCM . . . . . . . . . . . . . . . . . . . . . . . 3 3.6. SHAKE256 . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Handshake and Connection Establishment . . . . . . . . . . . 4 4.1. Meanings . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Networking and Packet Forms . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6.1. Vulnerabilities and Fixes . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The Abdelaziz Hybrid Key Protocol is a hybrid PQC protocol designed to protect systems against transport layer attacks using post-quantum algorithms [RFC9370]. 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. 2. 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 [BCP14] when, and only when, they appear in all capitals, as shown here. 3. Explanation of Each "Task" and Algorithm 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. Muhammad Expires 17 December 2026 [Page 2] Internet-Draft Hybrid PQ Protocol June 2026 3.1. Cryptographic based PoW solving 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. 3.2. ML-DSA It is an MLWE Digital Signature Algorithm primarily used outside the protocol for mutual authentication [FIPS204]. 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. 3.3. ML-KEM It is an MLWE algorithm that is post-quantum, primarily used to derive the shared secret and encapsulate ciphertext [FIPS203]. 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. 3.4. X25519 It is a classical cryptographic algorithm that is primarily used to derive the shared secret [RFC7748]. 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. 3.5. AES-256-GCM It is an encryption algorithm primarily used outside the protocol for encrypting plaintext [NIST-SP800-38D]. 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. Muhammad Expires 17 December 2026 [Page 3] Internet-Draft Hybrid PQ Protocol June 2026 * The || or double pipes refer to binary byte concatenation. 3.6. SHAKE256 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 [SHAKE256]. 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. 4. 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 <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. Muhammad Expires 17 December 2026 [Page 4] Internet-Draft Hybrid PQ Protocol June 2026 4.1. Meanings 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. 5. Networking and Packet Forms 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. 6. Security Considerations 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. 6.1. Vulnerabilities and 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 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 [NIST-SP800-140] (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 Muhammad Expires 17 December 2026 [Page 5] Internet-Draft Hybrid PQ Protocol June 2026 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. 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 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. 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, 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 [IEEE-802.1Q], 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 [RFC826]. 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 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. 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. 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. Muhammad Expires 17 December 2026 [Page 6] Internet-Draft Hybrid PQ Protocol June 2026 6. 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. 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 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. 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 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. 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. Isolate the CSPRNGs from the network. To ensure the integrity of numbers, implementations MUST adhere to the standards outlined in [NIST-SP800-90A]. 10. 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 Muhammad Expires 17 December 2026 [Page 7] Internet-Draft Hybrid PQ Protocol June 2026 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 [RFC5905]. 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. 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. 12. 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. 7. IANA Considerations 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. Muhammad Expires 17 December 2026 [Page 8] Internet-Draft Hybrid PQ Protocol June 2026 8. References 8.1. Normative References [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, RFC 8174, March 1997, . [FIPS203] National Institute of Standards and Technology (NIST), "Module-Lattice-Based Key-Encapsulation Mechanism Standard", FIPS PUB 203, August 2024. [FIPS204] National Institute of Standards and Technology (NIST), "Module-Lattice-Based Digital Signature Standard", FIPS PUB 204, August 2024. [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, January 2016, . [NIST-SP800-38D] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM)", NIST Special Publication 800-38D, November 2007. [SHAKE256] National Institute of Standards and Technology (NIST), "SHA-3 Standard: Permutation-Based Hash and Extendable- Output Functions", FIPS PUB 202, August 2015. [RFC826] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37, RFC 826, November 1982, . [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010, . [NIST-SP800-90A] Barker, E. and J. Kelsey, "Recommendation for Random Number Generation Using Determinional Random Bit Generators", NIST SP 800-90A Rev. 1, June 2015. 8.2. Informative References Muhammad Expires 17 December 2026 [Page 9] Internet-Draft Hybrid PQ Protocol June 2026 [RFC9370] D'Anjou, C. and D. Flux, "Framework for Hybrid Key Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 9370, May 2023, . [NIST-SP800-140] Barker, E., "FIPS 140-3 Derived Test Requirements", NIST SP 800-140, March 2020. [IEEE-802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks—Bridges and Bridged Networks", IEEE 802.1Q-2018, July 2018. Author's Address Abdelaziz Muhammad Independent Cairo Egypt Email: abdoprofessional1011@gmail.com Muhammad Expires 17 December 2026 [Page 10]