I'm not sure I follow your statement. How would you recommend that I encrypt a piece of data to store into a database? It needs to be reversible (encryption, not a hash), but does not need to be reversible on the production system (the field just needs to be decrypted before analysis, on different machines at a later time).
You could use public key encryption in a cryptosystem to store rows in a database. The "correct" way to do that would be to use /dev/random to generate a 128 bit AES key, encrypt the data with AES, and encrypt the AES key with RSA. That gets you "reversible on one server but not another".
But you're looking for something beyond that; you want "semi-reversible and deterministic". Determinism is not typically regarded as a feature in cryptosystems. Secure RSA schemes go out of their way to avoid it (read Wikipedia's OAEP article as a starting point).
Generally I think it's a very bad idea to get involved in custom cryptosystems just to store passwords.
I'm a little lost, perhaps I'm not explaining my problem too well. I really appreciate your assistance so far, and I'll try not to waste too much more of your time or space in the HN databases.
If you have a quick link about your first paragraph, that would be appreciated. I'm not sure exactly what that means -- I understand what you mean bygenerate an AES key via /dev/random (gives us nondeterministic key), then encrypt the data with AES. However, why would I use a symmetric encryption system rather than a private/public key pair? With a priv/pub pair, can't I encrypt the data on the server but not be able to decrypt it?
Again, thanks for your help. I'm not actually storing passwords -- those I properly hash. The problem is that my data app has a requirement to collect SSNs (and they need to be reversible, although that can be offline at a later date). Oddly enough, the data requirements only state encryption is required for that -- most of my colleagues are using symmetric encryption with the passphrase stored on the server itself! I was just hoping I could build a system that would be able to encrypt the data, but not decrypt it (the decryption would be handled by another machine not available to the public).
