OI Version 9.4

Using Encryption within BFS / MFS… Got the READ_RECORD, READO_RECORD and WRITE_RECORD done. I only encrypted the "RECORD DATA". Should I Encrypt the "RECORD ID" too?

Since I am using the ICONV / OCONV "VB" and RTP90, it should not matter if the "RECORD_ID is encrypted… Or does it?

Also what about INDEXES? I would believe the INDEXES contain data about both "RECORD DATA" and RECORD_ID, so they should be encrypted too, right?

So has or can anyone offer info so as to avoid issues doing this. I have already tested the BFS / MFS routines and they are working fine. Just wanted some info so as to avoid issues on encrypting the "RECORD_ID" and all index data.

Like I said… all is good going in and out (read / write) (encrypt / decrypt). Just not sure on issues unforeseen. As always I appreciate all suggestions.

Richard,

1) Encrypting keys should be fine, but be careful of the following:

Make sure there are no system delimiters in your keys, especially @fm or this will screw up select lists

Make sure there are no collisions (this is only a problem with one-way hashes, and not two way schemes like RTP90)

I can't really answer whether you need to encrypt the key or not - that's down to your requirements - does it contain sensitive information? Is it likely that it could be parsed out of the raw LH file and used to identify and extract an encrypted data record more easily? It all depends on how paranoid you are, though if you're using RTP90 then it's not high level so it sounds like you're using it more for obfuscation rather than keeping state secrets :)

2) Indexing:

If you place the encrypt MFS on the data file your raw data from indexed columns will be stored in the index records in the !table in clear text. You can't put the MFS before SI.MFS on the data table otherwise the correct data will not be indexed as it can only work with what it's passed, and if that's encrypted already SI.MFS won't be able to pick out the correct index values. What you need to do therefore is add the MFS to the !table itself so that the index records are stored encrypted but returned unencrypted to the procs that use them like Btree.Extract etc. I don't see any problem with this approach as long as the MFS is well written and conforms to the specs :)

Regards

Carl Pates

FWIW, encryption can affect performance.

If your data is mostly mundane with a few sensitive items that are not often updated, you can look at isolating the sensitive data from the mundane, only encrypt the sensitive . The application only pays the price of encryption / decryption when it needs to update or store the sensitive information.

For example, if field 3 is sensitive, replace it with a token such as a guid, have an encrypted table keyed by a one-way hash of the token, use a custom conversion to obtain the value from the token when it is needed. Most of the time the the token goes for a ride without ever being used.

That is CUTE!

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

View this thread on the Works forum...