FiveTech Software tech support forums

After some testing, it seems the only special "tricks" needed for working with Blowfish are that A) all fields must be of char data type; B) all fixed-length fields to be encrypted in a DBF must be 8 bytes long or some multiple of 8 bytes in length (16, 24, 32, etc.), and C ) the last byte of each field must be reserved for Blowfish's checksum code. So the actual data, besides being of character type, must be restricted to either 7, 15, 23, 31 etc. bytes in length. If space is not reserved for the checksum, then Blowfish will automatically add another 8 bytes to the data, which will get truncated when stored in the DBF, thereby losing the checksum - without which the data cannot be decrypted. Because memos are of variable length, the checksum byte won't get cut off, so no special data length is required for memos.

Before either encrypting or decrypting with Blowfish, you first have to get a key for each field with code like this: cBfkey := hb_blowfishkey("FiveWin=Mother'sMilk"). Of course, each field can have a different key for heightened security.

Thus to encrypt data in an 8 char field, the code is: MyField := hb_blowfishencrypt( cBfkey, SUBSTR(MyField,1,7) ) where MyField must be a char field. If encrypting a memvar, use SUBSTR(MyMemvar,1,7) in the code to provide the proper 7 char data limit for data going into an 8 char field. For larger fields/memvars (that will be saved to fields), all with lengths that are some multiple of 8, then instead of a limit of 7, use a limit number that is 1 less than the field/memvar length to allow space for the checksum.

To decrypt a field, no special length coding is needed. So the code is: MyField := hb_blowfishdecrypt( cBfkey, MyField). In the decryption, Blowfish will automatically drop the checksum byte leaving just your clear data.

If you need to work with logical (.t. or .f.) data, then it will have to be converted to char data, but stored in an 8 byte field. Encrypt as if you have 7 bytes of data (6 bytes are blanks) reserving the 8th byte for the checksum. When retrieved and decrypted, convert back to logical data type for processing. Likewise, numeric data - to be encrypted - must first be converted to char and then stored in a field that is 8 char long or some multiple thereof. Again, use SUBSTR(MyData,1,7) - or whatever appropriate length as noted above - as part of the encryption coding.

The earlier problem I posted on another thread about experiencing excessive processing time for encryption/decryption with Blowfish was caused by my error in handling the encryption of memos. After eliminating my error (I had incorrectly assumed that each memo field had to have a fixed length that was some multiple of 8 bytes), then processing was handled in a flash - despite the Blowfish key length of 4168 bytes.

Reviewing some of the comments made in other threads about encryption, I offer these observations:

1. Blowfish is an encryption system that is approved in the USA for health-related applications requiring HIPAA compliance. Some of the other encryption systems mentioned here may not have been certified for approval under HIPAA requirements.

2. Blowfish offers field encryption. Thus, you can encrypt only the fields that need to be encrypted. This is useful for network environments and for enabling the user to design adhoc reports utilizing the unencrypted data in a table. This is especially important where the user has to periodically run summary data reports for funding agencies, where the design of the reports must be flexible and thus user-changeable. Usually the data needed for such summary reports doesn't need to be encrypted, so being able to encrypt just selected fields (like fields containing individual people's identifying info such as name and address, etc.) is important.

3. I'm not aware of how to use Blowfish to do whole-file encryption.

4. Blowfish can easily encrypt memos (meeting Enrico's requirement).

5. Blowfish requires that any fields to be encrypted must be char fields and must be 8 bytes long or some multiple of 8 bytes long - except for memo fields, where no special data length is required. However, in fixed fields, the user's data must be limited to one byte less than the field length. The last byte is reserved for the Blowfish checksum code.

6. Answering James' earlier question about how to determine if data in a file has already been encrypted, one can assign a specific 8 char field to contain some indicator (when in the clear) that means the data is unencrypted, like "unencrp". This field gets encrypted when all other fields get encrypted, and likewise decrypted if the table gets decrypted. On opening the table, you check this field to see if it contains "unencrp". If it doesn't match then the table is encrypted.

An additional point on Blowfish encryption usage:

7. When encrypting/decrypting multiple records at once via Blowfish in a looping process like DO WHILE, you must first delete any controlling compound index, like a compound CDX index, or else the encrypting/decrypting will GPF after processing a few records or maybe even just one record. But if the controlling index is first deleted, then the encryption/decryption performed, and afterwards the index rebuilt, the process will not GPF. In this case, the DO WHILE is processing in natural record order. This index deletion/rebuild is not necessary if just encrypting/decrypting a single record at a time - this won't GPF.

Some test code illustrating how to work with Blowfish can be downloaded from...

http://www.leadersoft.com/files/BfTest.zip