> ## Documentation Index
> Fetch the complete documentation index at: https://docs.manthan.systems/llms.txt
> Use this file to discover all available pages before exploring further.

# crypto

> @parmana/crypto — canonical serialization, hashing, signing, and receipts

`@parmana/crypto` is where every concrete cryptographic algorithm in the monorepo is chosen — per its own `CryptoBootstrap` doc comment, it's "the ONLY place in the crypto package that should reference concrete cryptographic algorithms." See [Architecture → Security Model](/docs/architecture/security-model) for the guarantees this supports.

## High-level services

The two classes everything else in the monorepo actually calls:

```ts theme={null}
class VerificationCrypto {
  hash(trustRecord: ExecutionTrustRecord): Promise<string>;
  verify(trustRecord: ExecutionTrustRecord): Promise<boolean>; // re-hashes and compares to trustRecordHash
}

class ReceiptCrypto {
  hash(trustRecord: unknown): Promise<string>;
  sign(value: unknown): Promise<string>;
  createReceipt(payload: Omit<Receipt, "signature" | "algorithm">): Promise<Receipt>;
}
```

`VerificationCrypto.verify()` is what both [`POST /verify`](/docs/api/verify) and [`POST /replay`](/docs/api/replay) actually run under the hood — see those pages for why that means the two endpoints currently check the same thing. `VerificationCrypto`'s `canonicalRecord()` deliberately excludes the mutable `verifications`/`receipts` arrays from what gets hashed, so appending new Verifications or Receipts never invalidates a trust record's own hash.

## Default algorithms

`CryptoBootstrap` (composition root, cached for the process lifetime) registers exactly one hash provider and one signature provider by default:

| Concern    | Default provider | Class                      |
| ---------- | ---------------- | -------------------------- |
| Hashing    | SHA-256          | `SHA256HashProvider`       |
| Signatures | Ed25519          | `Ed25519SignatureProvider` |

Both are selected from a `HashRegistry`/`SignatureRegistry` based on `loadConfig()` (from [`shared`](/docs/packages/shared)) — swapping algorithms is a configuration change, not a code change, via the `CryptoProvider`/`HashProvider`/`SignatureProvider` interfaces (`packages/crypto/src/providers/`).

## Other exports

`packages/crypto/src/index.ts` also exports:

* **`CanonicalSerializer`** — deterministic JSON serialization (stable key ordering), the basis for reproducible hashes.
* **`TrustRecordHasher`**, **`ReceiptHasher`** — lower-level hashers `VerificationCrypto`/`ReceiptCrypto` build on.
* **`ReceiptSigner`**, **`SignatureVerifier`** — sign/verify primitives over canonical objects.
* **`CryptoBuilder`** — assembles a `CryptoProvider` from a chosen hash + signature provider.
* **`KeyPair`**, **`KeyStore`** — key material abstractions.

## Related

<CardGroup cols={2}>
  <Card title="Security Model" href="/docs/architecture/security-model">The guarantees this package's algorithms support.</Card>
  <Card title="Receipt" href="/docs/concepts/receipt">The artifact `ReceiptCrypto` produces.</Card>
  <Card title="Verify" href="/docs/api/verify">Where `VerificationCrypto.verify()` is actually called.</Card>
  <Card title="Replay" href="/docs/api/replay">The other caller of the same method.</Card>
</CardGroup>