Again, carefully think through the process of encrypting your data before applying encryption since you can destroy your data or at least make it difficult to properly access your data.
Don't apply edits other than "*" to stored data fields you encrypt.
Avoid encrypting fields you need to build indexes on.
Always make a backup before applying encryption.
Examples:
|
Unciphered |
Ciphered |
Edit Type |
Edit Mask |
Result |
|
123-12-1234 |
a§6¦ûf23gh |
ssnum |
nnn-nn-nnnn |
(blank) |
|
Jim Smith |
D¥§kbnmbÃÇ |
lowup |
Aaa Aaaa |
jiM SmiTh |
In the case of field having the "ssnum" edit type, when encrypting, the ciphered data will not pass "ssn" edit since the edit mask limits the field to numbers and "-" dashes as shown above. The ciphered value "a§6¦ûf23gh" will obviously not pass the "ssnum" edit. When the edit fails, the resulting value is a blank field. Only use the "*" edit type for ciphered fields to avoid this.
In the "Jim Smith" example, although the result is not as expected, the data is not lost. The lowup edit can be applied to convert the "j" back to uppercase. However, if you expect to be able to find the "Jim Smith" record by either an index search or by scanning for records, the ciphered field value "D¥§kbnmbÃÇ" is not very useful. Avoid encrypting fields that you need to search for or having indexes for this reason.