Codex Appendix III

EDGE Toolkit: Normative

APPENDIX III – BULK ENCRYPTION

(Block Ciphers, Stream Ciphers, and AEAD Modes)

CHAPTER I — GENERAL PROVISIONS

Art. 1º This Appendix establishes the normative framework for Bulk Encryption implemented in the EDGE Toolkit (edgetk), discerning between block ciphers and stream ciphers, and defining the approved Authenticated Encryption with Associated Data (AEAD) modes for each category.

§ 1º Bulk Encryption is defined as the class of symmetric cryptographic mechanisms in which ciphertext may be reverted to plaintext using the same secret key, primarily used for the protection of large volumes of data.

§ 2º Bulk encryption mechanisms are organized into two fundamental categories:

1. block ciphers, which process data in fixed-size chunks;
2. stream ciphers, which process data continuously, bit by bit or byte by byte.

§ 3º This Appendix complies with the concepts, classifications, and objectives set forth in the General Codex of edgetk, particularly Chapter II, Section I on Bulk Encryption.

---

CHAPTER II — FUNDAMENTAL DISTINCTION

Art. 2º The fundamental distinction between block ciphers and stream ciphers lies in how plaintext is transformed into ciphertext.

§ 1º A block cipher breaks plaintext messages into fixed-size blocks before converting them into ciphertext using a secret key. Each block is processed independently or in relation to previous blocks, depending on the mode of operation.

§ 2º A stream cipher breaks plaintext messages into individual bits or bytes, which are then converted into ciphertext by combining each unit with a pseudorandom keystream, typically using the XOR operation.

§ 3º To illustrate the distinction: encrypting a book one page at a time corresponds to a block cipher, whereas encrypting it one letter at a time corresponds to a stream cipher.

§ 4º Block ciphers mix plaintext bits together with key bits to produce ciphertext chunks of the same size, typically 128 bits. Stream ciphers, in contrast, generate pseudorandom bits from the key and encrypt the plaintext by combining it with those pseudorandom bits without mixing plaintext and key bits in reverse direction.

---

CHAPTER III — BLOCK CIPHERS

Art. 3º A block cipher is a symmetric cryptographic primitive that encrypts plaintext in fixed-size blocks, producing ciphertext blocks of identical size.

§ 1º The block cipher implemented in edgetk shall operate on blocks of 128 bits.

§ 2º Block ciphers are deterministic: the same plaintext block, encrypted with the same key, always produces the same ciphertext block. This property necessitates careful selection of modes of operation to ensure semantic security.

§ 3º Block ciphers form the backbone of many cryptographic technologies in widespread use today, including network security protocols, disk encryption, and file protection systems.

---

SECTION I — BLOCK CIPHER MODES OF OPERATION

Art. 4º A mode of operation is an algorithm that describes how to repeatedly apply a block cipher's single-block encryption operation to transform plaintext longer than a single block.

§ 1º Modes of operation are classified into the following categories:

1. unauthenticated modes, which provide only confidentiality;
2. authenticated modes (AEAD), which provide confidentiality, integrity, and authenticity simultaneously.

§ 2º The edgetk shall NOT implement unauthenticated modes (ECB, CBC, CFB, OFB, CTR) without an accompanying integrity mechanism, as they are vulnerable to various attacks including padding oracles, bit-flipping, and block rearrangement.

§ 3º All block cipher usage in edgetk shall employ an approved AEAD mode as defined in Chapter V of this Appendix.

---

SUBSECTION I — DIFFERENCES BETWEEN BLOCK CIPHER MODES

Art. 5º The following distinctions among block cipher modes of operation are normative for the correct selection and implementation in edgetk.

§ 1º Electronic Codebook (ECB) – PROHIBITED:

1. each plaintext block is encrypted independently with the same key;
2. identical plaintext blocks produce identical ciphertext blocks, revealing patterns;
3. ECB shall not be used under any circumstance in edgetk.

§ 2º Cipher Block Chaining (CBC) – DEPRECATED:

1. each plaintext block is XORed with the previous ciphertext block before encryption;
2. requires an initialization vector (IV) that must be unpredictable;
3. provides only confidentiality and is vulnerable to padding oracle attacks;
4. CBC shall only be used for compatibility with legacy systems and must be combined with a separate HMAC for integrity.

