Encryption puzzle

[chootoi2]

I don't know much about encryption, so I've been banging my head against this
for a few days now. Here's the situation: I'm working on an online application,
from which I'm collecting and storing sensitive data (social security numbers).
I want to encrypt that data to keep it safe. However, that data also needs to
be editable by the user who supplied it. Easy, right? I just use the
applicant's password as the key for encrypting the data in the database (MySQL.
I'm running RedHat and CF MX 6.1). It's only editable when the user supplies
the password, which is used to decrypt the data while the user is working on
it. That makes sense to me. But here's the thing. I only want the user to be
able to edit until a certain point in the process when the finished application
is submitted, at which time the data needs to be 'locked.' At that point, I
need the data to be editable by an administrator, but NOT the original user. In
other words, I need to be able to automate the decryption of the user's data
and then re-encrypt it so that it's no longer available to the user. I don't
want to store any keys on the server, obviously. So how do I do this? It seems
like I can use the password during the user's log-in session to decrypt the
data at the point they click the 'I'm completely done and now the data is all
yours' button. Even if that's right, how do I then automatically re-encrypt the
data using an administrative key without having that key stored on the server?
The question reveals my lack of understanding here, I'm sure, but even if I'm
thinking about this all wrong, does anyone have suggestions on how it *can* be
done? Thanks, P

[Nuclear.Kitten]

I've written an app that does store the keys, BUT they're hidden within a LARGE
string of numbers. A fake seed so to speak. So if your db was stolen it would
be pretty hard to figure which set of numbers you used to get the seed. Most
crackers would think you used the whole string and probably move on to a easier
target or waste their time figuring out which numbers were used. The thing that
makes this pretty secure is each record has a different seed and crack one
record would be amazing, but to crack them all is probably require pentagon
level skills. I'd give you the source code, but then the method wouldn't be
secure. I've probably said to much already, but wts SSN's should be protected
at all costs. I'm really not sure how the encryptoin gurus would look at this
since most frown on obfuscation, but at this point you need to secure that
content asap. Good Luck in any event.

[Mike Greider]

Use a public/private encryption. When a user clicks that they are done, encrypt
the SSN with your public key. Than you can decrypt it later with your private
key. You can key your key offline in a seperate safe location. Check out pgp or
equivalent programs.