NTP-3: Cryptography and Hash Specification

Status: PUBLISHED
Authors: Danthur Lice
Date of Creation: 2025-01-09
Date of Publication: 2025-01-15
License: NCL-11

1. Scope

This document establishes the mandatory cryptographic and hashing standards applicable throughout the Norsh ecosystem. It ensures uniformity, auditability, and technical integrity for all security-related operations. These standards apply to all environments and entities interacting with the platform, including nodes, services, APIs, and clients, regardless of implementation language or jurisdiction.

2. Normative Principles

To prevent cryptographic drift, implementation ambiguity, and attack surface expansion, the system mandates the exclusive use of deterministic hashing, canonical input representation, and elliptic curve cryptography. Legacy algorithms and insecure practices are categorically disallowed.

The standard prioritizes explicit encoding formats, forward compatibility, and integrity guarantees. Compliance with this document is not optional; all actors must adopt and enforce its technical prescriptions.

3. Technical Specification

3.1 Hashing Standards

All hashing operations must use SHA3-384 (Keccak family). This includes identifiers, message digests, signature payloads, integrity validations, and content addressing. Hash functions must operate exclusively on UTF-8 byte sequences, with no salt, padding, or personalization.

Output size: 384 bits (48 bytes)

Security level: 192-bit collision resistance

Input encoding: Strict UTF-8

Disallowed algorithms: SHA-1, SHA-2 (including SHA-256), MD5 and all deprecated or variable-length hash functions

3.2 Hash Representation and Encoding

Hash digests must be encoded in a deterministic and interoperable manner:

Default format: lowercase hexadecimal (e.g., a3f1c2...)

Alternative format: Base64 (only when required by external systems)

Hex casing: Lowercase only — uppercase is invalid

Input: UTF-8 without BOM or whitespace

Hashing must always operate on normalized, clean inputs

3.3 Digital Signature Algorithm

All signatures must conform to ECDSA over the secp384r1 curve, with digesting performed manually using SHA3-384, followed by signing using SHA3-384withECDSA. This method decouples hashing from the signature algorithm internally, while maintaining interoperability and strong cryptographic guarantees.

Signature algorithm: SHA3-384withECDSA

Digest: SHA3-384 (manual, deterministic)

Curve: secp384r1

Output: DER-encoded byte array

Transmission encoding: Base64 (preferred) or lowercase hexadecimal

Private keys must remain under exclusive user custody.

Accepted key formats:

Format	Encoding	Usage
PEM	Base64-wrapped	External APIs
Base64	Raw DER-encoded bytes	Network protocols
Hexadecimal	Raw DER-encoded bytes	Diagnostic tooling

Internal encoding standards:

Private Key: PKCS#8

Public Key: X.509

Exported key materials must follow these formats strictly to ensure proper validation and cross-system compatibility.

When exporting private keys using a password, the following parameters must be applied:

Encryption algorithm: AES-256-CBC

Key derivation function (PRF): HMAC-SHA3-384

Iteration count: 65,536

Random source: SecureRandom (cryptographically strong RNG)

Provider: BouncyCastle

Encoding: Encrypted PKCS#8

It is also possible to export the private key unencrypted, using plain PKCS#8 format.

3.4 Signature Generation and Validation

All signature operations must follow a strict canonicalization model and digest flow. The process must include:

Encoding the full payload as a UTF-8 byte sequence

Signing the resulting byte stream using SHA3-384withECDSA

Transmitting both the signature and the associated public key

To validate a signature, the verifier must:

Reconstruct the exact input

Verify the signature using the public key and SHA3-384withECDSA

Accept the message only if verification yields a valid result

Any deviation in encoding, ordering, or representation invalidates the signature.

3.5 ECIES Encryption and Decryption (Optional)

Norsh supports ECIES for optional asymmetric encryption between trusted peers. This is reserved for scenarios requiring confidentiality and targeted payload delivery.

Scheme: ECIES over secp384r1 using BouncyCastle

Encryption: With recipient’s public key

Decryption: Requires corresponding private key

Provider algorithm: "ECIES" from "BC"

Use cases: Confidential transport, secrets, token exchange

No ciphertexts are retained by Norsh, and decryption must be handled exclusively by the recipient. APIs must not expose encryption/decryption endpoints.

4. Security Considerations

This specification eliminates ambiguity by rejecting algorithmic variance. By requiring SHA3-384, secp384r1 ECDSA, and deterministic canonicalization, it guards against downgrade attacks, format mismatches, and signature replay. The manual digest process enhances control and transparency over signature generation.

It is acknowledged that SHA3 and ECDSA are not quantum-resistant. Although secure under current cryptographic models, a future NTP will define the migration path to post-quantum primitives, ensuring forward security and continuity.

5. Compliance and International Standards

The cryptographic configuration adopted by the Norsh ecosystem was selected not only for its security properties, but also for its alignment with recognized international standards, regulatory frameworks, and forward compatibility with global security and legal infrastructures.

5.1 Algorithmic Compliance

