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 encrypted. 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 him. So generalizing: 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. Marc _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
