# Security limits of iam-core 1.1

Read this before using IAM for real identities or access decisions. This page
collects the limits of [iam-core 1.1](IAM.md); it does not add a stronger
security profile. [THREAT-MODEL.md](THREAT-MODEL.md) describes attackers,
assumptions and trust boundaries.

IAM authenticates key-signed graph records and evaluates a selected history.
It does not establish that a key belongs to a unique human, that a person
consented to being accepted, or that an offline history is current.

## Known limits

| Limit | What it means in practice |
|---|---|
| Offline phrase guessing | A public key lets an attacker test candidate names and incantations without contacting a server. Resistance depends on secret unpredictability and the cost of each KDF evaluation. The 12-byte minimum does not guarantee entropy. Equal names share a salt; there is no server rate limit on offline guesses. |
| Root keys do not rotate within an identity | The identity is the root public key. A different root key is a different identity, with no automatic transfer of old edges. Social recovery means new acceptance decisions; it cannot repair a compromised old key. Replacing accepted device keys in a personal graph is a different operation. |
| Revocation is delayed at other verifiers | A verifier must receive and select a history in which REVOKE or LEAVE applies. An offline old anchor cannot prove that no later revocation exists. One parent's REVOKE removes only that parent's edge; other paths can preserve membership. |
| A compromised bootstrap member retains axiomatic authority | Other members cannot remove that axiom from the same bootstrap. There is no quorum limiting one root's authority to ACCEPT. If an applicable LEAVE cannot be obtained, removal requires a new community bootstrap/tree. This concerns a bootstrap target, not the ephemeral genesis signer, which is reserved from ordinary actions. |
| The four-word seal has only 32 bits | Collisions are possible before any particular population threshold; the probability of at least one random collision reaches roughly 50% near 77,000 uniformly distributed seals. A chosen victim's seal takes an expected `2^32` independent candidate keys to match in the generic model. That search need not run the IAM KDF. Use the full key for identity; the seal alone cannot authenticate an unknown person. |
| Cross-actor causality is not authenticated | Prev orders one actor's chain. The ready-record `(m, id)` order is deterministic, but signer-supplied times and hash tie-breaking do not prove causality between actors. Same-minute dependent actions can fail, and some cross-actor backdating remains possible. |
| Forks and clock mistakes can break a suffix | Authenticated siblings invalidate both branches in the selected anchor. A backwards-time link blocks its descendants. Honest signers must coordinate heads and pending signatures. Selecting replacement history is an explicit authority decision, not an automatic repair. |
| The selected history is a trust input | Core validation does not decide which anchor is authoritative. The optional anchoring profile trusts a pinned publisher, freezes on known publisher equivocation, and cannot prove that an offline snapshot is newest or that no undisclosed fork exists. |
| Endpoint compromise bypasses phrase hardening | Malware, an untrusted signing implementation or disclosure of the incantation/seed can give an attacker signing control. A more expensive KDF does not protect an already stolen secret. IAM supplies no hardware, operating-system or coercion protection. |
| Graphs can expose relationships | Reused keys are linkable across accessible graphs. IAM provides neither anonymity nor Sybil resistance. ACCEPT is unilateral. LEAVE does not erase retained records or copies held by others. |
| Resource limits do not guarantee availability | Bounded queues, quarantine and caches are required host controls. They can refuse work or lose pending data under load; they do not make a hostile network available. The reference tools are not a production admission or resource-management service. |

The KDF increases guessing cost; it does not create missing secret entropy.
Parameter choices and their costs need a stated deployment budget, as discussed
in [RFC 9106, sections 4 and 7](https://www.rfc-editor.org/rfc/rfc9106.html#section-4).
No IAM profile is currently claimed to defeat an attacker merely because it
is called a corporation or a state.

## Review and implementation evidence

The maintainer directed development with OpenAI Codex and its AI agents.
Project reviews, the 1.1 revisions, the Python reference code, the Node vector
generator and tests were produced in that shared workflow. Different languages
and cryptographic code paths are useful cross-checks, but do not make the
authors organizationally independent. See [review provenance](reviews/README.md).

The available records do not establish a completed independent third-party
security audit. Supplied critiques are preserved with their provenance limits.
Passing the published vectors is evidence about those cases, not proof of
specification completeness or production security. An [outside implementation
brief](proposals/independent-implementation.md) requests additional evidence.

## Before identity enrollment

IAM 1.1 currently defines only identity KDF v1. P0/P1/P2 are discussion labels,
not supported profiles or verified protection levels. Resolve the [derivation
decision](proposals/derivation-profiles.md) before a product commits users to a
derivation. A later KDF change must not silently regenerate their identities.