Component	Algorithm Used	Compliance Standards
Hashing	SHA3-384	NIST FIPS 202, ISO/IEC 10118-3
Signature Algorithm	ECDSA with SHA3-384	ANSI X9.62, FIPS 186-4, ISO/IEC 14888
Curve	secp384r1 (NIST P-384)	NIST SP 800-186, NSA Suite B
Key Encoding	PKCS#8 (private), X.509 (public)	RFC 5958, RFC 5280
Encryption	ECIES	ISO/IEC 18033-2 (via BouncyCastle implementation)

Note: The Norsh ecosystem does not adopt the P-521 (secp521r1) elliptic curve, despite its theoretically higher security level, due to limited compatibility across major cryptographic libraries, programming languages, and hardware modules. Many platforms, especially those using embedded systems, HSMs, or constrained environments, lack stable support for P-521. The selected P-384 (secp384r1) provides a balanced trade-off between strong cryptographic strength (~192-bit security) and broad interoperability, ensuring consistent cross-platform behavior and long-term maintainability.

These choices ensure cryptographic compliance with:

United States

NIST FIPS 202 – SHA3 family.

NIST FIPS 186-4 – Digital Signature Standard.

NIST SP 800-186 – ECC recommendations.

NSA CNSA Suite – Approved algorithms for national security systems.

HIPAA (45 CFR Part 164) – Healthcare data security.

GLBA (15 U.S.C. §§ 6801–6809) – Financial data safeguards.

FERPA (20 U.S.C. § 1232g) – Student record protections.

CCPA (Cal. Civ. Code §1798.100 et seq.).

Sarbanes-Oxley Act (Pub. L. 107-204, Sec. 404).

Federal Reserve SR 11-7 / FFIEC IT Handbook – Cybersecurity controls.

NIST Privacy Framework (2020).

European Union & United Kingdom

GDPR (Reg. EU 2016/679).

eIDAS (Reg. EU 910/2014).

UK - Data Protection Act 2018 (c.12).

UK - FCA Handbook SYSC 3 & 13.

Germany – BSI IT-Grundschutz (BSI-Standard 200-x).

Switzerland – Federal Data Protection Act (FADP, RS 235.1, 2023).

FINMA Circular 2008/21 – Operational risks in banks.

Estonia – Digital Signatures Act (RT I 2000, 26, 150; consolidated 2021).

Estonia – X-Road Interoperability Framework (v7, 2020).

Latin America (Other Countries)

Brazil - LGPD (Law No. 13,709/2018).

Brazil - CVM Instruction No. 617/2019 – Money laundering prevention.

Brazil - Central Bank Resolution No. 4,658/2018 – Cybersecurity and cloud.

Brazil - ABNT NBR ISO/IEC 27001:2013 – Brazilian adoption of ISO 27001.

Brazil - ABNT NBR ISO/IEC 27002:2013 – Security controls.

Argentina - Personal Data Protection Law (Law No. 25,326/2000) – National standards for encryption and confidentiality of personal data.

Chile - Law No. 19,628/1999 on the Protection of Private Life, amended 2023 – Requires secure handling and cryptographic protection of sensitive data.

Mexico - Federal Law on the Protection of Personal Data Held by Private Parties (LFPDPPP, 2010) – Enforces technical and organizational security measures, including encryption.

Colombia - Law No. 1581/2012 (Data Protection Law) – Establishes mandatory safeguards for personal data integrity and confidentiality.

Peru - Law No. 29733/2011 – Personal Data Protection Law, requiring adequate security measures consistent with ISO 27001.

Asia-Pacific

Japan – MIC/METI Information Security Guidelines (2018).

Japan – My Number Act (Act No. 27/2015).

South Korea – Personal Information Protection Act (PIPA, Act No. 14839/2017).

South Korea – KISA Cryptographic Guidelines (2019).

China – Cryptography Law (2019, Order No. 37).

China – GM/T 0003-2012 / GM/T 0004-2012 (SM2/SM3/SM4).

Singapore – PDPA (No. 26/2012, revised 2021).

Singapore – IMDA Advisory Guidelines (2019).

Australia – Privacy Act 1988 (as amended 2020).

Australia – ACSC ISM (2022).

Global Standards

ISO/IEC 27001:2022 – Information Security Management Systems.

ISO/IEC 27002:2022 – Information security controls.

ISO/IEC 27005:2018 – Risk management.

ISO/IEC 27701:2019 – Privacy Information Management.

PCI-DSS v4.0 (2022).

Basel III (2017).

5.2 Security Grade and Global Recognition

SHA3-384 is widely regarded as one of the most robust hash functions in public use, designed to resist collision and pre-image attacks beyond what SHA-2 can guarantee.

ECDSA over secp384r1 is recognized for offering a high security margin (~192-bit security level), suitable for government-grade and financial applications.

AES-256-CBC with HMAC-SHA3-384 used in private key encryption exceeds the majority of minimum security recommendations in commercial cryptography.

