This page exists to be forwarded to the person who has to sign off. It states what we defend against, what we deliberately cannot do, which primitives we use, and how to tell us when we have got something wrong. There is no marketing language below this paragraph.
A threat model that lists only threats is a wish list. Each row below names the mechanism, not the intention.
| # | Threat | Mechanism that defeats it |
|---|---|---|
| 01 | Compromised mailbox An attacker holds a mailbox that receives your intake, links, or notifications. |
Content is sealed to the destination service's key, never to the mailbox. The mailbox carries a reference and a sealed blob it cannot open. Compromising it yields ciphertext and routing metadata — no plaintext, and no ability to originate, because origination requires an attested key-pair the mailbox does not hold. |
| 02 | MITM on the relay path An attacker terminates or intercepts the connection between peers. |
Envelope content is encrypted end-to-end beneath the transport, so breaking TLS reveals ciphertext. The hop key is derived from an ECDH exchange bound into the AAD, and the peer's Ed25519 attestation signature covers the challenge, peer identity and timestamp — an interceptor cannot produce it. |
| 03 | Insider at the relay Someone with production access at KryptAPI decides to read your traffic. |
No content key or private key material exists on our infrastructure to be misused. Decryption capability was never built into the relay — there is no admin console, feature flag, or break-glass procedure that renders a payload. An insider with total access obtains exactly what a subpoena obtains: metadata. |
| 04 | Stolen device or exfiltrated key A laptop, container image, or secret store leaks a private key. |
Hop keys are ephemeral and discarded after sealing, so historical traffic is not retroactively readable. Long-lived identity keys sign attestations but never encrypt content. Revocation via POST /v1/keys/:id/rotate takes effect at the next attestation — seconds, not a deploy cycle — and the revocation itself is attested and audited. |
| 05 | Replayed payload A captured envelope is re-submitted to trigger a duplicate action. |
The AAD binds route ID, hop index, and a timestamp inside a bounded window, and the derived key is a function of that AAD. A replay onto a different hop derives a key that decrypts nothing; a replay onto the same hop is refused as envelope_already_opened, since ciphertext collection is single-shot. |
| 06 | Silent tampering Someone alters a payload, or alters the record of a payload, and hopes nobody checks. |
AES-GCM's authentication tag makes content tampering a hard decryption failure, never a silent corruption. Record tampering is defeated by the audit chain: each entry commits to the digest of the previous one, so altering any historical line invalidates every hash after it. You can verify the chain yourself, offline, with the open verifier. |
We do not defend against a compromised destination. If an attacker fully controls the service that is authorised to open an envelope, they can read what it opens — that is what "authorised" means. Our job is to make sure that is the only way to read it, and that the opening is recorded.
Traffic analysis at the metadata level. We carry ciphertext length, timing and routing, and an observer with total relay visibility can infer patterns from them. Padding and batching are available per route; they cost latency and GB, so they are opt-in rather than assumed.
Not "restricted by policy". Not "access-logged". Absent. Open an envelope to read the specific reason each one cannot reach us.
Under the lens: size, timing, route and key fingerprints. The content region stays noise wherever you put it. We can prove delivery; we cannot read it.
Drag the lens with a pointer, or focus the panel and steer it with the arrow keys.
Sealing happens in your process before the HTTP call. The relay receives a base64 ciphertext blob and an authentication tag. There is no code path in the relay that calls a decrypt function — the relay does not link a symmetric cipher implementation for envelope content at all.
envelope opened →Content keys are derived, never transmitted. Each side computes the same AES-256-GCM key from an ECDH shared secret and HKDF-SHA256 over the hop's AAD. Nothing that travels through the relay contains a wrapped key, so there is nothing for us to store or lose.
envelope opened →We accept public JWKs and fingerprints. The API has no field, form, or support workflow that accepts private key material, and SDK conformance tests assert that private components are stripped before serialisation. If you ever manage to send us one, that is a bug and we will tell you so.
envelope opened →The peer directory holds public keys, fingerprints, custody type and rotation schedule. For HSM and escrow custody we hold only the fingerprint — the public key itself is served from your directory endpoint at attestation time and is not cached beyond the attestation TTL.
envelope opened →Filenames, subjects, MIME types, record IDs and classifications live inside the ciphertext. The AAD carries only what routing strictly requires: route ID, hop index, timestamp, retention hint. If you put something in the AAD, that is a choice you make knowingly — the SDK warns you.
envelope opened →KryptAPI has no concept of your end users. There are organisations, key-pairs, routes and envelopes. A patient, a claimant, a customer or an employee is a string inside a ciphertext blob — indistinguishable to us from any other bytes, and impossible for us to enumerate.
envelope opened →Most audit logs record what happened. This one makes altering the record detectable by anyone holding a later entry — including you, offline, with software we did not write for you.
Each entry contains its event, its subject, and the SHA-256 digest of the previous entry's canonical serialisation. The chain head is published in every statement, so a document you already hold pins the entire history before it.
Export with GET /v1/audit and run krypt-audit-verify --head 0x… from any SDK. The verifier recomputes every digest locally. It never contacts us, and it is roughly two hundred lines you are welcome to read.
Events, subjects, quantities, fingerprints, timestamps and digests. Never content — an audit export of an envelope you cannot open is still an audit export you cannot read. Format is newline-delimited JSON, stable across API versions.
Custody is a per-key-pair decision, not an account-wide one. An intake key can be relay-directory published while an archive key sits in escrow.
| Property | Relay-managed directory | Customer HSM | Offline escrow quorum |
|---|---|---|---|
| Private key location | your service process | your HSM (PKCS#11) | offline shares, 2-of-3 |
| KryptAPI holds | public JWK + fingerprint | fingerprint only | fingerprint only |
| Rotation trigger | API or schedule | API + HSM operator | quorum ceremony |
| Rotation latency | seconds | minutes | hours to days |
| Attestation signing | in-process Ed25519 | HSM-resident Ed25519 | HSM or air-gapped signer |
| Recovery if lost | none — rotate and re-issue | HSM backup policy | 2 of 3 shares reconstitute |
| Typical use | intake and dashboard peers | regulated production paths | long-retention archives |
| Metered as | 1 active key-pair | 1 active key-pair | 1 active key-pair |
A quorum of three custodians is still one logical key-pair on your statement. We meter cryptographic objects, not people.
Nothing here is novel. Novelty in a cipher is a liability; the interesting engineering is in the completeness of the application, not the exoticism of the primitive.
| Primitive | Where it is used | Parameters | Rotation cadence |
|---|---|---|---|
| AES-256-GCM | Envelope content sealing | 96-bit IV, 128-bit tag, AAD bound to hop | per envelope (ephemeral) |
| ECDH P-256 | Hop key agreement (default) | ephemeral sender key, HKDF-SHA256 expansion | per hop (ephemeral) |
| X25519 | Hop key agreement (preferred where both peers support it) | ephemeral sender key, HKDF-SHA256 expansion | per hop (ephemeral) |
| Ed25519 | Attestation signatures, webhook signing, statement signing | signature over challenge ‖ peer_id ‖ timestamp | 90 days default, 30 at custody-scale |
| HKDF-SHA256 | Deriving content keys from the ECDH shared secret | info = hop AAD, salt = route nonce | per hop (ephemeral) |
| SHA-256 | Audit chaining, ciphertext digests, statement hashes | canonical JSON serialisation before digest | n/a |
| TLS 1.3 | Transport beneath the envelope | modern suites only; no downgrade path | certificates 90 days |
| CSPRNG | IVs, nonces, challenges, envelope IDs | platform CSPRNG; no userspace PRNG in any path | n/a |
No downgrade negotiation, no "compatibility mode", no custom cipher, no key escrow held by us, and no algorithm agility that lets a peer talk us into something weaker. Unsupported suites are refused with cipher_suite_unsupported.
Hybrid X25519 + ML-KEM-768 key agreement is implemented behind a per-route flag and in production for archive routes with long retention. It is not yet the default, because defaults should change once, deliberately, and with a migration path already proven.
Report anything you believe weakens the guarantees on this page to security@kryptapi.com. Encrypt with the key below if the report contains anything you would not put in a postcard.
Our commitments: acknowledgement within one business day, a technical assessment within five, and a fix or a written explanation of why it is not one within thirty. We publish a summary of every valid report after the fix ships, including the ones that were embarrassing.
We will not pursue legal action against good-faith research that avoids privacy violations, service degradation and data destruction. Testing against your own sandbox organisation is always in scope and unmetered; testing against another client's traffic never is.
Contact: security@kryptapi.com
Policy: kryptapi.com/security#disclosure
File: /.well-known/security.txt
Preferred-Languages: en
Expires: 2027-06-30T00:00:00Z
PGP fingerprint
9F42 A1C7 B3D4 0E11 8C31
4A0E D0F2 771B 5F1C A740
Annual third-party cryptographic review of the sealing path and the audit chain, plus a rolling penetration test of the relay and portal. Reports are available under NDA to clients and to prospects with a signed agreement in progress — request them at security@kryptapi.com.