Hmmm, I'm guessing that most symmetric keys are longer in length than 4K, but I'm not sure if that's true. And an encrypted key (encrypted by an assymetric key) that's then encoded with base-64 (so it's all characters that are acceptable to a cookie) is probably too big for that. Hmmm, am I reading it right in that each site should get at least 20 cookies of 4K each? Or is that off? With that, I could split up the key into multiple cookies. Not the best solution, but better than nothing.
I'll give it a try and see what happens. So here's what I'm
testing (in case anyone can see something wrong or stupid about this approach):
1. Create symmetric key "Key 'S'"
2. Create Assymetric key "Key 'A'"
3. Encrypt a copy of key "S" with key "A" ("A-S")
4. Save the encrypted key "A-S" to user's cookie
5. Attempt to retrieve "A-S" from cookie
6. Attempt to decrypt "A-S"
7. Take cookie-origin "S" (newly decrytped) and try to decrypt something with it (see if it's ok)
The reason I'm doing all this is that I want to encrypt files on the server with key "S" so that if anyone breaks into (or goes directly to) the server, they can't use/read the files. Furthermore, I want the key used to decrypt these to exist on the server ONLY in memory (so no one can find the key on the server). HOWEVER, I know that users want only what's easiest, so if they have to upload their key everytime they log in, they'll never do it. As well, I can't use client-side java/active-x because they'll be on all types of OS's and browsers so we an't guarantee they'll have it. If I can cache their key in a cookie, then they'll only have to do it the first time and it'll keep the keys off the server too. (Yes, their public keys are on the server, but the public keys can't decrypt the files, only the symmetric key they pass in). What do you think?
