Re: SSN encryption

From: Ben Livengood (ben.livengood_at_gmail.com)
Date: 09/30/05 

Date: 29 Sep 2005 19:10:11 -0700

> Now perhaps you can see the logic to my request. If the SSN can be
> suitably hashed, then the original records including the SSN can be
> stored offline, and analysis can go on as before, with table merges
> easily done on the hashed SSN, but the accidental release of a record
> will not include an individual identifier, mitigating concerns about
> violations of outer security barriers.

If this is the case, then you could keep a table mapping each SSN to a
unique random key and store that mapping table safely with the original
data, while replacing each SSN with its random key for the "work" data
set. Merging new data would just involve a lookup in the mapping table
to map existing SSNs to the proper keys, and create new keys for new
SSNs. The important requirement is that the new key is totally
unrelated to the SSN it represents. The safest way is to randomly
generate a key for each SSN that's not already in the mapping table and
use the mapping table to determine if there are any collisions. If you
choose large enough keys (128 bit), you shouldn't get any collisions
either. In this case the keys aren't use to encrypt or decrypt
anything, they're just keys in the database context.

Relevant Pages

  • Re: Use IDs or strings?
    ...     If the answer to either of these is yes, ... internal IDs is not as automatic as the above requests indicate. ... If the ONLY purpose behind ID's is to join  foreign keys with the keys they ... SSN to identify Job seekers  (with dummy SSNs for job seekers with no SSN or ...
    (comp.databases)
  • Re: Choosing a surrogate key vs. a composite key - "holy war" issue or clear best practice?
    ... vs. natural keys. ... There are simple keys and composite keys (also known as complex keys ... Well the SSN example again brings up problems. ... Here is another fact involving Social Security Numbers that many ...
    (comp.databases.oracle.server)
  • Re: Snapshot Relational Data into New Tables
    ... > Read the second sentence of my previous post again:) IDENTITY is a ... > are Dept_Name and SSN in this case. ... > CREATE TABLE Employees (employee_id INTEGER IDENTITY PRIMARY KEY, ... > Without the keys I don't think you'll find a reliable set-based solution. ...
    (microsoft.public.sqlserver.programming)
  • Re: Inserting a new PK into an existing table
    ... natural keys). ... @home.com is bogus. ... But you might want to do a two-field PK with SSN and DOB. ...
    (comp.databases.oracle.misc)