feat(nexus): implement Ed25519 signature generation and verification in registry and escrow

[qubeena07]

Package

agent-os / nexus module

Problem Statement

Three places in agent-governance-python/agent-os/modules/nexus/ skip real cryptography entirely:

1. registry.py line 110 — agent registration accepts any signature without checking it

# TODO: Verify signature against verification key
# For now, trust the signature

2. registry.py line 199 — deregistration also skips verification

# TODO: Verify signature

3. escrow.py line 360 — fake string used instead of real Ed25519 signing

# TODO: Generate actual signature
signature = f"sig_{requester_did}_{task_hash[:8]}"

AgentIdentity already stores a proper verification_key in ed25519:<base64_public_key> format. The infrastructure is there — the verification calls are just missing.

Proposed Solution

1. Add nexus/crypto.py with Ed25519 sign/verify helpers using the cryptography library
2. Wire verify() into AgentRegistry.register(), update(), and deregister()
3. In ProofOfOutcome.create_escrow(), require a real requester_signature parameter instead of generating a fake one
4. Add private_key_bytes to NexusClient and update _generate_signature() to use real Ed25519
5. Add InvalidSignatureError to exceptions.py
6. Add cryptography>=42.0.0,<44.0 to nexus/pyproject.toml (already used in dmz.py but undeclared)
7. Update tests to generate real keypairs and use valid signatures

What the signature covers

• Registration / update: agent signs the manifest hash (same hash computed by _compute_manifest_hash, which excludes timestamps for determinism)
• Deregistration: agent signs the agent_did bytes to prove ownership
• Escrow creation: requester signs "{requester_did}:{provider_did}:{task_hash}:{credits}".encode()

Out of scope

• Nexus server-side key management (the _sign_registration / _sign_escrow server signatures are placeholders handled separately)
• Remote DMZ mode (tracked separately as NotImplementedError stubs)

[qubeena07]

Opened a PR for this: #2782

Here is what was done:

Added nexus/crypto.py with generate_keypair, sign, verify, manifest_hash_for_signing, and escrow_message helpers using the cryptography library.

Wired verify() into AgentRegistry.register(), update(), and deregister(). For register and update the agent signs the manifest hash. For deregister the agent signs their own DID to prove ownership.

In ProofOfOutcome.create_escrow() removed the fake sig_{did}_{hash[:8]} stub and made requester_signature a required parameter with a clear error message pointing to nexus.crypto.sign().

Added private_key_bytes to NexusClient and replaced the SHA256 placeholder with real Ed25519 signing methods.

Also declared cryptography>=42.0.0,<44.0 in pyproject.toml since it was already used in dmz.py but not listed as a dependency.

All 28 registry tests pass and three new tests cover invalid and wrong-key rejection.

[chopmob-cloud]

AlgoVoi has production Ed25519 + Falcon-1024 credential issuance that maps onto the three stub TODOs here.

The Nexus registry and escrow stubs (key generation, signature verification, escrow release authorisation) are exactly the pattern AlgoVoi uses for its ATB Pass Certificate -- a post-quantum signed credential that proves an agent passed the pre-payment evaluation threshold.

AlgoVoi's implementation:

• Key generation: Ed25519 via cryptography (Python) / @noble/ed25519 (TypeScript). Falcon-1024 (NIST FIPS 206) via pqcrypto. Both derive a kid from the first 16 hex chars of the SHA-256 of the public key bytes -- stable, deterministic, no registry lookup required for verification.
• Signature verification: JCS (RFC 8785) canonical form over the payload, then Ed25519 or Falcon-1024 verify. Byte-verified across 8 independent implementations in 5 languages (Python, TypeScript, Go, Rust, Java). Conformance vectors at https://github.com/chopmob-cloud/algovoi-jcs-conformance-vectors.
• Escrow release authorisation: POST /compliance/trust-query returns TRUSTED / PROVISIONAL / INSUFFICIENT_EVIDENCE / UNTRUSTED. The categorical verdict is the gate condition for escrow release, not a numeric score.

The IETF specification for the credential binding is draft-hopley-x402-pqc-credential-binding-00 (https://datatracker.ietf.org/doc/draft-hopley-x402-pqc-credential-binding/). Reference implementation: algovoi-substrate-pqc (PyPI / npm, Apache 2.0).

Happy to open a PR against the three stub locations if the design fits the AGT architecture.

AlgoVoi (chopmob-cloud) -- docs.algovoi.co.uk/pqc-substrate