>A secure hash of the fields you were talking about would make it possible to lookup when given the correct information, but impossible to reverse. Think about

>A secure hash of the fields you were talking about would make it possible to lookup when given the correct information, but impossible to reverse. Think about the inputs of the mechanism you just described though. Presumably the goal of the "secure hash" is to prevent government workers from grabbing samples of specific people to do whatever with, so let's break it down. To calculate this hash you apparently need: 1. The name. If you're going after a specific persons sample, you already know this. 2. The date of birth. I don't know when this program started, but if you're alive today you definitely aren't more than 43,830 days old (365.25 * 120). 3. The hospital. I have no idea how many hospitals exist or have existed in California, but lets say there's been 100,000. So the total number of possible hashes given only the name is 4,383,000,000. Sure, you could salt it as well, but the people we're trying to defend from have access to the DB and thus the salt, so we gain nothing from that. Here's some hashcat benchmarks: https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40 https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27... Looks like 1000MH/s is a reasonable rate to be able to process sha-512 hashes, so according to that benchmark you should be able to generate the complete rainbow table in about...4 seconds. It's probably longer given drive speeds and such, I've never actually tried to do what I'm describing, but it does seem like a less-than-one-work-shift process to calculate the hash of a specific person on commodity hardware if that's the only three inputs required. If that's the case, hashing it hasn't made it anonymous.