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.

>Rodd, some questions:
>
>1) where is the key stored? Where does your app get the key?
>
>2) whats the chance of someone stealing the database itself?
>
>3) what access control does the database have? What is the database?
>
>4) from who is the data to be protected?
>
>A major flaw in this setup is not the choice of encryption algorithm but rather that you are encrypting an input whose format is known (SSN) and you have a large body of those inputs (i.e. sampling data). These two can be used to determine the key if the thief has the motivation to do so.
>
>
>>We're trying to beef up the security of our member data by moving from an in-house encryption algorithm to AES-256. We used to use a single key for encrypting each Social Security Number. This does mean, however, that if someone can get a hold of the key, they have access to every SSN.
>>
>>There was a benefit to a single key though. When adding a new personnel record, a search was done to ensure the person did not already exist in the system (possibly under a nickname, etc.) This was done by encrypting the SSN being added and doing a query on the existing encrypted ssns. This kept us from having to unencrypt every ssn in the system.
>>
>>What do you do? What are your thoughts? Is a single key used to encrypt all ssns with AES-256 sufficient or should each ssn be encrypted using a key generated with a unique seed value?
>>
>>Thanks for your input!
>>
>>Rodd