40. Cryptographic Primitives

40.1 Hash Functions

Hash functions in Kortana are strictly segmented by domain to prevent cross-protocol collision attacks and to optimize for specific performance characteristics.

• SHA-256 (OpenSSL/BoringSSL): The core engine of the Delegated Proof of History (dPOH). SHA-256 is specifically chosen because it provides a reliable verifiable delay function. It is strictly sequential and cannot be parallelized, meaning no attacker can compute the dPOH chain faster than honest generators simply by adding more cores. It is also used for verifying Merkle-Patricia Trie proofs.
• Keccak-256 (OpenSSL / ethash): The Ethereum standard hash, ensuring full EVM compatibility. It is used exclusively in the execution layer for deriving EVM (0x...) addresses, hashing transaction payloads prior to signing, calculating contract storage slots, and generating ABI function selectors.
• BLAKE3 (C SIMD): The primary internal hash for the Kortana node. Chosen for its extreme performance, BLAKE3 is used for hashing P2P networking frames, computing block hashes, state roots, and internal Merkle trees.

40.2 Signature Schemes

Kortana natively supports three distinct signature schemes, each tailored to its layer in the architecture.

• secp256k1 ECDSA (libsecp256k1): The standard elliptic curve for EVM compatibility. It is used to authenticate and sign all standard network transactions (EIP-155). The protocol strictly enforces EIP-2 (Low-S values) natively to prevent signature malleability attacks on the mempool.
• Ed25519: A high-performance, highly secure curve used natively by Kortana for generating ktn: addresses, CLI tooling, and staking operations. It is favored for native operations due to its resistance to side-channel attacks and faster verification speeds.
• BLS12-381 (Supranational blst): The backbone of the KSC BFT consensus layer. BLS signatures support mathematical aggregation. This allows 100 validator votes on a block to be aggregated into a single Quorum Certificate (QC) that is exactly the same byte size as a single vote. This ensures the block size remains constant regardless of the validator set size, preserving network bandwidth and liveness.

40.3 Encryption, Key Derivation & Encoding

• AES-128-CTR & AES-GCM (OpenSSL): AES-128-CTR is used for encrypting Keystore V3 files at rest. AES-GCM provides authenticated encryption for the mutual authentication (SIGMA) protocol on the P2P communication channels.
• scrypt (libscrypt): Used as the primary Key Derivation Function (KDF) to protect keystore files against brute-force attacks via memory hardness.
• Constant-Time Comparison (libsodium / sodium_memcmp): Used universally throughout the node for HMAC verification and comparing key material to eliminate timing side-channel attacks.
• RLP (Recursive Length Prefix): The strict encoding format used for serializing Blocks, Transactions, and State Trie nodes. RLP ensures that the byte layout is completely deterministic before any hashing occurs.