I think I would do the following:
- "Red Herring" the field. Add another field to the table and call it SSN. Fill it with random values and then encrypt it.
- Rename this field and call it GUID. Before encrypting it use a private algorythm to re-arrange the numbers. and some random numbers to the beginning and the end of the re-arranged SSN.
- encrypt it.
Not perfect but it would take a dedicated effor to determine the correct SSN and value.
Glenn
>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
