Annex 2 — Algorithm Requirements

Annex 2 — Algorithm Requirements#

A2.0. Purpose#

This annex defines the specific cryptographic algorithms permitted for use in systems certified to the CCSA Standard. Structure: 3 tiers (Global, Russian, Quantum-readiness), TLS configuration, recommended libraries and HSM products, the algorithm deprecation process, and an audit checklist.

Normative bases:

• NIST SP 800-57 Rev. 5 (Key Management Lifecycle)
• FIPS 186-5 (ECDSA, EdDSA)
• FIPS 202 (SHA-3 family)
• NIST SP 800-132 (PBKDF)
• OWASP Password Storage Cheat Sheet (2024)
• GOST R 34.10-2018, 34.11-2018, 34.12-2018, 34.13-2018 (for Russian clients)
• NIST PQC Standardization (ML-KEM, ML-DSA finalization August 2024)

CCSA does not duplicate the requirements of these documents but specifies and strengthens them for the crypto-custody context.

A2.1. Global Tier (international algorithms)#

Asymmetric Signing#

Permitted:

• ECDSA secp256k1 (Bitcoin, Ethereum legacy) — 256-bit strength equivalent
• ECDSA P-256, P-384 (NIST curves) — 128-bit, 192-bit strength
• Ed25519 (EdDSA) — 128-bit strength; Solana and many modern blockchains
• BLS12-381 (Ethereum 2.0 consensus, Filecoin) — 128-bit strength
• RSA — with level-based requirements:
  • L1, L2: RSA-3072+ permitted for legacy compatibility
  • L3: RSA-3072 deprecated as of 1 January 2028; RSA-4096+ mandatory for new key generation after this date
  • All levels: RSA < 2048 bit prohibited

Prohibited:

• ECDSA with k-reuse (a known critical vulnerability, leaks the private key)
• DSA (deprecated, NIST SP 800-131A Rev. 2)
• RSA < 2048 bit in production
• ECDSA on obsolete curves (secp192k1 and lower)

Hashing#

Permitted:

• SHA-256, SHA-384, SHA-512 (NIST SHA-2 family; FIPS 180-4)
• SHA-3 family — Keccak-256, Keccak-512 (FIPS 202; Ethereum native; Solana)
• BLAKE2b, BLAKE3 (RFC 7693) — for performance-critical paths

Prohibited for security-critical operations:

• MD5 (broken; RFC 6151)
• SHA-1 (collisions demonstrated; deprecated per NIST SP 800-131A Rev. 2)
• RIPEMD-160 (legacy; permitted only for backward compatibility with Bitcoin witness scripts)

Symmetric Encryption#

Permitted AEAD ciphers (recommended for all new deployments):

• AES-256-GCM (primary AEAD cipher)
• AES-256-GCM-SIV (for scenarios with a risk of nonce reuse)
• ChaCha20-Poly1305 (mobile, performance-critical)

Permitted non-AEAD only with a separate MAC:

• AES-256-CTR + HMAC-SHA-256 in an encrypt-then-MAC construction

Prohibited:

• DES, 3DES (deprecated)
• RC4, RC5, RC6 (broken / superseded)
• AES in ECB and CBC modes without a separate MAC
• AES-128 for long-term protected data (acceptable for session-scoped ephemeral data)

Key Derivation#

Permitted KDFs:

• Argon2id (preferred for new deployments) — minimum parameters m ≥ 19 MiB, t ≥ 2, p = 1 (OWASP Password Storage Cheat Sheet, 2024)
• PBKDF2 — minimum 600,000 iterations with SHA-256 (OWASP 2024 recommendation); SHA-512 recommended for new deployments
• scrypt — minimum N = 2^17, r = 8, p = 1 (equivalent to approx. 128-bit work factor)
• HKDF (NIST SP 800-56C Rev. 2) — for key derivation in protocols, not for password hashing

Prohibited:

• Plain hash (SHA-256 without a KDF iteration count) for password storage
• PBKDF2 < 100,000 iterations in production (legacy systems with < 100K iterations must be migrated)
• Argon2 with parameters m < 19 MiB or t < 2 (insufficient work factor)

Random Number Generation#

Permitted entropy sources:

• Hardware True Random Number Generator (TRNG), certified to FIPS 140-3 Level 3+
• Deterministic Random Bit Generator (DRBG) conforming to NIST SP 800-90A with seeding per SP 800-90B/C
• HSM internal RNG with a valid FIPS certificate
• Apple Secure Enclave RNG (Apple Silicon, A14+) and Android Hardware-backed Keystore RNG (StrongBox)
• /dev/urandom on modern Linux kernels (5.18+) for server-side operations (see the note on initial entropy in Section B.2.1)

Prohibited sources for production CCM:

• Math.random() in JavaScript, the random module in Python without secrets, Random in Java without SecureRandom
• User-supplied entropy without augmentation by a cryptographic source
• Time-based seeds
• Pseudo-random without cryptographic seeding

