Hahaha, I thought I was reading my own notes there for a minute Ted. I would highly recommend the key not being on the same machine, or even in the same cluster. And honestly, not the same data warehouse for that matter. (Anything in the warehouse can be cross-tracked and traced, and you're be surprised how many times it's a worker at the warehouse who doesn't know what he doesn't know.)
My 2cents/agreeing with Ted, Paranoia RULZ. After while crocodiles. ~dodi. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Ted Byers Sent: Thursday, March 28, 2013 6:40 PM To: [email protected] Subject: Re: how to STORE encrypted string in database There is greater need for precision in what is desired. Doing a base64 encoding and storing encrypted data are two entirely different matters, required sometimes in quite different circumstances. I generally do not bother with encoding as that is not normally needed in what I do, but a 30 second search using google found this somewhat dated note: http://www.ioncannon.net/programming/34/howto-base64-encode-with-cc-and-openssl/ Perhaps someone who knows openssl much better than I can tell us if the information contained in it is still accurate. My experience with openssl is primarily in using it to create and manage certificates. Any handling of encrypting and storing data, I typically divide between whatever RDBMS I am using for a given task and perl. That said, if the only real requirement is to store encrypted data in a database, the task is dirt simple (or perhaps simpler, as a soil scientist would probably tell us that dirt isn't so simple). First, one must recognize that the encrypted data is binary data, not plain text (i.e., for the OP, what blowfish returned to you wasn't a string at all, but rather binary data, and it is a mistake to try to treat it like a string). Once you know that, then the task becomes as trivially simple as to define the field in the table that is to hold that data to be of type varbinary, with a suitable maximum length. That is fairly standard across RDBMS. It is available in all the RDBMS I have worked with (MS SQL Server, MySQL, PostgreSQL), and has been for a rather long time.The connector library documentation you use to connect to whatever database you're using ought to have sufficient documentation on how to handle varbinary data. And, of course, if you're storing encrypted data in your database, you must ensure that you are storing everything you need to be able to decrypt it (and there is little point in storing it encrypted if the key used is stored in the same database, as any bad guy who gains access to your DB has thus access to both the encrypted data and the key needed to decrypt it, but that gets to an issue in the architecture of the software system you're building, and I am sure you don't wwant me to talk about use of multiple servers on multiple subnets each separated from the others by firewalls using a blend of techniques such as IP filtering - my enthusiasm for paranoia might just get the best of me if I do .... ). Cheers Ted ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [email protected] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [email protected]
