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: owner-openssl-***@openssl.org [mailto:owner-openssl-***@openssl.org]
On Behalf Of Ted Byers
Sent: Thursday, March 28, 2013 6:40 PM
To: openssl-***@openssl.org
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 openssl-***@openssl.org
Automated List Manager ***@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-***@openssl.org
Automated List Manager ***@openssl.org