Adding Salt
Encryption is all about hiding data, and sometimes encrypted data is easier to guess if there is repetition in the cleartext. For example, a table that contains salary information is quite likely to contain repeated values, and, in that case, the encrypted values will also be the same. Even if an intruder can’t decrypt the actual values, she will be able to tell which entries have the same salary, and this information may be valuable. To prevent such a thing from happening, salt is added to the data, which makes the encrypted value different even if the input data is the same. TDE, by default, applies salt.
In some cases, patterns of data may improve your database performance, and adding salt may degrade it. With certain indexes, for example, a pattern may establish the b-tree structure and make the searching of LIKE predicates faster, as in the following query:
SELECT ... FROM accounts WHERE ssn LIKE '123%';
In this case, b-tree indexes will have to travel along only one branch to get the data, because all account numbers start with the digits 123. If salt is added, the actual values will be stored all over the b-tree structure, making index scans more expensive, and the optimizer will most likely choose a full table scan. In such cases, you will have to remove the salt from the indexed columns. You can do so by specifying:
ALTER TABLE accounts MODIFY (ssn ENCRYPT NO SALT);
Removing the salt does not significantly affect the security, so the risk of vulnerability probably ...