Skip to content
AIGP

RFC-010: AIGP Runtime Governance Protocol — 4A. Cryptographic Algorithm Agility

AIGP Specification › RFC-010: AIGP Runtime Governance Protocol › 4A. Cryptographic Algorithm Agility

← 4. HMAC Authentication · Section index · 5. Governance Modes →

4A. Cryptographic Algorithm Agility

4A.1 Motivation

Section 4 defines HMAC-SHA256 as the default authentication mechanism. This section extends the protocol to support multiple cryptographic schemes — including asymmetric signatures and post-quantum algorithms — selectable at registration time.

Algorithm agility is required for:

  • FIPS 140-3 deployments requiring validated implementations of specific algorithms
  • CNSA 2.0 alignment mandating post-quantum cryptography (ML-DSA, SLH-DSA)
  • Deployments requiring non-repudiation (asymmetric signatures vs. symmetric MACs)
  • Interoperability with existing PKI infrastructure (ECDSA, Ed25519)

4A.2 Structural Requirement

A cryptographic scheme is admissible for AIGP message authentication if and only if it satisfies ALL of the following:

  1. Tag size: The scheme produces a per-message authentication tag of at least 128 bits.
  2. Security level: The scheme offers existential unforgeability under chosen-message attack (EUF-CMA) at a security level of at least 128 bits under standard cryptographic assumptions.
  3. Determinism or freshness: The scheme either produces deterministic outputs (HMAC, Ed25519) or incorporates per-signature randomness from a cryptographically secure source.

4A.3 Algorithm Registry

The following algorithms are registered for use with AIGP:

Identifier Type Security Level Standard Notes
hmac-sha256 MAC 128-bit FIPS 198-1 Default — backward-compatible
hmac-sha512 MAC 256-bit FIPS 198-1
hmac-sha3-256 MAC 128-bit FIPS 202
ed25519 Signature 128-bit RFC 8032 Recommended for new deployments
ed448 Signature 224-bit RFC 8032
ecdsa-p256 Signature 128-bit FIPS 186-5
ecdsa-p384 Signature 192-bit FIPS 186-5
rsa-pss-2048 Signature 112-bit* FIPS 186-5 *Accepted for legacy interop only
rsa-pss-4096 Signature 128-bit FIPS 186-5
ml-dsa-44 Signature (PQC) NIST Level 2 FIPS 204 CRYSTALS-Dilithium
ml-dsa-65 Signature (PQC) NIST Level 3 FIPS 204 Recommended PQC
ml-dsa-87 Signature (PQC) NIST Level 5 FIPS 204

4A.4 Algorithm Declaration at Registration

The REGISTER message (§3.1) is extended with the following optional fields:

{
  "protocol_version": "5.0",
  "message_type": "REGISTER",
  "app_id": "APP_PRJ",
  "mode": "ENFORCE",
  "crypto_scheme": "ed25519",
  "fips_required": false,
  "public_key": "MCowBQYDK2VwAyEA...",
  "use_cases": [...]
}
Field Type Required Default Description
crypto_scheme string No hmac-sha256 Algorithm identifier from §4A.3 registry
fips_required boolean No false If true, server MUST reject non-FIPS-validated implementations
public_key string Conditional — Base64-encoded public key. REQUIRED for asymmetric schemes; MUST NOT be present for MAC schemes

Validation rules:

  • If crypto_scheme is omitted, the server MUST assume hmac-sha256 and authenticate using the pre-shared HMAC secret (backward-compatible behavior per §4).
  • If crypto_scheme names an asymmetric algorithm, public_key MUST be present and well-formed for that algorithm.
  • If fips_required is true and the declared scheme does not have a FIPS 140-3 validated implementation available to the server, the server MUST reject the registration with HTTP 422 and reason fips_validation_unavailable.
  • The declared crypto_scheme is immutable for the lifetime of the registration. To change algorithms, the application MUST de-register and re-register.

4A.5 Signature Header Format

The X-AIGP-Signature header format is extended to carry the algorithm identifier:

X-AIGP-Signature: {algorithm}={base64_or_hex_signature}

Examples:

X-AIGP-Signature: hmac-sha256=a1b2c3d4e5f6...
X-AIGP-Signature: ed25519=MEUCIQD...
X-AIGP-Signature: ml-dsa-65=MIIBIjAN...

Parsing rule: Split on the first = character. The left side is the algorithm identifier; the right side is the authentication tag encoded in hex (for HMAC) or base64 (for signatures).

Validation rule: The algorithm identifier in the header MUST match the crypto_scheme declared at registration. If they do not match, the server MUST reject the message with HTTP 401 and reason algorithm_mismatch.

4A.6 Signature Computation

For MAC schemes (hmac-*), the computation is identical to §4.1 with the declared hash function substituted:

message = "{timestamp}\n{method}\n{path}\n{body_hash}"
tag = HMAC(secret, message, hash_function)

For signature schemes (ed25519, ecdsa-, rsa-pss-, ml-dsa-*), the computation signs the same canonical message:

message = "{timestamp}\n{method}\n{path}\n{body_hash}"
signature = Sign(private_key, message)

Where body_hash is always SHA-256 of the request body (regardless of the signature algorithm), ensuring the signed message format is consistent across all schemes.

4A.7 FIPS 140-3 Validation Gate

When fips_required: true is declared at registration:

  1. The server MUST verify it has access to a FIPS 140-3 validated cryptographic module for the declared scheme.
  2. The server MUST record the FIPS module identifier and certificate number in the registration record.
  3. All signature verification for that application MUST use the validated module.
  4. If the validated module becomes unavailable (e.g., certificate revocation), the server MUST suspend the registration and emit a governance alert.

4A.8 Migration Path

  • Existing applications using §4 HMAC-SHA256 continue to work unchanged. Omitting crypto_scheme implies hmac-sha256.
  • The server MUST support simultaneous registrations using different algorithms. Application A may use ed25519 while Application B uses hmac-sha256.
  • SDK implementations MUST provide a Signer interface abstracting algorithm details, with HmacSha256Signer as the default implementation preserving backward compatibility.

← 4. HMAC Authentication · Section index · 5. Governance Modes →