Rod,

First things first. AES using 128 key length has been accepted by the NSA as acceptable for all USG information up to the level of Secret so that is probably sufficent for your needs.

In respect of your app and data, using a FoxPro app means that anyone with access to the program will have access to the key simply by inspecting the code. Anyone with access to the dbf table will have access to all the information contained within it. The cracking of the encrypted field will not, imo, present too much problem and especially not if they have access to the program as well.

My first step would be secure the code using commercial tools like ReFox, MoleBox, Armadillo, or Thinstall. They can all be cracked but it makes it more difficult and requires only some money and a few minutes of time. Secondly, secure all the relevant tables using Cryptor or Netlib. Again these are very fast solutions to implement and require virtually no code changes.

The above two steps quickly provide code and table protection. The tables are always encrypted and the code is protected. The program should have, obviously, login procedures for identification and authorization otherwise a person who steals both the table and the program still gets access.

The next step would be to ask how you syncrhonize the data between locations. What communications method is in place? Is the channel secure? Is the data encrypted during transfer?

http://www.refox.net/
http://www.molebox.com/
http://siliconrealms.com/index.shtml
http://www.thinstall.com

http://www.xitech-europe.co.uk/Cryptor.html
http://www.netlib.com/file-encryption.asp



>Hello Jos,
>
>Our key is generated by a function in our app ... hence the key is never stored anywhere. A function call provides our app with the key. I do realize that the app could be reverse engineered but I guess we haven't been as concerned with that as much as we have the data being stolen. Maybe we should be? We've had a hard time figuring out what is realistic threat and what is overkill.
>
>Right now, the chance of the database being stolen is much higher than we feel comfortable with. We are working on ways to fix that. Our system is an international system with data synchronized between locations. Although our location has very good security, some of the others do not. Those are the places we're more concerned about.
>
>We use FoxPro free tables so security is basically nill. All our security is built into the app. So, if someone bypasses the app and opens a dbf in Word, viola, they have complete access to the data. (Hmm, should I be saying all this on a public forum?) :)
>
>From whom is the data to be protected? Definitely anyone outside our organization. Part of this is that we want to demonstrate a concentrated effort to protect our member data so that if something does happen (databases get stolen) we are 1) more comfortable that the data won't be compromised and 2) safer from prosecution in that we made every reasonable effort to protect the data.
>
>The data does need to be protected from individuals inside the organization who don't have permissions/rights to view the data. AES-256 is overkill for that scenario but serves the purpose anyway and definitely goes a long way toward protection from outside sources.
>