Initialization Vector (IV)
An Initialization Vector (IV) is a random or unique value combined with an encryption key during the encryption process to ensure that encrypting the same plaintext twice produces different ciphertexts.
Definition
An Initialization Vector (IV) is a random or unique value combined with an encryption key during the encryption process to ensure that encrypting the same plaintext twice produces different ciphertexts. The IV is one of the foundational concepts of modern symmetric encryption: without it, identical inputs would always produce identical ciphertexts, allowing attackers to identify patterns in encrypted data. The IV is not secret (it is often stored alongside the ciphertext) but it must be unique per encryption operation under the same key.
In Salesforce Shield Platform Encryption, IV handling distinguishes the two available encryption schemes. Probabilistic encryption uses a fresh random IV per record, providing the strongest security but breaking SOQL filters and sorts on the encrypted field. Deterministic encryption uses a derived IV based on the plaintext, producing the same ciphertext for the same plaintext, which allows SOQL equality matches but reveals which records share the same value. The IV choice is the central trade-off in Shield: filterability versus pattern resistance.
How IVs shape encryption security
Why IVs exist
AES and similar block ciphers are deterministic by design: same key plus same plaintext equals same ciphertext. Without an IV, an attacker observing encrypted data could identify records with the same plaintext (every Account record with Country = USA would have identical encrypted Country values). The IV breaks this pattern by mixing in additional unique data per encryption operation, so identical plaintexts produce different ciphertexts. Modern cipher modes (CBC, GCM) all require an IV; the security depends on uniqueness per encryption.
Probabilistic encryption and random IVs
Shield's probabilistic encryption generates a random IV per record. Encrypting the same Country value across two records produces two different ciphertexts. The data is maximally pattern-resistant: attackers cannot infer which records share values. The cost is that SOQL queries cannot filter, sort, or group by the encrypted field because the database cannot compare ciphertexts meaningfully. The platform handles a few common operations (decryption on output) but not the operations that require comparing encrypted values.
Deterministic encryption and derived IVs
Shield's deterministic encryption derives the IV from the plaintext value through a one-way function. The same plaintext always produces the same IV, and therefore the same ciphertext. SOQL equality matches work (find all records where Country equals USA), at the cost of revealing which records share the same value. An attacker who can see the encrypted ciphertexts can group records by ciphertext to identify Country clusters even without decrypting them. This is a known and accepted trade-off.
IV storage and key separation
The IV is stored alongside the ciphertext (or derived from it for deterministic). The IV is not secret; revealing it does not weaken security. The security depends on the key, not the IV. This separation is important for understanding what attackers can and cannot learn from access to ciphertexts: they can see the IVs, they can see the ciphertexts, but without the key they cannot decrypt. The IV uniqueness requirement is purely about preventing identical-plaintext-identical-ciphertext patterns.
IV reuse and the security catastrophe
Reusing the same IV with the same key across multiple encryptions is a serious security failure. In CBC mode, it allows attackers to detect identical plaintexts. In GCM mode (an authenticated encryption mode), it allows complete key recovery in some scenarios. Shield's design enforces unique IVs per record for probabilistic encryption and per plaintext value for deterministic. Custom Apex Crypto class code is the more dangerous surface: developers writing their own encryption logic can accidentally reuse IVs if they hard-code the IV or fail to generate fresh ones.
IVs in Apex Crypto class
The Apex Crypto class exposes encrypt() and encryptWithManagedIV() methods. The first requires you to provide an IV; the second generates one and embeds it in the output. For most custom encryption, encryptWithManagedIV() is the safer choice because it removes the IV-generation responsibility from developer code. Manual IV generation in Apex is a common mistake: developers often produce IVs from predictable sources (timestamps, counters) that reduce security.
Compliance and IV documentation
Compliance auditors sometimes ask for evidence of correct IV handling. For Shield, this is straightforward: the platform manages IVs and the documentation describes the algorithm. For custom Apex encryption, the documentation must describe how IVs are generated and demonstrate uniqueness. Reusing the encryptWithManagedIV() method simplifies this documentation; rolling your own IV generation requires more careful audit.
Use IVs correctly with Shield and Apex
The IV is a property of the encryption scheme rather than something administrators configure directly. The steps below cover the IV-related decisions during Shield rollout and the patterns for custom Apex encryption.
- Decide which fields need encryption
Work with security and compliance to list sensitive fields. Each will need a scheme decision: probabilistic or deterministic.
- Audit SOQL patterns per field
For each candidate field, check what SOQL queries filter, sort, or group by it. Fields used in queries usually need deterministic encryption to preserve functionality.
- Choose scheme per field
For low-cardinality fields where pattern reveal is acceptable (Country, State), deterministic is fine. For high-sensitivity high-cardinality fields (SSN, account number), probabilistic.
- Enable encryption with chosen scheme
Setup > Encryption Settings > Encrypted Fields. Edit each field, check Encrypted, choose scheme. The platform manages IV generation per the scheme.
- For custom Apex, use encryptWithManagedIV
Any Apex code that encrypts data should use Crypto.encryptWithManagedIV() rather than the manual encrypt(). Managed IV removes developer-side IV mistakes.
- Document the IV approach
For compliance audits, document the IV scheme per field and per custom Apex method. Auditors expect to see this documented for any encrypted data path.
- Test edge cases
For deterministic fields, test that equality queries still work post-encryption. For probabilistic, confirm that other operations (decryption on read) still function as expected.
Random IV per record. Strongest security; no SOQL filter/sort.
Derived IV. Allows equality match; reveals value patterns.
Developer-provided IV. More flexible but more error-prone.
Platform-generated IV. Safer default for custom encryption.
Store with ciphertext or derive from plaintext (deterministic). Both are standard; choose based on scheme.
- Probabilistic encryption blocks SOQL filter, sort, and GROUP BY. Reports and queries on the encrypted field break unless the field is also marked filterable.
- Deterministic encryption reveals shared values. Use only for low-sensitivity fields where pattern reveal is acceptable.
- Custom Apex encryption with manual IVs is a common mistake. Hard-coded or predictable IVs catastrophically weaken security.
- IV reuse with the same key is a serious failure. Shield prevents this; custom code must enforce it explicitly.
- Compliance auditors expect documented IV handling. Roll out includes documenting the scheme per field for the audit record.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is an Initialization Vector?
Q2. Do administrators manage IVs directly?
Q3. Why do IVs matter for security?
Discussion
Loading discussion…