<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: encrypting fields and email</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>Yes, aware of symmetric versus asymmetric encryption. </FONT>
</P>
<P><FONT SIZE=2>Just protecting the data during transmission can be achieved with SSL, which I do now. </FONT>
</P>
<P><FONT SIZE=2>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. </FONT></P>
<P><FONT SIZE=2>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: </FONT></P>
<P><FONT SIZE=2>- 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</FONT></P>
<P><FONT SIZE=2>- 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. </FONT></P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>Dave</FONT>
</P>
<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: seph [<A HREF="mailto:seph@directionless.org">mailto:seph@directionless.org</A>]</FONT>
<BR><FONT SIZE=2>Sent: Friday, October 01, 2004 12:38 PM</FONT>
<BR><FONT SIZE=2>To: david.falkenburger@rbc.com</FONT>
<BR><FONT SIZE=2>Cc: vivek@khera.org; rt-users@lists.bestpractical.com</FONT>
<BR><FONT SIZE=2>Subject: Re: encrypting fields and email</FONT>
</P>
<BR>
<P><FONT SIZE=2>I'm sorry, y'all seem somewhat confused about how cryptography works</FONT>
<BR><FONT SIZE=2>and it's making this discussion nonsensical. Backing up several steps...</FONT>
</P>
<P><FONT SIZE=2>There are 2 basic forms of encryption. Both start knowing the</FONT>
<BR><FONT SIZE=2>plaintext. </FONT>
</P>
<P><FONT SIZE=2> Symmetric encryption uses the same key for encryption and</FONT>
<BR><FONT SIZE=2> decryption. This means that they key is secret, and only people</FONT>
<BR><FONT SIZE=2> knowing the secret can encrypt or decrypt.</FONT>
</P>
<P><FONT SIZE=2> Public/Private encryption uses separate keys for the encryption and</FONT>
<BR><FONT SIZE=2> decryption. The public key is known to all, and is only used to</FONT>
<BR><FONT SIZE=2> encrypt things, the private key is secret and only used to decrypt</FONT>
<BR><FONT SIZE=2> things. The public key is never needed for decryption, the private</FONT>
<BR><FONT SIZE=2> key is never needed for encryption.</FONT>
</P>
<P><FONT SIZE=2>If you were only concerned about protecting the ticket content in</FONT>
<BR><FONT SIZE=2>transport, and didn't mind having the server able to read it, you</FONT>
<BR><FONT SIZE=2>would use public/private. The server would use the public keys for</FONT>
<BR><FONT SIZE=2>each recipient and encrypt the outgoing data. The clients would then</FONT>
<BR><FONT SIZE=2>use their private keys to decrypt.</FONT>
</P>
<P><FONT SIZE=2>Unfortunately, that would mean storing the data in plaintext on the</FONT>
<BR><FONT SIZE=2>server. The simple approach to solving that problem is to have the</FONT>
<BR><FONT SIZE=2>client encrypt the data before it reaches the server. However, that</FONT>
<BR><FONT SIZE=2>has several downsides. The client has to know who it's encrypting the</FONT>
<BR><FONT SIZE=2>data for, and the server won't be able to index or search data. </FONT>
</P>
<P><FONT SIZE=2>One possible approach would be to only encrypt fields that didn't need</FONT>
<BR><FONT SIZE=2>to be indexed, credit card data, for example. The client would handle</FONT>
<BR><FONT SIZE=2>all the encryption and decryption. Has the aforementioned downside that</FONT>
<BR><FONT SIZE=2>the client would have to know who to encrypt it to. You couldn't just</FONT>
<BR><FONT SIZE=2>add a watcher, without also giving them a copy of the key.</FONT>
</P>
<P><FONT SIZE=2>So now that we have a basic over view of the possibilities, what</FONT>
<BR><FONT SIZE=2>problem are you trying to solve? My experience in industry is that the</FONT>
<BR><FONT SIZE=2>most common sort of encryption is to have the data encrypted in the</FONT>
<BR><FONT SIZE=2>database, to a symmetric key in the application layer. Hardly perfect,</FONT>
<BR><FONT SIZE=2>but when the app layer needs to work with the data, there's not much</FONT>
<BR><FONT SIZE=2>else to do. </FONT>
</P>
<P><FONT SIZE=2>seph</FONT>
</P>
</BODY>
</HTML>
<P>------------------------------------------------------------<br>
<br>
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. <br>
<br>
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.<br>
<br>
============================================================ </P>