Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 23 GitHub source documents. All source documents are searchable here.
Last updated: October 7, 2025
This content is meant to be consumed by AI agents via MCP. Click here to get the MCP configuration.
Note: In rare cases it may contain LLM hallucinations.
For authoritative documentation, please consult the official GLEIF vLEI trainings and the ToIP Glossary.
A rainbow table attack is a password-cracking method that uses precomputed lookup tables (rainbow tables) to reverse cryptographic hashes and recover original passwords from stolen hash databases, exploiting systems that store passwords as unsalted hashes.
A rainbow table attack is a cryptographic attack technique that exploits precomputed tables mapping common passwords to their corresponding hash values. When attackers gain access to a database of hashed passwords, they use these special lookup tables—called rainbow tables—to quickly reverse-engineer the original plaintext passwords without computing hashes in real-time.
The attack specifically targets password storage systems that rely solely on cryptographic hash functions without additional security measures like salting. Rainbow tables enable attackers to determine which original password produced a given hash value much faster than brute-force methods.
Within the KERI/ACDC ecosystem, rainbow table attack resistance is a critical design consideration for several components:
When implementing private ACDCs, the UUID field (u) MUST contain at least 128 bits of entropy to provide adequate rainbow table resistance. This high-entropy requirement ensures that even if an attacker knows the schema and can compute potential SAIDs, the computational cost of precomputing rainbow tables for all possible UUID values is prohibitively expensive.
For blinded revocation registries, the shared salt between issuer and issuee must be:
Public ACDCs (without UUID field) are vulnerable to rainbow table attacks if:
Implementers should use private ACDCs whenever attribute values might be guessable or when the combination of schema + attributes creates a searchable space small enough for rainbow table precomputation.
Acceptable entropy sources for rainbow table resistance include:
/dev/urandom, CryptGenRandom, etc.)Unacceptable sources include:
Private ACDCs include a high-entropy UUID field (u) that functions as a salty nonce to prevent rainbow table attacks. Without this UUID, an attacker who knows the schema and SAID of a public ACDC could potentially use rainbow tables to discover the ACDC's contents by precomputing hashes of likely attribute combinations. The UUID adds sufficient entropy (≥128 bits) to make such precomputation attacks computationally infeasible.
In blinded revocation registry implementations, the transaction event log (TEL) state is protected using salty nonce blinding factors. The specification explicitly states that "no information can be obtained via a rainbow-table-attack because the hash has enough entropy added to it." This entropy addition through shared salts between issuer and issuee prevents attackers from precomputing credential state values.
The attack mechanism exploits how applications traditionally store passwords:
KERI/ACDC systems defend against rainbow table attacks through: