Yes, aware of symmetric versus asymmetric encryption.
Just protecting the data during transmission can be achieved with SSL, which
I do now.
I was looking for a way so that if someone compromises the box, had access
to the code, all files, there would be no way for them to decrypt the data.
So no storing secret encryption keys in the code, in any config file for
symmetric encryption.
I was thinking along the lines of asymmetric encryption, and yes you are
correct that any user that needed to read the data would need a copy of the
public key. It could work something like this:
- any data that is filled out in a form would be encrypted using a private
key that is stored on the server. Having this key would not be of use to
anyone since it could not be used to decrypt any of the data
- when a record is displayed by the user and the field has encrypted data,
JavaScript could perhaps be used along with a copy of the public key to
decrypt the data on the client side.
Yes this makes things more complicated but it would guarantee that no one
could read the data without the public key. Using a secret key stored on the
server and using DES or AES encryption would be better than storing data in
the clear, and perhaps with field level security and tight physical access
restrictions would be enough to satisfy security requirements for sensitive
data that may be stored in the database.
Perhaps something as simple as a passphrase typed in a form that would allow
the application to decrypt a symmetric key that was stored on the server
could then be used by the application to further decrypt or encrypt data
server side would be sufficient. Actually a very simple solution. The
symmetric key could be reencrypted with a new passphrase whenever required,
say someone should no longer have access because they left the department or
the company. Hmmmm, almost doable with some glue code. Probably still some
little gotchas to work out I am sure.
Dave-----Original Message-----
From: seph [mailto:seph@directionless.org]
Sent: Friday, October 01, 2004 12:38 PM
To: david.falkenburger@rbc.com
Cc: vivek@khera.org; rt-users@lists.bestpractical.com
Subject: Re: encrypting fields and email
I’m sorry, y’all seem somewhat confused about how cryptography works
and it’s making this discussion nonsensical. Backing up several steps…
There are 2 basic forms of encryption. Both start knowing the
plaintext.
Symmetric encryption uses the same key for encryption and
decryption. This means that they key is secret, and only people
knowing the secret can encrypt or decrypt.
Public/Private encryption uses separate keys for the encryption and
decryption. The public key is known to all, and is only used to
encrypt things, the private key is secret and only used to decrypt
things. The public key is never needed for decryption, the private
key is never needed for encryption.
If you were only concerned about protecting the ticket content in
transport, and didn’t mind having the server able to read it, you
would use public/private. The server would use the public keys for
each recipient and encrypt the outgoing data. The clients would then
use their private keys to decrypt.
Unfortunately, that would mean storing the data in plaintext on the
server. The simple approach to solving that problem is to have the
client encrypt the data before it reaches the server. However, that
has several downsides. The client has to know who it’s encrypting the
data for, and the server won’t be able to index or search data.
One possible approach would be to only encrypt fields that didn’t need
to be indexed, credit card data, for example. The client would handle
all the encryption and decryption. Has the aforementioned downside that
the client would have to know who to encrypt it to. You couldn’t just
add a watcher, without also giving them a copy of the key.
So now that we have a basic over view of the possibilities, what
problem are you trying to solve? My experience in industry is that the
most common sort of encryption is to have the data encrypted in the
database, to a symmetric key in the application layer. Hardly perfect,
but when the app layer needs to work with the data, there’s not much
else to do.
seph
This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately.
Ce courrier �lectronique est confidentiel et prot�g�. L’exp�diteur ne renonce pas aux droits et obligations qui s’y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu’il contient par une personne autre que le (les) destinataire(s) d�sign�(s) est interdite. Si vous recevez ce courrier �lectronique par erreur, veuillez m’en aviser imm�diatement, par retour de courrier �lectronique ou par un autre moyen.
