@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 for the guarantees this supports.
High-level services
The two classes everything else in the monorepo actually calls:VerificationCrypto.verify() is what both POST /verify and POST /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 |
HashRegistry/SignatureRegistry based on loadConfig() (from 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 hashersVerificationCrypto/ReceiptCryptobuild on.ReceiptSigner,SignatureVerifier— sign/verify primitives over canonical objects.CryptoBuilder— assembles aCryptoProviderfrom a chosen hash + signature provider.KeyPair,KeyStore— key material abstractions.
Related
Security Model
The guarantees this package’s algorithms support.
Receipt
The artifact
ReceiptCrypto produces.Verify
Where
VerificationCrypto.verify() is actually called.Replay
The other caller of the same method.