Encryption Key

OK
I'm running over secure channel - It's an intranet web app with about 25 users. I'm not too sure about giving the key out to users as i'm happy they are authenticated via LDAPS and I think giving the key out to more than 1 person is a high risk. It's the same key to decrypt/encrypt. I am already retrieving the data encrypted and cahcing queries encrypted and only serving them to the user as requested.
I like the idea of possibly coming up with some kind of scrambled script!
e.g. I already store the pop mail user/pass in a scoped var which is stored like this:
#URLEncodedFormat(ascii,numeric,repesentation)# with some extra chars thrown in, then i 'unscramble' via a script.

One thing I wanted to know - is there any other way I can encode a .cfm file but not with CF's own tool? Maybe I could call in an encoded file that can only be read by java or similar.

Thanks for all the help and suggestions - I'll have a play...

Build a form to ask for the key on demand. User enters the key and the data returns 'de-crypted'. Key is stored in user's head(frightening thought). Load into a session variable and destroy on application exit or if that is a security concern, have user enter key each time encrypted data is requested. Of course you will have to distribute the key to your users.
-or-
Store key in a file on an external flash drive or users local hard drive. Depending on how many users, you could purchase inexpensive, low storage USB flash drives. Load the key on the flash drives in a plain text file named key.key and distribute the drives. User plugs drive into PC, logs into the site, when first time asked for encryption key, users clicks on the 'Browse' button and selects key file from local USB flash drive. User clicks submit, file is uploaded, read into a Session variable and deleted. Use below:

<!--- SUBMITTED FORM PAGE (action_page.cfm) --->
<!--- Check to see if the Form variable exists. --->
<cfif isDefined("Form.FileContents") >

<!--- *** If TRUE, upload the file, --->
<!--- *** create destination dir first on server --->
<cffile action = "upload"
fileField = "FileContents"
destination = "c:\key\"
accept = "text/plain"
nameConflict = "MakeUnique">
<!--- *** (can add attributes="hidden" to hide file(s)) --->

<!--- *** Read key and load into Session variable --->
<cffile action = "read"
file = "c:\key\#cffile.serverFile#"
variable = "enc_key" >
<cfset Session.enc_key = enc_key>

<!--- *** Delete key --->
<cffile action = "delete"
file = "c:\key\#cffile.serverFile#" >

<!--- *** Display Session variable --->
<cfoutput>
key: #Session.enc_key#<br>
</cfoutput>
</cfif>

<!--- USER - INPUT KEY FILE LOCATION PAGE --->
<!--- *** CreateUUID() makes each form post unique --->
<form method="post" action="action_page.cfm?<cfoutput>#CreateUUID()#</cfoutput>
name="uploadForm" enctype="multipart/form-data">
<input name="FileContents" type="file">
<br>
<input name="submit" type="submit" value="Upload File">
</form>

You can also have the key loaded onto the users local HD and use the same procedure.

If you need to update the key in future and mailing out new USB flash drives is prohibitive,
you can do the following.

Encrypt new key using PREVIOUS key and insert into database. When users enter key to
view data, decrypt new key using old key. If successful, meaning user needed to update key,
force a file download window. Instruct users to download new key to flash or local hard drive;
overwriting old key.key file.

<!--- Write your own custom code for this step: --->
<!--- -Decrypt new key using old key, if successful, load --->
<!--- -new key into current Session.enc_key variable --->

<!--- *** USE FOLLOWING TO SERVE NEW FILE TO USER --->
<!--- *** INSTRUCT USER TO SAVE FILE OVER PREVIOUS key.key FILE --->
<cfheader name="Content-Disposition" value='attachment; filename="key.key"'>
<cfcontent type="unknown"><cfoutput>#Session.enc_key#</cfoutput>

That may be best you can do. Although the value in the variable should be scrambled in some way (X-Or'ed , reversed, etc) so that someone dumping the application variables would not see the exact key and would have to dive through the code to know how to use it.

Some alternatives:

1. Have the application retrieve the key, as needed, from a trusted server via a secure connection. Rotate keys often.
   
2. Provide a tamper resistant HW dongle that supplies a key component of the key. Ideally this dongle should be restrictable to the one machine.
   
3. Don't outsource any sensitive or business-critical databases! I have never seen this work well but I have seen disastrous consequences of such foolishness.
   You can see a typical experience here:
   http://weblog.infoworld.com/dbunderground/archives/2006/05/never_outsource.html