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