Myślę, że ten artykuł może mieć duże znaczenie dla tego, co robisz. Jeśli rzeczywiście chcesz „anonimizować” numery SSN ze względów bezpieczeństwa i odpowiedzialności prawnej, samo ich haszowanie nie wystarczy.
Samo ich haszowanie byłoby procesem całkowicie deterministycznym, więc aby skutecznie „zamaskować” poszczególne numery SSN, proces musi być randomizowany. W przeciwnym razie możesz po prostu użyć metody brute force przez wszystkie możliwe kombinacje numerów SSN (co byłoby znacznie mniej pracochłonne niż próba brutalnego wymuszenia funkcji skrótu) i poszukać pasującej wartości.
Aby zobaczyć, dlaczego to się trzyma, weźmy najbardziej uproszczony przykład, że numer SSN może po prostu przyjąć dwie wartości, 0 i 1. Niezależnie od jakości i siły funkcji skrótu, w końcu będą tylko dwa możliwe wyniki i łatwo to zobaczyć który jest który.
To stara gra o tym, dlaczego nie należy haszować m.in. hasła bezpośrednio, bez wcześniejszego ich wstępnego przetwarzania. Bazowe dane po prostu nie zawierają wystarczającej entropii i dlatego będą łatwym celem dla wyszukiwań w wstępnie obliczonej tabeli.
W chwili, gdy Twoje numery SSN staną się prywatne i poufne (nie są one dostępne w każdym kraju, więc wybacz moje głupie pytanie w komentarzach :), te same najlepsze praktyki, które są również używane do przechowywania haseł, powinny również mieć zastosowanie w Twoim konkretnym przypadku, tj. powolny adaptacyjny algorytm mieszający, który kompensuje brak początkowej entropii, takiej jak bcrypt, scrypt i PBKDF2 (co było już zalecane przez Marcusa Adamsa).