A2.2. Russian Tier (Russian algorithms)#

Asymmetric Signing#

Permitted:

• GOST R 34.10-2018 (electronic signature on elliptic curves)

Application: mandatory for documents related to Russian DFAs (digital financial assets); for operations with the digital ruble; recommended for Russian clients in addition to the Global tier.

Hashing#

Permitted:

• GOST R 34.11-2018 (Streebog)

Application: mandatory when GOST R 34.10-2018 is used.

Symmetric Encryption#

Permitted:

• GOST R 34.12-2018 — Kuznyechik (128-bit block)
• GOST R 34.12-2018 — Magma (64-bit block, legacy compatibility only)

Modes (GOST R 34.13-2018):

• CTR (counter mode)
• CBC-IM (CBC with MAC)
• MGM (Multilinear Galois Mode — an AEAD analog of GCM, recommended for CCM on GOST)

Cryptographic Information Protection Tools (СКЗИ) certification#

СКЗИ classes (per the FSB of Russia):

Certified products (examples, not an exhaustive list):

• KriptoPro CSP — КС1, КС2, КС3
• ViPNet CSP — КС1, КС2, КС3
• Signal-COM CSP — КС1, КС2
• Kontinent-AP — for VPN
• APKSh Kontinent — for encryption

The full СКЗИ registry is available on the official website of the FSB of Russia (https://clsz.fsb.ru/clsz/).

A2.3. Quantum-Readiness Tier (advisory in v1.0, mandatory for L3 in v2.0)#

Goal#

Preparation for post-quantum cryptography. In v1.0 — advisory (recommended); in v2.0 (2029) — mandatory for Level 3.

Permitted post-quantum algorithms (NIST PQC Standardization, finalization 2024)#

Asymmetric Key Encapsulation Mechanism (KEM):

• ML-KEM (formerly CRYSTALS-Kyber) — NIST FIPS 203 (Kyber-512, Kyber-768, Kyber-1024)

Digital Signatures:

• ML-DSA (formerly CRYSTALS-Dilithium) — NIST FIPS 204
• SLH-DSA (formerly SPHINCS+) — NIST FIPS 205, stateless hash-based, proven security
• Falcon (compact signatures, in the standardization process in 2025)

Hybrid schemes (recommended for the transitional period):

• ECDSA + ML-DSA dual-signing for critical operations
• ECDH + ML-KEM hybrid for TLS key exchange

Migration Roadmap#

Phase 1 — Inventory & Assessment (2026–2027):

• Identify all cryptographic operations storing long-term secrets
• Classify by "harvest now, decrypt later" (HNL) risk
• Prioritize: signing keys > encryption keys > session keys

Phase 2 — Hybrid Deployments (2027–2028):

• Critical paths: implement dual-signing (ECDSA + ML-DSA hybrid)
• New key generation: create hybrid keypairs
• TLS 1.3 + hybrid KEM support for backend communications

Phase 3 — Compliance Assessment (2028–2029):

• Level 3 organizations: submit a hybrid PQC roadmap to the Council as an assessment-stage submission (not enforcement); the Council collects roadmaps to evaluate market readiness for v2.0
• Level 2: advisory status; the SAQ includes quantum questions
• Level 1: no quantum requirement

Phase 4 — Pure PQC (2029–2030, mandatory for L3 in v2.0):

• Legacy crypto gradually phased out for new systems
• Mandatory for L3 for any system storing keys longer than 10 years

A2.4. TLS Configuration#

For off-chain communications (API, web interfaces):

TLS Version Support#

Permitted:

• TLS 1.3 (mandatory for new deployments)
• TLS 1.2 — permitted within a temporary window relative to the v1.0 effective date (1 December 2026):
  • Until 2027-12-01 (12 months of overlap after the v1.0 effective date): allowed for L1 and L2 without explicit deprecation
  • From 2027-12-01: TLS 1.2 deprecated; TLS 1.3 mandatory for all levels
  • From 2028-06-01: TLS 1.2 prohibited for new deployments (only for existing systems via a Compensating Control with a migration plan)

Prohibited:

• TLS 1.1 and lower
• SSLv2, SSLv3

Cipher Suites#

TLS 1.3 cipher suites:

• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_GCM_SHA256 (only for session-scoped data, not for CCM long-term)

TLS 1.2 cipher suites (transitional period):

• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-ECDSA-CHACHA20-POLY1305
• ECDHE-RSA-CHACHA20-POLY1305

Certificate Requirements#

• Public certificates from trusted Certificate Authorities (Let's Encrypt, DigiCert, Sectigo, GlobalSign and equivalents; for Russian clients — Russian CAs are permitted)
• ECDSA or RSA-3072+ (RSA-4096 for L3 after 1 January 2028 per A2.1)
• HSTS mandatory for web interfaces with a minimum max-age of 31536000 (1 year) and includeSubDomains for L2+

Certificate Pinning#

Recommended for backend-to-backend communications with critical dependencies:

• TLS certificate pinning is recommended for critical backend-to-HSM and backend-to-blockchain node communications
• For public-facing APIs: standard CA chain validation is sufficient
• Pinning implementation: dynamic pinning per OWASP guidelines with a rotation strategy and a minimum 90-day pin backup validity

A2.5. Algorithm Compliance Mapping#

A2.6. Algorithm Deprecation Process#

The Council maintains a structured process for deprecating algorithms upon discovery of vulnerabilities or quantum readiness milestones.

A2.6.1. Deprecation Categories#

A2.6.2. Notification and Implementation Process#

• The Council issues a Security Advisory (public) at least 180 days before enforcement
• CCSAC training within 60 days of the advisory
• Assessment for the transition begins at the Assessed Entity's next re-assessment
• Violations flagged in AOC status updates

A2.6.3. Emergency Deprecation#

Upon discovery of a critical CVE (for example, a demonstrated practical key recovery attack for a widely used algorithm):

1. Immediate Security Advisory issued
2. The algorithm is marked Deprecated for the current CCSA version
3. At the next standard release it moves to Prohibited if there is no mitigation
4. Organizations have 12 months for remediation or loss of certification

A2.7. Recommended Cryptographic Libraries and HSM Products#

Open-source crypto libraries#

• libsodium (proven, well-audited)
• Bouncy Castle (Java, C#)
• OpenSSL 3.0+ with the FIPS module enabled
• Ring (Rust, high-assurance)
• Google Tink (multi-language, high-level API)

Hardware Security Modules#

• Level 1 / Level 2: Thales Luna Network HSM, Gemalto SafeNet, AWS CloudHSM (FIPS 140-2 Level 3)
• Level 3: Securosys Primus HSM, YubiHSM 2, Utimaco SecurityServer (FIPS 140-3 Level 3+)
• Blockchain-specific: Ledger Secure Element, Nitrokey HSM, Coldcard Mk4

Known Vulnerable / Deprecated Libraries#

• OpenSSL < 3.0 (deprecated; use 3.x with the FIPS module)
• Old versions of cryptojs (known weak RNG implementations)
• Custom crypto implementations without third-party audit — prohibited for production CCM

A2.8. Auditor's Cryptography Review Checklist#

During an audit, the CCSA-QSA performs the following checklist for each CCM-related cryptographic operation:

• Cryptographic inventory completed — all operations documented (linked to the CCM Inventory, Section B.1.1)
• Version audit — no deprecated or end-of-life libraries in production paths
• Configuration review — TLS cipher suites hardened, KDF parameters meet requirements, RNG configured correctly
• Random source verification — a FIPS-certified TRNG / DRBG or /dev/urandom on a supported kernel is used; no fallback to weak RNG
• Key storage verified — CCM isolated (HSM partition, secure enclave, MPC envelope); no cleartext exposure in logs or memory dumps
• Key rotation schedule — documented and tested (Section B.5.1)
• Side-channel risk assessment (for Level 3) — timing attacks, power analysis mitigations
• Documentation completeness — algorithms, key sizes, rotation cadence, and disposal procedures explicitly stated for each CCM category
• Compatibility tier (if applicable) — Russian tier for Russian clients checked for valid СКЗИ certificates

A2.9. Quantum Risk Assessment Framework (Mandatory for L3 in v2.0, 2029)#

For L3 organizations in v2.0, an annual Quantum Risk Assessment is mandatory. In v1.0 — advisory; in v1.1 — encouraged; full enforcement — from v2.0 (Phase 4, 2029).

• Cryptographic asset lifetime analysis — for each CCM category, an assessment of expected useful life
• HNL (Harvest Now, Decrypt Later) risk classification — if a key protects data that must remain confidential > 10 years, classify it HIGH risk
• Migration roadmap — submission to the Council by 2028–2029 as assessment-stage (Phase 3); full enforcement from v2.0 (Phase 4)
• Hybrid deployment status — a report on the progress of hybrid PQC deployment in critical paths

Related#

• 13 — Annex 1 — Glossary — previous
• 15 — Annex 3 — ROC Reporting Template — next
• 04 — B.2 — Generation of Cryptographic Material — algorithm application in B.2
• 05 — B.3 — Storage of Cryptographic Material — algorithm application in B.3

Sources#

See Section 0.4 Normative References in the Front Matter.

Additional sources:

• NIST PQC Standardization (FIPS 203, 204, 205 — finalized 2024)
• OWASP Cryptographic Storage Cheat Sheet (2024)
• OWASP Password Storage Cheat Sheet (2024)
• FSB of Russia — СКЗИ registry (https://clsz.fsb.ru/clsz/)