marc at electronics-design
Jan 29, 2008, 1:30 AM
Post #19 of 30
On Tue, Jan 29, 2008 at 11:19:45AM +0200, Sim Zacks wrote:
> The problem is having the data encrypted as it is stored. Paul Stevens said
> in one of his posts that this is a *bad* idea. Is this because of the
> amount of time it would take, or is there another problem here? What I was
> thinking is that if I had the encryption library on the server then on the
> insert code for the messageblks table (only for non header parts,
> obviously) I could call the encrypt function using the public key of the
> user it is being inserted into. Then when he opens the email on his client,
> his private key would open it automatically.
> Then the only thing I would have to worry about is sniffers and people
> accessing the computer to read email, which I am really not worried about.
No, it just doesn't make sense to encrypt on the server, because both
public as private keys should be /on/ the server before communicating
with the client. It adds extra load, but no security.
If the private key is on the client side, only he is able to decrypt.
Communication and storage will be encrypted, without the database
application even having to know the message is encrypted. Also, you don't
have to be worried about sniffers anymore, because communication is
When using a /good/ email tool encryption/decryption should be done
automatically at client side, only requesting the private key password
at the user when opening it.
The CEO only has to spread a public key to his senders, and they can
(automatically using a good email client) encrypt all messages send to
1) Encrypting server-side is a bad idea, because it makes no sense.
2) Encrypting client-side is. Either use gnuPG or PGP.
3) Trusting sysadmins is just something you have to get over with.
DBmail mailing list
DBmail [at] dbmail