| 7:09 pm on Oct 31, 2003 (gmt 0)|
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?
| 10:39 pm on Oct 31, 2003 (gmt 0)|
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.
| 2:33 pm on Nov 1, 2003 (gmt 0)|
In that case, the simplest solution is to use SSL with an HTTPS connection to the server.
| 8:54 pm on Nov 2, 2003 (gmt 0)|
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.
| 1:06 am on Nov 3, 2003 (gmt 0)|
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?
| 2:13 am on Nov 3, 2003 (gmt 0)|
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.
| 2:34 am on Nov 3, 2003 (gmt 0)|
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?
| 4:58 am on Nov 3, 2003 (gmt 0)|
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.)
- 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"!
| 2:08 pm on Nov 3, 2003 (gmt 0)|
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.
| 7:23 pm on Nov 3, 2003 (gmt 0)|
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!
| 7:31 pm on Nov 3, 2003 (gmt 0)|
well, I'm out of ideas then.
| 7:53 pm on Nov 3, 2003 (gmt 0)|
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.
| 9:17 pm on Nov 3, 2003 (gmt 0)|
This is a great place really helpful.
Issue there include:
- I suspect a lot of effort to implement a performant and robust algorithm.
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.
| 7:49 pm on Nov 4, 2003 (gmt 0)|
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.
| 9:09 pm on Nov 4, 2003 (gmt 0)|
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:
| 9:51 pm on Nov 4, 2003 (gmt 0)|
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.