The question to ask is: should the server be able to access the value ?
If the server must be able to access the value, then the "encryption for storage" is just an illusion. An attacker who gains control of the server will be able to read the values, since such an attacker can do whatever the server can do. You might want to apply some "encryption" on the database itself if you consider the database to be "less secure" (or "distinctly secure") than the server (i.e. you envision an attacker who gets a read-only peek at the database, e.g. by stealing a backup tape); in that case, you'd better apply a whole-database encryption system, which will be more comprehensive, simpler, and more efficient, than simply concentrating on your two values (in Microsoft's SQL Server, this is called Transparent Data Encryption).
If the server must not be able to access the value, then the client application must do the encryption and decryption -- which raises the issue of key management. The client application must have a user-specific key which it stores and then uses to decrypt and encrypt the data. There is ample room for blunders here, so you'd better choose a well-vetted protocol and format for that. One way is to encrypt the data with a key derived from a user password; the OpenPGP format has some support for that.