Random Salt & IV Generator
Generate cryptographically secure random salts, initialization vectors, and nonces. Configurable length from 8 to 64 bytes. Output in hex, Base64, or byte array format. Uses crypto.getRandomValues() — 100% browser-based, nothing leaves your device.
All random data is generated in your browser using the Web Crypto API (crypto.getRandomValues). Nothing is transmitted to any server.
Key Facts
- Source: Uses crypto.getRandomValues() — draws from OS entropy pool providing true cryptographic randomness
- Not Math.random(): Math.random() is predictable and NEVER safe for cryptographic use. Our generator uses the same API trusted by banks and security software
- Salt Purpose: Added to passwords before hashing. Ensures identical passwords produce different hashes, defeating rainbow table attacks
- IV Purpose: Added to encryption. Ensures the same plaintext encrypted with the same key produces different ciphertext each time
- Output Formats: Hex (lowercase, standard for most crypto libraries), Base64 (compact for storage), Byte Array (for direct code use)
- Recommended Size: 16 bytes (128-bit) for password salts per NIST SP 800-132. 12 bytes for AES-GCM IVs. 32 bytes for AES-256 keys
Recommended Sizes by Use Case
- Password Hashing (bcrypt, PBKDF2, Argon2): 16 bytes (128-bit) minimum per NIST SP 800-132. Stored alongside the hash
- AES-GCM Initialization Vector: Exactly 12 bytes (96-bit). The only recommended IV size for GCM mode
- AES-CBC Initialization Vector: Exactly 16 bytes (128-bit). Must match the AES block size
- AES-256 Key Material: 32 bytes (256-bit). When generating random keys instead of deriving from passwords
- HMAC Secret Key: At least equal to the hash output size — 32 bytes for HMAC-SHA-256, 64 bytes for HMAC-SHA-512
- CSRF Tokens / Nonces: 16 to 32 bytes. Longer is harder to guess but uses more storage
Salt vs IV vs Nonce — What is the Difference?
- Salt: Random data added to input before hashing. Must be unique per user/password. Does not need to be secret — stored openly alongside the hash. Used in password hashing (bcrypt, PBKDF2, Argon2)
- Initialization Vector (IV): Random data used to seed an encryption algorithm. Must be unique per encryption with the same key. Does not need to be secret — typically prepended to ciphertext. Used in AES-GCM, AES-CBC
- Nonce (Number Used Once): A value that must never be repeated for a given key. Can be random or sequential (counter). Used in authentication protocols, CSRF protection, and some encryption modes. Critical: reuse with same key can be catastrophic
Frequently Asked Questions
What is a cryptographic salt?
A salt is random data added to a password before hashing to ensure that identical passwords produce different hashes. Without salts, attackers can use pre-computed rainbow tables to crack millions of hashes instantly. Each user should have a unique salt stored alongside their hashed password.
What is an initialization vector (IV)?
An IV is random data used to ensure that encrypting the same plaintext with the same key produces different ciphertext each time. IVs prevent pattern analysis attacks. AES-GCM uses a 12-byte IV; AES-CBC uses a 16-byte IV. IVs do not need to be secret but must be unique per encryption operation.
What salt size should I use?
16 bytes (128 bits) is the standard recommendation for password hashing salts per NIST SP 800-132. PBKDF2, bcrypt, and Argon2 all work well with 16-byte salts. For AES-GCM IVs, use exactly 12 bytes. For AES-CBC IVs, use exactly 16 bytes. For AES-256 key material, use 32 bytes.
Why not use Math.random() for salts?
Math.random() is a pseudo-random number generator designed for non-security purposes. Its output is predictable and can be reverse-engineered by attackers. crypto.getRandomValues() draws from the operating system's entropy pool, providing true cryptographic randomness that is unpredictable and suitable for security applications.
Do salts need to be kept secret?
No. Salts are not secrets — they are stored openly alongside the hashed password, often in the same database column. Their purpose is not to be secret but to be unique per user, which prevents rainbow table attacks and ensures that two users with the same password have different hashes.