New Pure Post-Quantum Protocol Specification
draft-muhammad-pquip-apkp-pqcprotocol-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Abdelaziz Muhammad | ||
| Last updated | 2026-06-18 | ||
| Replaces | draft-muhammad-ahkp-pqcprotocol, draft-muhammad-apkp-pqcprotocol | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-muhammad-pquip-apkp-pqcprotocol-00
pquip A. Muhammad
Internet-Draft 19 June 2026
Intended status: Standards Track
Expires: 21 December 2026
New Pure Post-Quantum Protocol Specification
draft-muhammad-pquip-apkp-pqcprotocol-00
Abstract
The Abdelaziz Pure Key Protocol, a.k.a. APKP, was designed to protect
systems with pure post-quantum mechanics and transition to full PQC
in the future. It is used in high-security environments to protect
against quantum attacks.
This doxument replaces and supersedes draft-muhammad-apkp-pqcprotocol
and draft-muhammad-ahkp-pqcprotocol.
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 21 December 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Muhammad Expires 21 December 2026 [Page 1]
Internet-Draft Pure PQ Protocol June 2026
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. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Explanation of Each 'Task' and Algorithm . . . . . . . . . . 3
3.1. Cryptographic-Based PoW Solving . . . . . . . . . . . . . 3
3.2. ML-DSA-87 . . . . . . . . . . . . . . . . . . . . . . . . 3
3.3. SLH-DSA . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.4. ML-KEM-768 . . . . . . . . . . . . . . . . . . . . . . . 4
3.5. HQC-256 . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.6. AES-256-GCM . . . . . . . . . . . . . . . . . . . . . . . 4
3.7. SHAKE256 . . . . . . . . . . . . . . . . . . . . . . . . 4
3.8. HKDF via SHA-384 + salting . . . . . . . . . . . . . . . 4
4. Handshake and Connection Establishment . . . . . . . . . . . 5
4.1. Meanings . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Networking and Packet Forms . . . . . . . . . . . . . . . . . 6
5.1. TCP and UDP . . . . . . . . . . . . . . . . . . . . . . . 6
6. Benefits over Existing Protocols like TLS . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7.1. Vulnerabilities and Fixes . . . . . . . . . . . . . . . . 8
7.2. Configurations of Security . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. 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. It is intented for all audiences around
the world, no matter if they are ordinay of cryptographers, or
workers. It is designed for everyone. It 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,
Muhammad Expires 21 December 2026 [Page 2]
Internet-Draft Pure PQ Protocol June 2026
or takes >450ms to solve, 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 [RFC2119] [RFC8174] 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's functions and operations
are explained, along with how they are used in specific areas of the
protocol.
3.1. 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.
3.2. ML-DSA-87
It is an MLWE (Machine Learning with Errors) Digital Signature
Algorithm [FIPS204] primarily used outside the protocol for mutual
authentication and signature. 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
signature is generated. It is required for the client to generate an
ML-DSA signature for every connection.
3.3. SLH-DSA
It is an SLH (Stateless Hash-Based) Digital Signature Algorithm
[FIPS205] also primarily used outside the protocol for mutual
authentication and signature. Its function in the protocol is to
sign packets and verify the server only if ML-DSA was flawed or
failed to work. It MUST NOT be used with ML-DSA as it is a fallback
option and if added, will result in more packet fragmentation and
bloat of the packets.
Muhammad Expires 21 December 2026 [Page 3]
Internet-Draft Pure PQ Protocol June 2026
3.4. ML-KEM-768
It is a post-quantum MLWE algorithm [FIPS203] 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.
3.5. HQC-256
It is a code-based PQC algorithm [HQC-SPEC] 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. It acts as the backup if ML-KEM-768
fails or is flawed.
3.6. 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 [NIST-SP800-38D]. * The || or double pipes refer to
binary byte concatenation.
3.7. SHAKE256
It is an XOF algorithm [FIPS202] 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.
3.8. HKDF via SHA-384 + salting
It is an HMAC-based algorithm [RFC5869] 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.
Muhammad Expires 21 December 2026 [Page 4]
Internet-Draft Pure PQ Protocol June 2026
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 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 signature or SLH-DSA if ML-DSA fails. 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 or SLH-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 or SLH-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 or SLH-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
[RFC5869], 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 [RFC5116].
Muhammad Expires 21 December 2026 [Page 5]
Internet-Draft Pure PQ Protocol June 2026
4.1. 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 |
+--------------+-------------------------------+
Table 1
5. Networking and Packet Forms
Due to the ML-KEM and HQC keys, the ML-DSA signatures, and other
content, the expected packet size is 22-27KB and with SLH-DSA, the
final expected packet size is 36-42KB. 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 using a IKE-modelled mechanism [RFC7383] and
number them so the server knows how to reorganize them. APKP that
uses UDP adheres to the best current practices as defined in
[RFC8085], Packet encapsulation may be subject to standards such as
[IEEE-802.1Q].
5.1. TCP and UDP
TCP prioritizes organization over speed [RFC9293], 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 [RFC4987]. UDP prioritizes speed over organization [RFC0768],
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 according to [RFC9438].
This implements a reliable transport shim over UDP. ensuring TCP-
Muhammad Expires 21 December 2026 [Page 6]
Internet-Draft Pure PQ Protocol June 2026
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. Once
packets are reassembled, the actual packet MUST be deleted and wiped
or zeroized or replaced with new incoming packets.
6. Benefits over Existing Protocols like TLS
TLS 1.3 [RFC8446] is known to use X25519 in its protocol and ECDSA
[RFC7748], 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.
7. 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.
Muhammad Expires 21 December 2026 [Page 7]
Internet-Draft Pure PQ Protocol June 2026
7.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 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.
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
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.
3. An attacker can and will send malformed ML-KEM keys or HQC keys.
They can also send malformed ML-DSA or SLH-DSA signautes 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 or SLH-DSA
signatures 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 HQC 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 [RFC0826].
Muhammad Expires 21 December 2026 [Page 8]
Internet-Draft Pure PQ Protocol June 2026
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,
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 on the text, and discarding
the code and packet once inspected is a way to prevent this
because one, the packet containing the code is stripped of extra
content and its essential is left and two, due to read only text
policies it will be not exexuted and three, wiping the packet
wipes malicious code.
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.
6. 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.
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 every-connection
generation for clients already combat this. However, if an
attacker takes the final AES key from the connection they have
Muhammad Expires 21 December 2026 [Page 9]
Internet-Draft Pure PQ Protocol June 2026
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 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.
9. An attacker can and will disrupt the CSPRNGs. This opens a door
for overloaded DDoS attacks and potential security
vulnerabilities. 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
[NIST-SP800-90A].
10. The time could drift off at any given time. If this happens and
it is left unprevented, it will keep drifting away from actual
time. This could cause false positive time sync errors with
legitimate users To prevent this, an atomic clock MAY 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 [RFC5905]. The NTP is not isolated
fron network because it requires an internet connection to sync
time.
11. 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, the maximum ceeling is up to 800ms for slow users.
Muhammad Expires 21 December 2026 [Page 10]
Internet-Draft Pure PQ Protocol June 2026
At this stage, the client appends a special identifier that MUST
be sent encapsulated with either the HQC metadata or ML-KEM
metadata. 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. The
identifier also MUST be signed and be sent without the user
knowing. Still if the connection speed is >=40Mbps and the
pinging is =<150Mbps, this identifier MUST be added.
12. 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.
13. 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, both peers MUST mutually
authenticate each other using ML-DSA or SLH-DSA, and every
packet from the start of the handshake to the end MUST be
signed.
7.2. Configurations of Security
Since unconfigured algorithms can and will be deadly, implementations
MUST be taken. The protocol depends on ML-DSA-87 or SLH-DSA, and PoW
for signature verification and mutual authentication to prevent man
in the middle attacks and DDoS but what happens if an attacker
compromises the signature, the public key and private key and the
proof of work? The resulting is that the signature is faked and a
client blindly accepts an impostor. To mitigate this attack,
implementations MUST include a database with each server containing
the public signature keys of a server only accessible with the IMEI
or MAC of a registered user, the mutual authentication of SHA-384
hashed and salted strings that match, and being not put on a
blacklist. If all three are matched, then the client is allowed to
access that database. The PoW MUST be included. Ignoring it or not
putting it will result in the connection being aborted. Initial
signatures MUST be hidden by being put deeply with protected kernel-
level processes, and the proof of work is REQUIRED to be signed with
Muhammad Expires 21 December 2026 [Page 11]
Internet-Draft Pure PQ Protocol June 2026
the initial signatures. ML-KEM-768 and HQC-256 keys should be
generated in specific ways such as:
* Being generated with random algerbraic calculations and separate
instructions that tell the keygen what to do. does not get
injected into the key itself. It is done every second after a new
key is generated for the next key to be generated and so on
* Being generated in ways that is private to both the client and
server
* Being generated and discarded at least 3 times. The final attempt
is where the final keys are generated and kept
If an attacker compromised a client's device and modified the keys so
that it matches the attacker's, then a new man in the middle is
discovered. To mitigate this, if the key does not match expected
form, was detected modified in the separate environment or was
generated by an external process, immediatly wipe the key and abandon
the connection. The client MUST generate it with an internal process
only. Software configurations should implement access control lists
and loggers that do not reveal any sensitive information. and logs
MUST be wiped after one month to ensure privacy of users. It is left
up for the host to keep logs for one month only or wipe it within any
given time provided it does not exceed one month. Sensitive data and
context MUST NOT be viewed by the client or server.
8. 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 * 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 pure
post-quantum algorithm suites, ensuring that extensions or
modifications to the baseline algorithm mix can be securely
negotiated.
9. References
9.1. Normative References
Muhammad Expires 21 December 2026 [Page 12]
Internet-Draft Pure PQ Protocol June 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
[RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37,
RFC 826, DOI 10.17487/RFC0826, November 1982,
<https://www.rfc-editor.org/info/rfc826>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2
(IKEv2) Message Fragmentation", RFC 7383,
DOI 10.17487/RFC7383, November 2014,
<https://www.rfc-editor.org/info/rfc7383>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
[RFC9438] Xu, L., Ha, S., Rhee, I., Goel, V., and L. Eggert, Ed.,
"CUBIC for Fast and Long-Distance Networks", RFC 9438,
DOI 10.17487/RFC9438, August 2023,
<https://www.rfc-editor.org/info/rfc9438>.
Muhammad Expires 21 December 2026 [Page 13]
Internet-Draft Pure PQ Protocol June 2026
[FIPS202] National Institute of Standards and Technology, "SHA-3
Standard: Permutation-Based Hash and Extendable-Output
Functions", FIPS PUB 202, August 2015.
[FIPS203] National Institute of Standards and Technology, "Module-
Lattice-Based Key-Encapsulation Mechanism Standard",
FIPS PUB 203, August 2024.
[FIPS204] National Institute of Standards and Technology, "Module-
Lattice-Based Digital Signature Standard", FIPS PUB 204,
August 2024.
[FIPS205] National Institute of Standards and Technology, "Stateless
Hash-Based Digital Signature Standard", FIPS 205.
[NIST-SP800-38D]
National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM)", NIST Special
Publication 800-38D, November 2007.
[NIST-SP800-90A]
National Institute of Standards and Technology,
"Recommendation for Random Number Generation Using
Deterministic Random Bit Generators", NIST Special
Publication 800-90A, June 2015.
9.2. Informative References
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
<https://www.rfc-editor.org/info/rfc4987>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
Muhammad Expires 21 December 2026 [Page 14]
Internet-Draft Pure PQ Protocol June 2026
[IEEE-802.1Q]
IEEE, "IEEE Standard for Local and metropolitan area
networks—Bridges and Bridged Networks", IEEE 802.1Q, July
2018.
[HQC-SPEC] Aguilar Melchor, C., Aragon, N., Bettaieb, S., Bidoux, L.,
Blazy, O., Deneuville, J. C., Gaborit, P., and E. Zémor,
"HQC (Hamming Quasi-Cyclic)", 6 June 2021, <https://pqc-
hqc.org/doc/hqc-specification_2021-06-06.pdf>.
Author's Address
Abdelaziz Muhammad
Cairo
Egypt
Email: abdoprofessional1011@gmail.com
Muhammad Expires 21 December 2026 [Page 15]