PermaLinkProof of Concept: Browser-Based Field Encryption With Blowfish Via Ajax
06:06:35 PM

A few days ago, I wondered about the possibility of building a practical brower-based scheme for data field encryption using Ajax. What I'm hoping for is a way to build browser apps that can be totally secure even though they are hosted by an application service provider. The goal is to make an application that is "host-proof", in the sense that while legitimate users can easily share data with one another, the people who actually host the servers can't see the data.

I was able to spend part of last night and today working on building an Ajax-based host-proof app, and I've got a proof-of-concept working for the first piece of the puzzle. My proof-of-concept app combined a Javascript implementation of the Blowfish crypto algorithm, and some additional Javascript lifted from Jake's sample Ajax database along with my own HTML and scripting to build a single page in a Domino database, along with one form, one view, and one agent. The result is an app that you can see and try out here. The app encrypts and decrypts data entirely within the browser. The data is stored on the server, but just as is the case with secret key encryption in the Notes client, it can't be decrypted by a server admininstrator. It can only be decrypted by users who know a secret pass-phrase.

The app starts with a single ?OpenPage url, and if you play with it a bit you will notice that it stays there. There's no frameset. The first thing you do is enter a pass-phrase, which is used to generate the key for the Blowfish algorithm. You can use any key you want, from 4 to 56 bytes. Despite using variable length keys, and in this case despite the limitation of using keys that consist only of printable characters, Blowfish is a strong algorithm, comparable to or stronger than what is available for secret key encyrption in the Notes client and in SSL. Once you enter the pass-phrase, it stays in the browser, cached in the object model of the resident page. That's one of the most important things to realize about Ajax: there are no page transitions. All of the UI updates are via DHTML, If we were doing page updates, we'd either have to re-prompt for the pass-phrase every time we want to do a crypto operation, or we'd have to find some other way to keep it persistent. The entire point of what I'm trying to show in this proof-of-concept is that we can do this entirely within the confines of the browser itself -- without using a cookie (which would be transmitted to the server) or the PC's file system (which is problematic in Javascript).

After entering the pass-phrase, you can enter a message in a text field. You also enter a name for the message, which you will use later to retrieve it. When you click to save the message, it is encrypted and then transmitted to the server. Technically, this isn't true Ajax at this point, because I'm not bothering with XML-encoding the data. I'm just putting it into the URL that I am generating for an http GET operation. The URL is actually for an ?OpenAgent operation on the Domino server, and the agent takes care of saving the encrypted message and it's name in a document. The application shows you the encrypted value after it is saved, and you can click on a link that brings you to a plain vanilla Domino ?OpenDocument page where you can see that the encrypted data was stored. You can't actually see that the plaintext value isn't stored on the server, but you'll either have to trust me on that, or check the code. (BTW: the fact that you can check the code is actually an important feature for what I'm trying to accomplish. It's what provides the ability for users to trust that their data really isn't being shipped off somewhere in it's unencrypted form.)

After saving your message, you can read messages. The app will show you a select control containing a list of stored messages. You will be able to select the message you just saved, and any others you save with the same key. If you select messages that were saved by someone else, encrypted with a different pass-phrase, the app will just tell you that the keys don't match. The select control is populated, and the message is retrieved for decryption using true Ajax. In both cases, a ?readviewentries URL is generated and sent to the Domino server. The DXL that is returned is processed using the browser's builtin DOM parser. I don't do XSL because first of all XSL in general makes my brain hurt, and secondly because thinking about how I might specifically use XSL to transform DXL and populate and re-populate the options of a select control makes my brain really hurt.

At this point, you can click a button to start over with the same pass-phrase or a new pass-phrase. If you use "the power of the schwartz" as your pass-phrase, by the way, you'll be able to decrypt a half dozen or so messages that I've already encrypted with that as the key.

