-
Notifications
You must be signed in to change notification settings - Fork 2
Codex Appendix VI
(Classical, Modern, Post-Quantum, and Key Agreement Distinction)
Art. 1º This Appendix establishes the normative framework for Asymmetric Encryption and Key Wrapping implemented in the EDGE Toolkit (edgetk), discerning between classical, modern, and post-quantum schemes, as well as between asymmetric encryption (direct confidentiality) and key agreement protocols (shared secret derivation).
§ 1º Asymmetric encryption is defined as the class of cryptographic mechanisms in which a message is encrypted using a recipient's public key and decrypted using the corresponding private key, providing confidentiality without a pre-shared secret.
§ 2º Key agreement is defined as the class of cryptographic protocols in which two or more parties derive a shared secret over an insecure channel, each contributing their own public-private key pair.
§ 3º Key wrapping is defined as the asymmetric encryption of symmetric cryptographic keys, enabling hybrid cryptographic systems as established in the General Codex, Art. 9º.
§ 4º This Appendix complies with the concepts, classifications, and objectives set forth in the General Codex of edgetk, particularly Chapter III, Sections II and III.
Art. 2º Asymmetric encryption and key agreement protocols serve different cryptographic purposes and shall not be used interchangeably.
§ 1º Asymmetric encryption (e.g., ElGamal, RSA-OAEP, Kyber, IBE) directly encrypts a message or symmetric key using a recipient's public key. The recipient alone can decrypt using the corresponding private key.
§ 2º Key agreement (e.g., ECDH, X25519, X448, VKO) derives a shared secret between two or more parties. The shared secret is then processed through a Key Derivation Function (KDF) to produce cryptographic keys.
§ 3º The essential distinction is summarized as follows:
| Criterion | Asymmetric Encryption | Key Agreement |
|---|---|---|
| Direction | One-way (sender to recipient) | Two-way (mutual) |
| Input | Recipient's public key | Both parties' key pairs |
| Output | Ciphertext (contains the message) | Shared secret (requires KDF) |
| Non-repudiation | No | No |
| Typical use | Encrypting symmetric keys, email encryption | TLS, VPN, messaging protocols |
Art. 3º Classical asymmetric encryption schemes are based on the hardness of the integer factorization problem (RSA) or the discrete logarithm problem in multiplicative groups of finite fields (ElGamal).
§ 1º Classical asymmetric encryption is characterized by:
- reliance on mathematical problems not known to be quantum-resistant;
- larger ciphertext sizes compared to modern elliptic curve variants;
- historical significance as the first practical public-key encryption schemes.
§ 2º RSA (Rivest–Shamir–Adleman, 1978) is a classical asymmetric encryption scheme based on the hardness of integer factorization. RSA is deprecated in edgetk for new deployments, except for legacy compatibility. Minimum parameters: 2048-bit modulus; 3072-bit or 4096-bit recommended for new deployments when legacy compatibility is required.
§ 3º ElGamal encryption (Tahir ElGamal, 1985) is a classical asymmetric encryption scheme based on the Diffie-Hellman framework. ElGamal is deprecated in edgetk for new deployments, except for legacy compatibility. Minimum parameters: 2048-bit prime modulus with a 256-bit subgroup.
Art. 4º Modern asymmetric encryption schemes are based on elliptic curve cryptography (ECC), offering smaller key sizes, faster operations, and stronger security per bit compared to classical schemes.
§ 1º EC-ElGamal (Elliptic Curve ElGamal) is the elliptic curve variant of ElGamal encryption. EC-ElGamal is deprecated in edgetk for general-purpose use, as direct encryption on elliptic curves is less common than hybrid encryption via ECDH + KDF + AEAD.
§ 2º SM2 Asymmetric Encryption is a public-key encryption scheme standardized by the Chinese government (GM/T 0003-2012), based on elliptic curve cryptography. SM2 encryption is a modern asymmetric encryption scheme that uses the same elliptic curve domain parameters as SM2 digital signatures. SM2 is approved for deployments requiring compliance with Chinese cryptographic standards, using the SM3 hash function and recommended curves such as sm2p256v1.
Art. 5º Key agreement protocols are asymmetric mechanisms in which two or more parties derive a shared secret over an insecure channel, without directly encrypting messages.
§ 1º Key agreement differs from asymmetric encryption in that:
- no message is directly encrypted; the output is a shared secret, not a ciphertext containing a message;
- both parties actively participate in the protocol;
- the resulting shared secret must be processed through a KDF before use in symmetric encryption.
§ 2º Key agreement protocols are the foundation of modern secure communication, including TLS, Signal, WhatsApp, and SSH.
Art. 6º The following key agreement schemes are approved for use in edgetk.
- ECDH (Elliptic Curve Diffie-Hellman): based on the elliptic curve discrete logarithm problem; approved with curves P-256, P-384, and others as specified in edgetk elliptic curve policy;
- X25519: optimized ECDH based on Curve25519; provides 128-bit security; approved as the default key agreement mechanism in edgetk;
- X448: optimized ECDH based on Curve448; provides 224-bit security; approved for high-security applications requiring stronger security than X25519;
- VKO (Vyrabotka Klyucha Obshchego): Russian standardized key agreement protocol defined in GOST R 34.10-2012; approved exclusively for deployments requiring compliance with Russian cryptographic standards.
Art. 7º Identity-Based Encryption (IBE) is a form of asymmetric encryption in which the sender encrypts a message using only the recipient's identity string (e.g., email address, username), without requiring advance distribution of the recipient's public key or certificate.
§ 1º In IBE systems, decryption is performed by the recipient using a private key derived from the same identity by a trusted Private Key Generator (PKG), as established in Appendix II.
§ 2º Unlike traditional asymmetric encryption, IBE eliminates the need for public key directories and certificate authorities.
§ 3º IBE schemes are classified as stochastic (randomized) encryption schemes, as encryption incorporates randomness to achieve semantic security.
§ 4º All approved IBE schemes, in their basic form, achieve IND-ID-CPA (chosen plaintext security). To achieve IND-ID-CCA2 (chosen ciphertext security), the Fujisaki-Okamoto (FO) transformation shall be applied, as it converts a passively secure encryption scheme into an actively secure one in the random oracle model. The FO transformation is particularly suitable for IBE schemes due to their probabilistic encryption nature and the ability to re-encrypt during decryption for verification.
Art. 8º The following Identity-Based Encryption schemes are approved for use in edgetk.
- Boneh–Franklin IBE (Dan Boneh and Matt Franklin, 2001): the first practical IBE scheme, based on bilinear pairings; proven secure in the random oracle model under the Bilinear Diffie-Hellman (BDH) assumption; approved for general-purpose IBE deployments;
- Boneh–Boyen IBE (Dan Boneh and Xavier Boyen, 2004): an IBE scheme proven secure in the standard model (without random oracles) under the Decisional Bilinear Diffie-Hellman (DBDH) assumption; approved for applications requiring security in the standard model;
- Sakai–Kasahara IBE (Ryuichi Sakai and Masao Kasahara, 2003): an efficient IBE scheme based on bilinear pairings, known for its simplicity and performance; approved for performance-critical IBE deployments and when combined with other IBS;
- SM9 (Chinese National Standard GM/T 0044-2016): an Identity-Based Cryptographic standard established by the Chinese government, covering both encryption and signatures; based on bilinear pairings; approved for deployments requiring compliance with Chinese IBE standards, using the SM3 hash function.
Art. 9º Post-quantum asymmetric encryption and key wrapping are achieved through Key Encapsulation Mechanisms (KEMs) designed to resist attacks from quantum computers.
§ 1º Unlike traditional asymmetric encryption, KEMs are designed to encapsulate a random symmetric key, which is then used with a symmetric AEAD cipher for bulk encryption.
§ 2º KEMs provide the same functionality as asymmetric encryption for hybrid systems but are structured differently: encapsulation produces a ciphertext and a shared secret; decapsulation recovers the shared secret from the ciphertext.
Art. 10º ML-KEM (formerly Kyber) is the primary post-quantum key encapsulation mechanism standardized by NIST (FIPS 203), based on the hardness of the Module Learning with Errors (MLWE) problem.
§ 1º ML-KEM provides the following properties:
- post-quantum security based on lattice problems believed hard even for quantum computers;
- compact ciphertexts (approximately 768 to 1568 bytes depending on security level);
- fast encapsulation and decapsulation, suitable for high-performance applications;
- IND-CCA2 security (secure against adaptive chosen ciphertext attacks).
§ 2º ML-KEM is available in three parameter sets:
- ML-KEM-512: 128-bit security level;
- ML-KEM-768: 192-bit security level (recommended default);
- ML-KEM-1024: 256-bit security level.
§ 3º ML-KEM is approved as the default post-quantum key encapsulation mechanism in edgetk.
Art. 11º For the transition period to post-quantum cryptography, edgetk shall support hybrid key establishment combining classical key agreement with ML-KEM.
§ 1º A hybrid KEM combines the output of a classical key agreement (e.g., X25519) and a post-quantum KEM (e.g., ML-KEM) to produce a single shared secret.
§ 2º Hybrid KEMs provide:
- security that is at least as strong as the strongest component scheme;
- backward compatibility with systems not yet upgraded to post-quantum;
- defense-in-depth against unforeseen cryptanalysis of either component.
§ 3º The approved hybrid combinations include:
- X25519 + ML-KEM-768 (default hybrid);
- X448 + ML-KEM-1024 (high-security hybrid);
- ECDH (P-256) + ML-KEM-768 (legacy compatibility).
§ 4º Hybrid shared secrets shall be combined using a KDF (e.g., HKDF) with domain separation.
Art. 12º The selection of the appropriate asymmetric encryption or key agreement mechanism in edgetk shall follow these normative guidelines.
§ 1º For direct asymmetric encryption (deprecated) :
- do not use ElGamal or EC-ElGamal for new deployments;
- prefer hybrid encryption: key agreement (X25519) + KDF + AEAD.
§ 2º For key agreement (default) :
- use X25519 as the default key agreement mechanism;
- use X448 for high-security applications (224-bit security);
- use VKO only for GOST compliance.
§ 3º For Identity-Based Encryption :
- use Boneh–Franklin for general-purpose IBE deployments where random oracle security is acceptable;
- use Boneh–Boyen when security in the standard model (without random oracles) is required;
- use Sakai–Kasahara for performance-critical deployments and when combined with other IBS;
- use SM9 exclusively for deployments requiring compliance with Chinese cryptographic standards.
§ 4º For post-quantum readiness :
- use ML-KEM-768 as the default post-quantum KEM;
- use hybrid X25519 + ML-KEM-768 when transition risk mitigation is required;
- use ML-KEM-1024 for high-security post-quantum deployments.
Art. 13º The secure operation of asymmetric encryption and key agreement within edgetk depends on the following mandatory requirements.
§ 1º For all schemes:
- key pairs shall be generated using a cryptographically secure random number generator;
- private keys shall be stored in secure storage with appropriate access controls;
- shared secrets shall always be processed through a KDF before use as symmetric keys.
§ 2º For key agreement:
- ephemeral key pairs shall be generated for each session (forward secrecy);
- static key pairs may be used only when authenticated and combined with ephemeral keys.
§ 3º For IBE:
- the PKG master secret key shall be protected with the same security level as established in Appendix II;
- bilinear pairing implementations shall use constant-time operations to mitigate side-channel attacks;
- identity strings shall be canonicalized before hashing to prevent equivalence attacks.
§ 4º For ML-KEM:
- implementations shall use the parameter sets and domain separation as specified in FIPS 203;
- hybrid KEMs shall combine outputs using a KDF, not simple concatenation.
Art. 14º The following asymmetric encryption and key agreement schemes are expressly prohibited or deprecated in edgetk.
§ 1º Prohibited schemes:
- RSA with keys smaller than 2048 bits (for encryption);
- ElGamal with keys smaller than 2048 bits;
- EC-ElGamal without proper point validation;
- any scheme using MD5 or SHA-1 as the underlying hash function.
§ 2º Deprecated schemes (allowed only for legacy compatibility):
- classical ElGamal encryption (prefer X25519 + KDF + AEAD);
- EC-ElGamal (prefer X25519 + KDF + AEAD);
- ECDH with curves other than P-256, P-384, or approved Brainpool curves.
Art. 15º This Appendix may be extended to include additional asymmetric encryption schemes, key agreement protocols, IBE schemes, or post-quantum KEMs, provided they conform to the classification framework established in this Appendix and the General Codex.
§ 1º Future extensions may include schemes such as Classic McEliece (code-based KEM), BIKE, and additional NIST PQC KEM candidates.
§ 2º Any proposed addition shall demonstrate resistance to known cryptanalytic attacks and provide clear security, performance, and implementation trade-offs.
Art. 16º This Appendix enters into force upon its publication as part of the EDGE Toolkit Normative Codex.