§ 3º Counter Mode (CTR) – APPROVED FOR AEAD COMBINATIONS:

1. converts a block cipher into a stream cipher by encrypting successive counter values;
2. the ciphertext is produced by XORing plaintext with the resulting keystream;
3. provides only confidentiality but enables parallel encryption and decryption;
4. CTR is approved only when combined with an authentication mechanism as part of an AEAD mode such as GCM.

§ 4º Galois/Counter Mode (GCM) – APPROVED:

1. combines CTR mode for confidentiality with Galois Message Authentication Code (GMAC) for integrity and authenticity;
2. supports associated data that is authenticated but not encrypted;
3. requires unique IVs for each encryption operation with the same key;
4. GCM is approved for high-performance applications requiring parallelizable authentication.

§ 5º The essential difference among modes reduces to:

1. whether the mode provides authentication (ECB, CBC, CTR do not; GCM, CCM, MGM do);
2. whether encryption can be parallelized (ECB, CTR, GCM can; CBC cannot);
3. whether the mode is vulnerable to padding attacks (CBC is; CTR-based modes are not);
4. whether the mode requires nonce uniqueness (GCM, CCM, MGM do; ECB does not, but is insecure).

---

CHAPTER IV — STREAM CIPHERS

Art. 6º A stream cipher is a symmetric cryptographic primitive that encrypts plaintext continuously, bit by bit or byte by byte, by combining the plaintext with a pseudorandom keystream.

§ 1º Unlike block ciphers, stream ciphers do not mix plaintext and key bits. Instead, they generate a pseudorandom keystream from the secret key and combine it with the plaintext, typically using the XOR operation.

§ 2º Stream ciphers are characterized by:

1. no need for padding, as they operate on data of any length;
2. low latency, as each bit or byte can be encrypted as it arrives;
3. simplicity of implementation in hardware and software.

§ 3º Stream ciphers are particularly suitable for:

1. real-time communications where low latency is critical;
2. environments with limited memory or processing resources;
3. encryption of continuous data streams such as network traffic or audio/video streams.

§ 4º A critical requirement for all stream ciphers is that the same keystream shall never be reused for two different plaintexts. Each encryption operation requires a unique nonce or initialization vector.

---

CHAPTER V — APPROVED AEAD MODES FOR BULK ENCRYPTION

Art. 7º The edgetk shall implement Authenticated Encryption with Associated Data (AEAD) for all bulk encryption operations. AEAD provides confidentiality, integrity, and authenticity in a single integrated mechanism.

§ 1º The following AEAD constructions are approved for use in edgetk, covering both block cipher-based and stream cipher-based designs:

1. AES-GCM: an AEAD mode based on the Advanced Encryption Standard (AES) block cipher operating in Galois/Counter Mode. It combines AES in CTR mode for confidentiality with GMAC for integrity. AES-GCM offers high performance on hardware with AES and carryless multiplication instructions, supports parallelizable encryption and authentication, and requires unique IVs for each encryption operation with the same key. Keys shall be rotated after a maximum of 2³² encryptions.
2. ChaCha20-Poly1305: an AEAD construction combining the ChaCha20 stream cipher with the Poly1305 message authentication code. ChaCha20 generates a pseudorandom keystream using a 256-bit key and a 96-bit nonce. This mode offers high performance in software without special hardware instructions, resists timing side-channel attacks due to its use of only additions, rotations, and XOR operations, and requires unique nonces for each encryption operation.
3. Ascon: a family of lightweight authenticated encryption algorithms based on the sponge construction. Ascon is characterized by low memory footprint requiring minimal RAM and ROM, high performance on resource-constrained devices including microcontrollers and embedded systems, and resistance to side-channel attacks. Ascon was selected as the standard for lightweight cryptography by the National Institute of Standards and Technology (NIST) and is approved for use in edgetk for resource-constrained environments where AES-GCM or ChaCha20-Poly1305 may be impractical.
4. Kuznechik-MGM: an AEAD mode combining the Kuznechik block cipher (GOST R 34.12-2015) with the Multilinear Galois Mode (MGM) of operation. Kuznechik is a 128-bit block cipher defined by the Russian federal standard. MGM is an authenticated encryption mode based on counter mode with a polynomial hash function similar to GCM. This mode offers parallelizable encryption and decryption, support for associated data, and compliance with Russian cryptographic standards. Kuznechik-MGM is approved for use in edgetk exclusively for deployments requiring compliance with GOST standards.
5. SM4: a 128-bit block cipher standardized by the Chinese government (GB/T 32907-2016). When used in an AEAD mode such as GCM or CCM, SM4 provides authenticated encryption for deployments requiring compliance with Chinese cryptographic standards. SM4 is approved for use in edgetk with approved AEAD modes, using the SM3 hash function for key derivation when applicable.
6. Curupira-LETTERSOUP: an AEAD construction based on the Curupira block cipher operating in LETTERSOUP mode. Curupira is a Brazilian block cipher designed for flexible and secure bulk encryption. LETTERSOUP is an authenticated encryption mode that provides confidentiality, integrity, and authenticity in a single integrated mechanism. This construction is approved for general-purpose bulk encryption in edgetk, particularly for deployments requiring compliance with Brazilian cryptographic standards.