PKCS#8 with password-based encryption using HMAC-SHA3-384 allows secure key export and import with high resistance to brute-force attacks due to 65,536 iterations.

5.3 Comparison with Other Blockchains

Blockchain	Hash Algorithm	Signature Scheme	Curve Used	Compliance Grade
Bitcoin	SHA-256	ECDSA (SHA256)	secp256k1	Low (no NIST curve, SHA-2 only)
Ethereum	Keccak-256	ECDSA (SHA3-like)	secp256k1	Medium (non-standard Keccak, not SHA3)
Solana	SHA-256	Ed25519	Curve25519	Medium (modern, but Ed25519 not CNSA)
Algorand	SHA-512/256	Ed25519	Curve25519	Medium (same as above)
Cardano	Blake2b-224	Ed25519	Curve25519	Medium (non-NIST hash)
Norsh	SHA3-384	ECDSA (SHA3-384withECDSA)	secp384r1	High (CNSA, NIST, ISO/IEC, GDPR, LGPD, eIDAS, MIC-JP, KISA-KR, BACEN-BR, PCI-DSS, Basel III)

Note: Most public blockchains use secp256k1, which is not recommended by NIST and lacks formal approval for use in regulated environments.

Cryptographic Longevity and the Need for Algorithm Rotation

Modern cryptographic algorithms are not permanently secure. Their security lifespan depends on:

Advances in computational power (especially with quantum computing)

Cryptanalysis techniques that may weaken assumptions over time

Regulatory updates enforcing migration to newer, post-quantum algorithms

Expected Timeline for Deprecation

Algorithm	Current Status	Estimated Validity Horizon	Replacement Path
SHA-256	Acceptable (legacy)	Until ~2030–2035 (non-quantum)	SHA-3, SHA-512/256
SHA3-384	Strong	Beyond 2040 (classical)	Post-quantum hash
secp256k1 + ECDSA	Weak (non-compliant)	Likely deprecated by 2030	NIST curves or lattice-based signatures
secp384r1 + ECDSA	Strong	~2035–2045 (classical)	CRYSTALS-Dilithium, SPHINCS+ (PQ)
Ed25519	Acceptable	~2035 (depending on context)	Hybrid/PQ schemes

Consequences for Non-Compliant Blockchains

Blockchains that continue using outdated or non-rotatable cryptographic primitives (e.g., secp256k1) face increasing regulatory and technical risks:

Inability to comply with banking, defense, and cross-border regulatory audits.

Loss of trust in cryptographic guarantees by institutional actors.

Unreliable signatures once quantum computers become practical for ECDLP attacks.

Impossibility of upgrade for immutable ledger entries already signed with broken schemes.

Forking pressure: Networks may be forced to fork or wrap assets in secure layers, adding complexity and cost.

Strategic Positioning of Norsh

Norsh adopts secp384r1 with SHA3-384, offering a high-security baseline with:

Strong protection in classical environments

Clear migration path to post-quantum cryptography

Key material encoded in standard formats (PKCS#8 / X.509) that are upgradeable

Native canonicalization and signature isolation to support hybrid signature models in the future

This ensures long-term legal, technical, and cryptographic continuity, while other blockchains may face compatibility fragmentation or even irreversible trust decay.

5.4 Rationale for Adoption in Norsh

Auditability: SHA3-384 offers longer digest and better resistance to collision than SHA3-256, enabling higher audit precision for long-term digital archives.

Legal-grade Signatures: Using SHA3-384withECDSA over a NIST curve allows compliance with qualified digital signature frameworks (e.g., EU eIDAS Qualified Signature).

Interoperability: Standard formats (PKCS#8, X.509, DER) allow seamless integration with HSMs, secure enclaves, identity providers, and compliant e-signature platforms.

Cryptographic Maturity: All cryptographic choices are considered mature, well-reviewed, and broadly implemented in commercial security libraries (e.g., BouncyCastle, OpenSSL, AWS KMS).

6. Conclusion

This NTP establishes the definitive cryptographic foundation for the Norsh ecosystem. It mandates the use of SHA3-384 hashing, ECDSA over secp384r1 with integrated digesting, strict canonicalization, and optional ECIES encryption. These prescriptions ensure determinism, verifiability, and cross-system integrity. Adherence to this standard is mandatory and enforceable across all system layers.

NTP-3: Cryptography and Hash Specification

1. Scope#

2. Normative Principles#

3. Technical Specification#

3.1 Hashing Standards#

3.2 Hash Representation and Encoding#

3.3 Digital Signature Algorithm#

3.4 Signature Generation and Validation#

3.5 ECIES Encryption and Decryption (Optional)#

4. Security Considerations#

5. Compliance and International Standards#

5.1 Algorithmic Compliance#

5.2 Security Grade and Global Recognition#

5.3 Comparison with Other Blockchains#

Cryptographic Longevity and the Need for Algorithm Rotation#

Expected Timeline for Deprecation#

Consequences for Non-Compliant Blockchains#

Strategic Positioning of Norsh#

5.4 Rationale for Adoption in Norsh#

6. Conclusion#