You will notice some flashing of a status line during operations. I did this just to add a bit of visual demonstration of the asynchronous behaviour of app. If your connection is slow enough, you might actually see more than one message appear and disappear during some operations. You might also notice that the select control appears empty at first while the DXL is being retrieved, and is then filled in as the view entries are parsed.

I'm not ready to make the database downloadable yet. The code isn't as clean as I would like. In particular, the Blowfish implementation uses a bunch of ugly global variables that it really shouldn't, and it has a small bug that I had to work around (i.e., it returns a bunch of trailing nulls at the end of the decrypted text). And none of the code is well commented. Still, it's just Javascript, so you can get it from your browser if you want to. I'll clean it up eventually, but not necessarily before the next stage of my investigation, which will involve doing public key crypto in a similar framework. The challenge there will be retrieving a certificate in the first place. I've already established through this Blowfish exercise that I can keep keys persistent in the browser.

Other articles in this series...

    Is Ajax The Answer For Crypto In Browser-Based Applications
    The Obstacles To Public Key Encryption In The browser
    An Improvement To The Classic Ajax Coding Pattern
    A Further Improvement To The Ajax Coding Pattern
    Why Ajax And Crypto Intrigue Me

This page has been accessed 996 times. .
Comments :v

1. Stephan H. Wissel05/12/2005 12:29:56 AM

Very cool!
I'm looking forward to the public key example.
I'm wondering:
- could one use that to sign with a private key? The challenge here would be how to get that key. I presume JS can't access the local key store (which would be propriarty anyway), so some clever mechanism would be needed to get the private key from somewhere else.

2. Alan Bell05/12/2005 06:29:49 AM
Homepage: Http://

I was quite enjoying that until most of my internal organs collapsed as I read the content of message 5!

3. Chris Hammond-Thrasher05/21/2005 01:52:02 AM

This is amazing stuff. I am looking forward to the public key example.

4. Eric Tomenga08/04/2005 01:25:19 PM

I found your demo very informative. I look forward to the public key example myself.

5. Chris09/14/2005 05:07:04 PM

I'm very interested in your javascript encryption methods. I am trying to encrypt a phone number before saving it to a database. I would then need an unencryption method call once I've returned the record with the encrypted value from the database.
Might you have something I can work with?
Essentially, the user would type their phone number into a form, and after submitting form, the encryption would take place before posting to the database.
Please email me directly if you can! Thanks so much for any help you can provide.

6. ocnsss03/22/2007 07:48:09 PM
Homepage: http://

On personal opinion, I find this very helpful.
Guys, I have also posted some more relevant info further on this, not sure if you find it useful:

7. Secure Email05/09/2007 12:04:43 PM

Thanks for the information. Just the thing I was looking for my service. However the link' does not work.

Blocked Response!11/17/2008 05:48:54 AM

This response from IP Address was blocked by the owner of this blog.

Blocked Response!11/26/2008 07:20:32 AM

This response from IP Address was blocked by the owner of this blog.

Blocked Response!11/29/2008 06:39:32 AM

This response from IP Address was blocked by the owner of this blog.

Blocked Response!12/03/2008 12:31:54 AM

This response from IP Address was blocked by the owner of this blog.

Blocked Response!12/04/2008 04:20:32 AM

This response from IP Address was blocked by the owner of this blog.

Blocked Response!12/08/2008 04:15:12 AM

This response from IP Address was blocked by the owner of this blog.

14. cmoutlet12/03/2014 03:16:10 AM

Enter Comments^

Email addresses provided are not made available on this site.

You can use UUB Code in your posts.

[b]bold[/b]  [i]italic[/i]  [u]underline[/u]  [s]strikethrough[/s]

URL's will be automatically converted to Links

:-x :cry: :laugh: :-( :cool: :huh: :-) :angry: :-D ;-) :-p :grin: :rolleyes: :-\ :emb: :lips: :-o
bold italic underline Strikethrough

Remember me    

Monthly Archive
Responses Elsewhere

About The Schwartz


All opinions expressed here are my own, and do not represent positions of my employer.