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-256 (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: 256 bits (32 bytes)

Security level: 128-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 secp256k1 curve, with digesting performed manually using SHA3-256, followed by signing using NONEwithECDSA. This method decouples hashing from the signature algorithm, avoiding discrepancies across runtimes or libraries.

Signature algorithm: NONEwithECDSA

Digest: SHA3-256 (manual, deterministic)

Curve: secp256k1

Output: DER-encoded byte array

Transmission encoding: Base64 (preferred) or lowercase hexadecimal

Private keys must remain under exclusive user custody. The platform must never generate, store, or transmit private key material.

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.

3.4 Signature Generation and Validation

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

Canonicalizing all fields according to the rules in section 3.5

Encoding the full payload as a UTF-8 byte sequence

Computing the SHA3-256 hash of the canonical string

Signing the resulting hash using NONEwithECDSA

Transmitting both the signature and the associated public key

To validate a signature, the verifier must:

Reconstruct the exact canonical input

Hash it using SHA3-256

Verify the signature using the public key and NONEwithECDSA

Accept the message only if verification yields a valid result

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

3.5 Canonicalization Rules for Signature Inputs

Canonicalization enforces strict predictability across all serialization processes. All input fields to be signed must be concatenated using the following rules:

Separator: Pipe (|, ASCII 124)

Field order: Must follow schema or API definition exactly

Nulls: Encoded as empty string ""

Empty strings: Preserved without substitution

Booleans: true or false, lowercase

Numbers: Decimal notation, . as decimal separator, no scientific notation

Timestamps: ISO 8601 format with explicit UTC suffix (Z)

Encoding: UTF-8 only, without padding or escape sequences

Escaping of the separator character is strictly prohibited

Example:
Input values:

["user123", 100.0, "2025-01-09T15:00:00Z", null, "active"]

Canonical string:

user123|100.0|2025-01-09T15:00:00Z||active

3.6 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 secp256k1 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-256, secp256k1 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. Conclusion

This NTP establishes the definitive cryptographic foundation for the Norsh ecosystem. It mandates the use of SHA3-256 hashing, ECDSA over secp256k1 with manual 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 Canonicalization Rules for Signature Inputs#

3.6 ECIES Encryption and Decryption (Optional)#

4. Security Considerations#

5. Conclusion#