Client Side Encryption and Decryption of Content

Client takes responsibility for security of stored content.

[MikeGale]

I'm looking at an application where the client saves information on a database. The saving is via a web interface and he sees it again through a web interface.

I'd like there to be security options. Especially options that don't cost us effort.

One idea is that the client encrypts and decrypts the content (which is very simple markup) on the browser.

Anyone know of techniques to achieve this?

Know where I can find out more?

(I've found JavaScript code that uses RSA and some PGP facilities but none have the easy for user to setup features I'd like.)

[txbakers]

Hi Mike and WELCOME to webmaster world.

I'm not clear on your application. When the client enters the data in the browser, should it be encrypted as he types it?

Or, do you want the data to travel across the internet encrypted?

Or should it be stored in an encrypted fashion on the database?

[MikeGale]

The essential idea is that the user takes full responsibility for his encryption. (I may well encrypt in the database but that's a separate issue.)

For that to happen encryption and decryption happen on the browser.

The design in my head is that he sees the cleartext in his browser but sends cyphertext over the wire.

I know a lot of machines have encryption on board (RSA, DES, PGP...) and an infrastructure for using it. What I don't see is a lot of people using it. Last time I tried to get that going (in email) with a few people (say 2 years ago) I found it not worth my effort. Makes sense that these facilities can be hooked into the browser but I can't find any references (other than roll your own encryption in JavaScript which could be very slow).

[txbakers]

In that case, the simplest solution is to use SSL with an HTTPS connection to the server.

[MikeGale]

No I've rules out HTTPS.

1) It doesn't satisfy the requirement that only the user can read the content.

2) It slurps up processor cycles.

[txbakers]

I guess I still don't understand what you are trying to do then.

HTTPS will encrypt it so that no one will see it en route. Yes, anyone who can successfully reach that page will see the page, but why not just add a password to the directory?

[MikeGale]

The objective is:

Only the user can see the content, not me, not the communication channel, not anyone looking into the database...

No leaks possible except at the browser, but the information is stored elsewhere.

It's entirely the user's responsibility, if he looses the decryption key/s he's finished.

[marcs]

Sounds like you'll need a browser/client-side application to handle encryption.

The server would then receive/send only encrypted data and have the browser handle encryption.

Maybe a Java application could do this?

[MikeGale]

I was hoping to find out about an already developed solution. A couple of points about this in my analysis, that may be of interest:

• The EOLAS fiasco makes developing anything inside object or embed tags a bad idea at this point in time. (Damn the eyes of stupid Patent Clerks and Judges.)
  
• There are things you can do in JavaScript, but they don't make sense to me especially when you need to connect to a certificate browser side.
  
• With an equivalent functionality in many e-mail clients I hoped that there might be a little publicised feature already in there.
  
• I'd probably go for a .NET solution before a Java approach.
  
• The ideal is something built into the browser like "EncryptingTextBox" that links to your certificate store/stores and "just does the right thing"!
  

[txbakers]

In the mySql database, you can store everything encrypted.

Register the users in the database with an encrypted password as well.

Then, the person logs on, provides the proper password and only he can read the data as it comes through the encryption filter.

[MikeGale]

Thanks for that.

Encryption in the database doesn't satisfy this need (I'm considering using my own layer of encryption within the database but that's a separate issue).

Technically I have the key and the cyphertext so I could decode the content. I don't want to be able to do that.

Even if an asymmetric technique is used I still need the content encrypted on the browser. That way no clear text on the wire at all.

Basically this is about what I'd like to have myself for completely private content. I'd like to offer something that bulletproof to users. Eventually this will be feasible, I'm hoping it is also sensible to do it now. I know a lot of users won't be able to understand it yet but they're not the target audience!

[txbakers]

well, I'm out of ideas then.

[killroy]

Why not use a simple symmetric cypher in JavaScript?

Seeems the most obvious and fullfills all your needs:
- Content is ever only decrypted at the client.
- Only use knows password
- Password NEVER travels to server
- Does not use any extra server resources
- if user looses password, data becomes unrecoverable except by brute force, depending on algorithm.

Negatives: Mostly to do with the cache, but since the results of JS executions don't really enter the cache, that shouldn't be a problem. i.e. The algorithm is puplic anyways, but useless without the cipher key.

SN

[MikeGale]

This is a great place really helpful.

Yes I looked at JavaScript approaches. (It looked as though I needed to create a BigInt class then implementing the algorithms using it.)

Issue there include:

• Implementing a certificate store. I don't want to hassle the user unduly. In other words he enters key data not at all or once only. A good approach is to get at the real certificate store for keys / passwords. Failing that I'm not sure what to use as a cookie like mechanism that is only visible client side from within Javascript (can't be seen server side).
  
• I suspect a lot of effort to implement a performant and robust algorithm.
  
• I'm reluctant to code this in JavaScript. I remember when a date function changed the way it worked (by design from Netscape and MS) when the millenium changed. Essentially code that worked fine before the date failed after it. (Like a deliberately engineered Y2K problem.) I didn't get any advance warning and remember running around in the new year changing web sites in various parts of the world because of this deliberate and idiotic feature. (Thank goodness for FTP.) The number type also has some interesting behaviour!
  
• Part of the target audience knows about widely deployed encryption technology and will want to tap into an existing infrastructure. That means standard algorithms and the whole nine yards. To access that I need to get out of the JavaScript sandbox.
  
• ...
  

I guess the reason I wasn't aware of a browser hosted technology (like that available in email clients) is that it's not there. Pity.

I'll decide by 15 November whether this goes on ice.

Thanks again for all the input to this query.

[MikeGale]

I came across this IE Digital Rights Addon [microsoft.com]. It describes a beta version of an addon to Internet Explorer. This taps into something called Rights Management Services which among other things controls the ability to print documents and forward e-mails. I've not looked at it in detail. It may be whole document oriented (rather than smaller chunks) and is not yet released or widely deployed.

Anyone know anything about it or tried it out?

Looks like it may need a heavy backend investment on the server. If it does then it's not suitable.

[edicius]

You indicated above that your inclination was more towards .NET over Java. With this in mind, have you looked at the Smart Client deployment route? It has a few limitations (Microsoft .NET Framework must be loaded on the users' PC), but would give you full use of the .NET CLR,a rich-client UI, Code Access Security, offline capabilities, etc..

If you think the deployment scenario might fit (the .NET Framework requirement could nullify this option outright) - Microsoft has published quite a bit on the topic at: [msdn.microsoft.com...]

It may also be worth your time to check out some more real-world information and a demo here:
[sellsbrothers.com...]

[MikeGale]

Thanks for that edicius. I hadn't tried out the technology before.

I tried the Wahoo example and got firewall messages followed by a security blockade and debug session. I didn't run the program. This may currently be too hard.

I'm keeping an eye on this approach.