Remember that any indices generated from encrypted fields won't be valid, either. And because these fields don't relate to the actual data, it'll be harder for the database administrator and developer to debug problems. As a matter of fact, unless you have a mechanism to decrypt your database data on the fly, any query that uses encrypted fields to search or order data will cause trouble.
Database software, such as Sybase's, lets you create encrypted databases. Access requires a key, which also lets you decrypt on the fly. This all-or-nothing encryption, with the entire database encrypted or not, can cost you in overhead. However, Sybase offers helpful tips for getting around the problem. And though the all-or-nothing approach is beyond the scope of this article, it may prove a viable option in high-security situations, given recent improvements in hard-drive speed and capacity.
Trading Spaces
Disk space is an issue with database encryption because encrypted fields are larger than unencrypted fields. They're a little larger for textual data and a lot larger for numeric and binary data--data in a numeric field, for example, gets encrypted one byte at a time and grows to two bytes when it's encrypted. RAID arrays, SANs and network-attached storage devices give you plenty of space, unless you have a massive database of millions of rows, each row with hundreds of bytes.
Most database-encryption mechanisms present encrypted data as characters, one character per hexadecimal digit. That's a big increase: When encrypted, a 4-byte integer becomes an 8-byte character string. Most encryption algorithms use 64-bit DES, so your 4-byte (32-bit) integer becomes a string of 16 encrypted characters. Bottom line: When building your disk capacity for database encryption, anticipate that your data will triple or quadruple in size. In addition, make sure you have sufficient logical-memory space.