Skip to content

Section 31: Cryptography and Secure Operations

TECHSPEC-31 — Section 31 · Version 0.1 · Status: Initial Draft

Status: draft. This section is an Initial Draft (Section 57 is a Working Register). It describes intended or proposed behavior, not a finalized, implemented language rule. Do not treat examples here as normative.

1. Cryptographic Philosophy

Cryptographic operations must use established, reviewed algorithms and implementations.

The language must make security-sensitive operations explicit and prevent AI agents from casually inventing cryptographic algorithms or implementing unsafe substitutes.

Cryptographic correctness must be distinguished from overall system security.

2. Supported Cryptographic Operations

The standard library should provide:

  • Cryptographic hashing.
  • Message authentication codes (MACs).
  • Digital signatures.
  • Signature verification.
  • Symmetric encryption.
  • Asymmetric encryption.
  • Secure random number generation.
  • Key derivation.
  • Secure key management.

Each operation must have a documented security purpose and supported algorithm set.

3. Approved Algorithms

Rules: - Cryptographic algorithms must come from an explicitly maintained approved set. - Deprecated or broken algorithms must be identified. - Weak algorithms must not be available through ordinary secure APIs. - Algorithm selection must be explicit where security requirements depend on it. - Applications must not silently fall back to weaker algorithms. - Algorithm recommendations must be maintained as security standards evolve.

4. Dedicated Cryptographic Types

The language should provide dedicated types for cryptographic values.

Proposed types:

  • SecretKey
  • PublicKey
  • PrivateKey
  • Signature
  • HashDigest
  • Nonce
  • Ciphertext
  • Plaintext

Rules: - Cryptographic types must not be interchangeable with ordinary strings or byte collections. - Private keys and secret keys must have restricted access. - Sensitive values must not appear in ordinary diagnostics. - Key ownership and lifetime must be explicit. - Conversions must preserve the security meaning of the underlying value.

5. Secure Randomness

Security-sensitive randomness must use a cryptographically secure random number generator.

Rules: - Ordinary pseudorandom generators must not be accepted where cryptographic randomness is required. - Randomness sources must be provided by approved runtime or operating-system facilities. - Random number generation failures must be explicit. - Nonces and other unique values must follow algorithm-specific requirements. - The language must not claim that a generated value is unpredictable without an appropriate source and implementation.

6. Hashing and Password Storage

Hashing APIs must distinguish ordinary hashing from password hashing.

Rules: - Passwords must not be stored as plaintext. - Password storage must use an approved password-hashing algorithm. - Password hashing must use appropriate salts and configurable work factors. - Ordinary fast hashes must not be presented as suitable password-storage mechanisms. - Hash comparison for authentication-sensitive operations must use appropriate constant-time comparison facilities where required.

7. Encryption and Decryption

Encryption APIs must require explicit algorithm and key requirements.

Rules: - Secure authenticated encryption should be preferred. - Nonces and initialization values must follow algorithm-specific requirements. - Encryption failures must produce explicit errors. - Decryption must authenticate ciphertext before exposing plaintext when the selected construction supports authenticated encryption. - Authentication failure must not return unverified plaintext. - Keys must not be reused in ways prohibited by the selected algorithm.

8. Digital Signatures

Digital signatures establish that data was signed by the holder of a corresponding private key, subject to the security of the algorithm and key.

Rules: - Signing and verification must be separate operations. - Signature verification must return an explicit result. - Invalid signatures must never be treated as successful verification. - The signed data and relevant algorithm parameters must be unambiguous. - Signature verification must not automatically establish that the signer is trustworthy or authorized.

9. Key Management

Key management must be handled through dedicated secure APIs.

Rules: - Private keys must not be embedded in source code. - Key storage must use approved secure storage mechanisms. - Key access must require explicit permissions. - Key rotation and revocation must be supported where applicable. - Key expiration must be enforceable. - Key export must require explicit authorization. - Key destruction must have documented limitations.

10. Cryptographic Effects and Permissions

Cryptographic operations must declare relevant effects.

Examples include: - CRYPTO.RANDOM - CRYPTO.KEY_ACCESS - CRYPTO.SIGN - CRYPTO.VERIFY - CRYPTO.ENCRYPT - CRYPTO.DECRYPT

Rules: - Sensitive key access must be separately permission-controlled. - Cryptographic effects must propagate through the call graph. - Dependencies must not inherit key permissions automatically. - Operations must identify the keys and algorithms they use without exposing secret material.

11. Compiler and Runtime Responsibilities

The compiler and runtime must: - Enforce cryptographic type restrictions. - Prevent unsafe conversions between ordinary and cryptographic values. - Require explicit key access. - Use approved cryptographic implementations. - Detect prohibited algorithm choices. - Protect secrets from ordinary logging. - Report cryptographic failures explicitly. - Preserve cryptographic semantics across execution targets.

12. Verification Limitations

The language cannot prove that a cryptographic algorithm is free from unknown vulnerabilities or that a key has never been compromised.

Verification reports must distinguish: - Algorithm approved by the language's current policy. - Approved implementation selected. - Key access authorized. - Cryptographic operation executed. - Signature or authentication successfully verified. - Broader security assumptions not established.

A successful cryptographic operation does not prove that the surrounding application is secure.

13. Design Goal

An AI agent must be able to use cryptography through safe, explicit, well-defined interfaces without inventing algorithms, weakening security settings, or confusing successful execution with established security.

Security-sensitive operations must favor established implementations over agent-generated cryptographic code.

Source file: TECHSPEC-31.md (preserved in source-original/LANG/). See the specification index, the glossary, and the cross-reference index.