§ 2º All approved AEAD modes require unique nonces or initialization vectors for each encryption operation performed with the same key. Reuse of nonces compromises security across all modes.

---

CHAPTER VI — COMPARATIVE GUIDELINES

Art. 8º The selection of the appropriate bulk encryption mechanism in edgetk shall follow these normative guidelines.

§ 1º Block cipher vs. stream cipher selection:

1. use block cipher-based AEAD (AES-GCM, Kuznechik-MGM, SM4-AEAD, Curupira-LETTERSOUP) when hardware acceleration is available and maximum performance is required;
2. use stream cipher-based AEAD (ChaCha20-Poly1305) for software implementations without hardware acceleration or when resistance to timing attacks is critical;
3. use lightweight AEAD (Ascon or Curupira-LETTERSOUP) for resource-constrained embedded devices;
4. use Kuznechik-MGM only when regulatory compliance with Russian standards is mandatory;
5. use SM4 only when regulatory compliance with Chinese standards is required;

§ 2º Performance characteristics summary:

1. AES-GCM: fastest on hardware with AES-NI and CLMUL instructions;
2. ChaCha20-Poly1305: fastest in software on general-purpose CPUs;
3. Ascon: lowest memory footprint and suitable for 8-bit and 16-bit microcontrollers;
4. Kuznechik-MGM: comparable performance to AES-GCM on hardware supporting the Kuznechik cipher;
5. SM4: comparable performance to AES on hardware supporting SM4 instructions;

§ 3º Security characteristics summary:

1. all six approved AEAD modes provide strong confidentiality, integrity, and authenticity when used correctly;
2. all six require unique nonces per encryption operation with the same key;
3. none of the approved modes are known to be vulnerable to practical cryptanalytic attacks when properly implemented.

---

CHAPTER VII — PROHIBITED AND DEPRECATED MECHANISMS

Art. 9º The following bulk encryption mechanisms are expressly prohibited or deprecated in edgetk.

§ 1º Prohibited mechanisms:

1. ECB mode (Electronic Codebook) for any purpose;
2. RC4 stream cipher;
3. any unauthenticated mode used without a separate integrity mechanism.

§ 2º Deprecated mechanisms (allowed only for legacy compatibility):

1. CBC mode without explicit HMAC;
2. CTR mode without explicit HMAC;
3. any cipher using less than 128-bit keys.

---

CHAPTER VIII — FINAL PROVISIONS

Art. 10º This Appendix may be extended to include additional AEAD modes, block ciphers, or stream ciphers, provided they conform to the classification framework established in this Appendix and the General Codex.

§ 1º Future extensions may include modes such as CCM, OCB, or XChaCha20-Poly1305.

§ 2º Any proposed addition shall demonstrate resistance to known cryptanalytic attacks and provide clear performance and security trade-offs.

Art. 11º This Appendix enters into force upon its publication as part of the EDGE Toolkit Normative Codex.