An Ounce of Encryption is Worth a Pound of Cure—Part 3

Spotlight on Synergy/DE 9.3: Data Encryption
by John Brunett, Senior Software Engineer, and Mark Cooper, Lead Systems Programmer

This is the third article in a three-part series about the new encryption features in Synergy/DE 9.3. Part 1 and part 2 discussed network encryption; in this final article, we’ll turn to data encryption.

While network encryption encrypts data transferred across a network, data encryption encrypts data at the application level. When you implement data encryption in your application, you can encrypt a record or field using a passphrase. The two main Synergy/DE encryption routines are DATA_ENCRYPT and DATA_DECRYPT. Once encrypted, this data can be written to a file or even transferred across a network. How is this different than the network encryption we’ve been discussing? The primary difference is that with data encryption, the application and ultimately the user maintain complete control of the encrypted data, which means the data is still protected once it reaches the other side. With network encryption, the data is only encrypted while it’s being transferred.

Let’s take a look at how data encryption can be used in an application. Perhaps you have a data record containing a customer’s social security number that you’d like to store securely. First, you need to decide what cipher algorithm to use, 3DES or AES. Assuming your SSN field is 9 bytes in length, you’ll need a bigger area to store the encrypted data. 3DES requires an area that’s a multiple of 8 bytes, and AES requires an area that’s a multiple of 16 bytes. You might handle this by adding a pad field after the SSN field, so that the combined size is the correct multiple, with an overlay field that encompasses both fields. You would then use the overlay field as the destination when encrypting and as the source when decrypting.

But if you happen to have a field that’s exactly a multiple of your cipher block size, you can’t just encrypt it back into the same field! Because of the padding that’s enforced by the cipher algorithm, it will require one additional cipher block to encrypt. However, if you know the size will always be an exact multiple of the cipher block size, you can tell the cipher routine not to pad, in which case you can then encrypt the field directly in place without changing the record. Turning padding off is only an option when the source field is exactly the same size as your cipher block size; otherwise, padding is required. If changing your record structure is not a viable option, and the field is not the last field in the record, you might consider encrypting the field and enough of the following non-sensitive field(s) to satisfy the block size multiple with no padding. You just need to ensure that you decrypt the field before you attempt to access the non-sensitive fields(s) that follow.

If your application uses UI Toolkit, you need to be careful when displaying windows containing encrypted fields. Fields that have not been decrypted first must be suppressed or masked.

Once you’ve decided how to format your encrypted data, you need to decide which encryption options you want to use. You may want to supply your own generated salt and initialization vector (IV   for key strengthening. The passphrase supplied by the user generates an encryption key to encrypt and decrypt the data. By adding different salt and IV values, using the same passphrase will generate a different encryption key that results in cipher text less susceptible to attacks. You can use the Synergy/DE DATA_SALTIV routine, which uses a cryptographic PRNG (pseudorandom number generator), to create appropriate salt and IV values. Note, however, that when salt and IV are used to encrypt some data, the same salt and IV are required to decrypt that data. Because of the way the encryption routines use the salt and IV, there’s no need to keep them secret. Storing them with the encrypted data is a safe option.

Not surprisingly, in addition to the same salt and IV being required to decrypt the data, the same passphrase used to encrypt the data is also required. One thing to note, though, is that even if the wrong passphrase, salt, or IV is used to decrypt the data, the DATA_DECRYPT routine will not fail; the data that gets returned will just be less desirable (i.e., random data).

Finally, the last and probably most important thing to think about is how to manage passphrases. Due to the sensitive nature of passphrases, this is ultimately a security-level decision. However, here are a couple of things to consider if you decide to trust the user to choose the passphrase:

• If the user forgets the passphrase, the data is forever unrecoverable.
• A user can make a typing error (and not realize it) when selecting the passphrase, thus putting you in the same predicament.

A better, safer option may be to programmatically read passphrases from a file. If you maintain a file of known passphrases, you can encrypt this file with a single master passphrase. Then, rather than having users type in a passphrase that will encrypt valuable data, they will be typing a passphrase to decrypt the passphrase file itself. A wrong passphrase entered by a user can thus be caught immediately, before potentially damaging application data. Note again, however, that any passphrase provided will perform as if the data has been successfully decrypted. To ensure the correct passphrase has been acquired, consider including a well-known phrase that can be decrypted and compared against before retrieving the actual passphrase. Then, maintaining the passphrase file becomes an administrative task.

For more information on data encryption, see “Data encryption” in the “Welcome to Synergy Language” chapter of the version 9.3 Synergy Language Reference Manual. Information about the routines DATA_ENCRYPT, DATA_DECRYPT, and DATA_SALTIV can be found in the “System-Supplied Subroutines, Functions, and Classes” chapter of the same manual.

We hope these new Synergy/DE encryption features will make it easier for you to enhance application data security as your users become more security conscious.

For more information about all the new features in Synergy/DE 9.3, visit our Web site.