CRYPTOGRAPHY
The primitives that make the chain trustworthy.
RANKIGI is built on four primitives. Ed25519 for identity. SHA-256 for the chain. AES-256-GCM for sensitive intent. PQ-512 for the post-quantum path. Each was chosen for a specific property, not for novelty.
DEFINITION
RANKIGI uses Ed25519 to sign agent passports, SHA-256 to chain events, and AES-256-GCM to encrypt intent payloads. Post-quantum migration is on the roadmap, with PQ-512 as the reference target.
THE PROBLEMS IT SOLVES
What goes wrong without it.
01
Cryptographic novelty is a liability.
An evidence system has to outlive its first audit. Choosing exotic primitives means betting that the surrounding ecosystem (libraries, hardware support, regulator familiarity) will catch up. We chose primitives that are already universal.
02
Performance and security are usually a tradeoff.
An agent emits hundreds of events per minute. The cryptography on the hot path has to be cheap enough not to matter. Ed25519 and SHA-256 satisfy this. RSA and SHA-3 in our context did not.
03
Quantum is not the threat people imagine, but it is on the horizon.
A practical quantum computer that breaks Ed25519 is years away. The risk to a chain is not the live signature but the historical record. We document the post-quantum path now so the migration can be staged before it becomes urgent.
HOW IT WORKS · TECHNICAL
The four primitives, by job.
01 ED25519
Passport signing
Every agent passport is an Ed25519 keypair. The public key is the verifiable identity. The private key signs claims (issuance, revocation, role assertions). Ed25519 was chosen for deterministic signatures, fast verification, and ubiquitous library support.
02 SHA-256
Hash chaining
Each event is canonicalized to JSON and hashed with SHA-256. The hash references the previous event's hash. Tampering at any point in the past invalidates every subsequent hash. Verification is a deterministic walk over the chain.
03 AES-256-GCM
Intent encryption
When an agent declares intent before acting, the plaintext is sensitive. The SDK encrypts intent payloads with AES-256-GCM at the client. The ciphertext is what reaches RANKIGI. Plaintext is never logged server-side.
04 PQ-512
Post-quantum readiness
PQ-512 is the reference target for our post-quantum migration. The plan is dual-signing during transition: Ed25519 plus a lattice-based signature. The chain itself migrates by anchoring future snapshots with the new primitive while preserving historical Ed25519 signatures. This work is on the roadmap.
HOW IT WORKS · PLAIN ENGLISH
Why these four, in plain English.
Ed25519 gives every agent a passport that anyone can verify. SHA-256 turns each action into a fingerprint and ties it to the previous one, so the past cannot be rewritten silently. AES-256-GCM lets agents declare what they intend to do without exposing the plain text to RANKIGI. PQ-512 is the future-proof signature target. We use what already works and we document the path to what will work later.
ANALOGY
A passport, a stamp, a sealed envelope, and a contingency plan. Identity, evidence, privacy, and longevity.
ANATOMY
Where each primitive shows up in an event.
Identity layer
Properties of the agent passport that the chain depends on.
Chain layer
Properties of the per-event hash and its link to the prior event.
Intent layer
Properties of the AES-256-GCM ciphertext attached to intent_declared events.
Anchor layer
Properties of the daily snapshot that anchors the chain externally.
REGULATION MAPPING
Where regulators expect cryptographic answers.
| Framework | Reference | Requirement | RANKIGI Answer |
|---|---|---|---|
| GDPR | Article 32 | Encryption of personal data and integrity of processing systems. | AES-256-GCM at the SDK plus SHA-256 chain integrity. |
| SOC 2 | CC6.1 | Logical access controls, including cryptographic protection of data. | Bearer tokens for API auth, AES-256-GCM for sensitive payloads, Ed25519 passports for agent identity. |
| HIPAA | 164.312(a)(2)(iv) | Encryption and decryption of ePHI as a reasonable safeguard. | AES-256-GCM at the SDK before any payload reaches RANKIGI. |
| NIST | SP 800-208 | Stateful hash-based signatures for long-term integrity. | On the roadmap. PQ-512 reference target identified for post-quantum migration. |
WHO IT IS FOR
Who reads this section closely.
CRYPTOGRAPHER
You are evaluating primitive choice and parameterization. The reasoning is on this page. We did not invent anything. We chose primitives with broad library support, conservative parameters, and a documented post-quantum path.
SECURITY ARCHITECT
You are mapping RANKIGI to your control framework. The four-layer breakdown (identity, chain, intent, anchor) lines up with most enterprise control libraries. The regulation table is your starting point for the controls map.
REGULATOR
You are confirming that the cryptography meets the bar set by your framework. The primitives are standard. The integrity property is deterministic and verifiable without our servers. The post-quantum migration plan is documented.
QUESTIONS & ANSWERS
What cryptographers ask first.
Why Ed25519 instead of ECDSA P-256?
Ed25519 has deterministic signatures (no nonce reuse risk), faster verification, smaller signatures, and extensive vetted library support. ECDSA P-256 is acceptable but gives no benefit in our threat model. Ed25519 was the simpler, safer choice.
Why SHA-256 and not SHA-3 or BLAKE3?
SHA-256 has the broadest hardware acceleration, the most universal library support, and direct alignment with what auditors and regulators already accept. BLAKE3 is faster, but the ecosystem benefit is not yet there for an evidence system.
What about quantum?
A practical quantum computer that breaks Ed25519 is years away, and the threat to RANKIGI is the historical record more than live signatures. Our path is dual-signing during transition with a lattice-based signature alongside Ed25519. PQ-512 is the reference target. The migration is on the roadmap.
How is the AES-256-GCM key managed?
Keys are scoped per organization. Distribution and rotation are handled at the SDK layer with a key envelope mechanism. Plaintext intent never reaches RANKIGI. If you lose your key, the ciphertext is unrecoverable, by design.
Are snapshots anchored externally today?
Yes. Daily snapshot heads are signed with a persistent ECDSA P-256 key and submitted to Sigstore Rekor, a public cryptographic transparency log. The returned log entry is third-party-witnessed and verifiable directly against rekor.sigstore.dev without any RANKIGI infrastructure. A blockchain anchor remains on the roadmap.
The contract every SDK and integrator implements against.
Walk through your control questionnaire with our team.