Asymmetric and symmetric key storage

I'm working on an ajax portal and I need some advice. My client wants it fairly secure but doesn't want to deal with ssl. There is no ultra sensitive data to store so I'm doing a custom "handshake" when the page initializes.

Since every session I'm dealing with 2 new sets of asymetric key and some symetric one as well, I want to know how you would handle these keys. This is probably going to reside on a shared host and I've read everywhere that the session file can't really be trusted in that case...

Right now I'm storing some info in the session file pointing to the right keys, which are in a database. Everything works just fine as it is (well, I think :))... Now I want to delete the keys from the database when the user session ends, so I don't end up with tables filled with useless keys.

Even if I knew it is BAD, I tried an ajax call when closing the window/browser... this is indeed BAD and inconsistent, so this option is out of the way. I also thought about a cron job to erase every key dating more than a couple of days, but it kind of feels "unfinished" to me...

My question is: I'm wondering how does ssl handles its keys? Where are they stored while the user session lasts? How do you deal/would deal with this?

EDIT

Yep, I should have known that this question would lead to that.

I know that ssl would be the best option and it is to my own regret that I have coded my application. I'll talk some more to my client about it, but I have little hopes. If he still wants to go http, I won't risk to loose the contract to proove my point and I'll have an alternative to protect its unsensitive data (login info kinda, no credit card...).

Yes, "fairly secure" is appropriate since no system is completely secure. "Fairly secure" means that a wannabe hacker who just downloaded wireshark, or watched a video on youtube to do a man in the middle a开发者_开发百科ttack won't be able to get in. I would say that it is already a lot better than all the multi billions gaming companies who recently been put to shame by some teenagers.

The correct answer goes to Nasko who answered part of my question and made some obvious recommendation, without being cocky at that.

'Secure' is a binary state. There is no such thing as 'fairly' secure.

Your hope of implementing something as cheap and effective as SSL is approximately zero. Don't bother. Unless the client is the US DoD he can't afford it anyway.

SSL generates symmetric key for each handshake it completes and stores it in memory (unless the session cache is written to disk).

That said, I would suggest to avoid doing your own crypto protocol, since you are bound to make a mistake. Even the best crypto people make mistakes, so I wouldn't recommend anyone doing it for the sake of doing it.

Figure out what the problems are that your client perceives with SSL and address those. This way you use standard technology that is proven to work and your customer is happy at the end.