Client side encryption with web technologies is a myth -- any code you send to the client is visible to the client -- PERIOD, therein if the security part isn't built into the browser (and even then being built on open standards) then you don't have security. ANYONE telling you otherwise doesn't know enough about how things work to be flapping their gums on the topic.
It's like the question that comes up on web development forums every two or three weeks -- well, it's a series of questions with some variations ranging from "how do I stop people from copying my images" or "copying my scripts" or "stealing my content?"
... and it all gets the same answer; if it's that damned important and you don't want anyone else to use it, DON'T PUT IT ONLINE. Everything from there is a matter of degree.
Even HTTPS is a house of cards, and anyone determined enough sitting "in the middle" can slap that aside faster than the majority of script kiddies can bypass NTFS "security". (and yes, I made air quotes with my fingers like Doctor Evil when I said "security"... "Laser")
The only thing that even comes close is using JavaScript, but again that code has to be sent, a common value has to be present client and server side for it to be decoded, meaning it doesn't actually do a blasted thing other than waste bandwidth. This is made WORSE by the fact that such scripttardery usually has zero graceful degradation for UA's that either don't have JS or are actively blocking it due to trust issues, bandwidth issues, etc...
.... and if this is a web based system, telling users with security or accessibility concerns to go plow themselves is NOT a recipe for success. ALWAYS have a scripting off graceful degradation plan in place if it is for anything important.