Creo que este artículo puede ser muy relevante para lo que está haciendo. Si de hecho desea "anonimizar" los SSN por razones de seguridad y responsabilidad legal, simplemente codificarlos no es suficiente.
Simplemente codificarlos sería un proceso completamente determinista, por lo que para "enmascarar" efectivamente los SSN individuales, el proceso debe ser aleatorio. De lo contrario, podría simplemente aplicar fuerza bruta a través de todas las combinaciones posibles de SSN (lo que requeriría mucho menos trabajo que tratar de aplicar fuerza bruta a la función hash) y buscar un valor coincidente.
Para ver por qué esto es así, tome el ejemplo más simple de que un SSN podría tomar solo dos valores, 0 y 1. Independientemente de la calidad y la fuerza de la función hash, al final solo habrá dos resultados posibles y es fácil de ver. cuál es cuál.
Es el viejo juego de por qué no deberías hacer hash, p. contraseñas directamente sin realizar algún preprocesamiento en ellas primero. Los datos subyacentes simplemente no contienen suficiente entropía y, por lo tanto, serán un objetivo fácil para las búsquedas en una tabla precalculada.
En el momento en que sus SSN se vuelvan privados y confidenciales (no están en todos los países, así que disculpe mi estúpida pregunta en los comentarios :), las mismas mejores prácticas que también se usan para el almacenamiento de contraseñas también deberían aplicarse a su caso particular, es decir, un lento algoritmo hash adaptativo que compensa la falta de entropía inicial como bcrypt, scrypt y PBKDF2 (que ya recomendaba Marcus Adams).
