Encryption Mode (not included in filePro Lite)

The encryption mode used is CTR mode.

The key is the character sequence used as the primary base to encrypt or decrypt to desired field. A key is in some ways similar to a pass phrase used to validate a system login. The key should be not easily guessed, it should be protected as you would protect a login pass phrase. The encryption key has a required length ( Block Size ) that differs among encryption methods. Depending on the encryption method used, the key length can either be within a specified range or the key is a fixed length and must be one of a set of valid lengths. The following table provides Block Size and acceptable key ranges values allowed for each supported encryption method.

The length of the key must be between the specified values (inclusive) if a range is specified or be one of the specified values if a list of values is specified.

The encryption/decryption routines enforce this key length requirement and will exit with an error if the length of the supplied key is not valid for the requested method. There is no way encrypted data can be recovered if the key is lost - this point can not be emphasized enough.

Nonces are generated by filePro and are created by constraining the output of the Yarrow pseudo-random number generator to printable non-control characters (so they can be easily stored). Entropy is currently added to the Yarrow generator by manipulations of the system clock. The nonce used for encryption must be provided at decryption time but it introduces no cryptographic weakness if the nonce is known (as long as the key is kept secret). It does introduce a cryptographic weakness if the same nonce is reused with the same key.

The "nonce", sometimes called the initialization vector, is used to transform the key into the symmetric key that is actually used to transform the data. While the key must be held secret in order to protect the data the nonce can be revealed without compromising the security of the encrypted data. While the key can and usually will remain constant while encrypting multiple sets of the same type of data, the nonce should change for each separate set of data. Reusing the same nonce with the same key to encrypt multiple pieces of data weakens the encryption and makes it more susceptible to cryptographic analysis and exposure of the encrypted data. The same key and nonce used to encrypt the data must be supplied at the time of decryption in order for the data to be successfully decrypted.

An example of this might be encryption of data in medical records. You might use a nonce built from the patient ID and social security number. Then, a unique nonce could be generated (and regenerated) in processing from data which would not change stored in the record. If some of the nonce data might possibly change it wouldn't be to hard to build a routine to retrieve the encrypted field, decrypt it with the old data, re-encrypt it with the new data, and store it.

The length of the nonce for the encryption method has to match the block size for the encryption method.

For example:

Selecting Blowfish as the method would mean that the nonce would have to be 8 bytes and the key could be any length between 8 bytes and 56 bytes inclusive.

Selecting AES as the method would mean that the nonce would have to be 16 bytes long and the key would have to be 8, 16, or 24 bytes long.

Selecting 3DES as the method would mean that the nonce would have to be 8 bytes and the key would have to be 21 bytes.