GoogleIt Mail IT Print IT PermaLinkWhy Ajax And Crypto Intrigue Me
11:27:14 AM
Written By : Richard SchwartzCategory : AJAX Crypto
Location : Nashua, NH

The series of articles that I have published lately dealing with Ajax and crypto have been attracting a little bit of an audience and a few links. I've been getting some feedback and questions -- good feedback, good questions, some of it skeptical -- and I've concluded that I haven't done a good job explaining my motivation for looking into it in the first place. So, I'm going to try to be more clear by using the conventional "Alice" and "Bob" metaphor favored by a lot of writers who deal with encryption.

The name that I have given to my objective is "host-proof hosting", and what that means is this:


Alice and Bob want to exchange data securely.

Charles hosts a web server used by Alice and Bob to collaborate, but Charles is not trusted by Alice or Bob.


Charles obtains access to Alice and Bob’s data.

Conventional Approach

Alice and Bob use an application that transmits plaintext data to Charle's server via SSL, but trust that code on Charle's server will encrypt it before storage. This is adequate for a lot of purposes, but may be inadequate in some cases.

Ideal Approach

Alice and Bob encrypt data before it leaves their computers, thus plaintext data is never accessible to Charles

Drawbacks Of The Ideal Approach

Methods for encrypting data and transmitting it, or receiving and then decrypting via a browser are "clunky".


Using the Ajax techniques in combination with a JavaScript implementation of crypto algorithms offers a "non-clunky" alternative.

Potential Hole

Alice and Bob need assurance that the JavaScript does not actually transmit plaintext data to Charles' server. (Or alternatively, know that it doesn't send data encrypted with a key that Charles knows.)


JavaScript code that executes in the browser can always be detected and examined because it is inherently open-source. This provides a way for Alice and Bob to know whether they are really communicating securely using pages delievered Charles' server.


Charles provides Alice and Bob with a JavaScript implementation that does browser-side encryption and decryption

David provides an expert opinion to Alice and Bob, vouching for the fact that the HTML and Javascript generated by Charle’s server does not transmit unencrypted data, and it is a closed system. (I.e., it does not use surreptitious methods to download and load additional scripts for execution.)

David provides Alice and Bob with a signed version of the actual code from Charle’s server that he is vouching for.

Ethan provides an open-source tool to Alice and Bob. This tool is a browser plugin capable of validating that the HTML and JavaScript loaded from Charles’ web site site into a given browser matches the code signed by David.

Alice and Bob run Ethan’s code. They are now assured that any attempt by Charles to modify the scripts in such a way that it would transmit plaintext data to Charles (or data encrypted with a key known only to Charles) can be detected. Alice and Bob are therefore able to exchange confidential data through Charles' server.


A conspiracy of Charles, David, and Ethan can allow access to Alice and Bob's private data.

A breach of Alice or Bob's computer that disable's Ethan's tool can make theft of data undetectable

No — I don’t know how to write Ethan’s tool, but I’m convinced that it can be done. The inherent open-source nature of JavaScript makes it possible.

Other articles in this series...

    Is Ajax The Answer For Crypto In Browser-Based Applications
    Proof of Concept: Browser-Based Field Encryption With Blowfish Via Ajax
    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

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

1. Christoph Zurnieden08/13/2006 03:09:52 PM

> A conspiracy of Charles, David, and Ethan can allow access to Alice and Bob's private data.

Not conspiracies needed. David signs the code, so he can insert all kind of code. Charles is not needed if Charles' server is vulnerable and can be cracked by David and/or David is able to intercept the communication between Charles, Alice and Bob. Ethan and David are exchangeable, they share the same attack vectors.
You would need SSL and selfsigning (Never allow third party signing if it is avoidable!) to avoid these attacks.

Or a complete RSA public/private key implementation (here is a BSD-licensed one:, only PKCS#1 which has some known attacks).


Alice and Bob exchange their public key and everything needed to prove a signature as one Javascript-script. This can be done in a lot of ways: personal exchange of some CDROMS, email if the GnuPG/PGP keys are already exchanged and most probably a lot of others ways too.

Alice and Bob encrypt their messages with the public key. The public key exists as a file on Alice and Bobs machines respectively and is loaded by hand (typing the path to the script in a textfile and load that via Javascript as an external-script node will not work, at least I hope so , I mean copy&pasting the base64 encoded keys into a textarea).

The rest works the same as you do it with the symmetric encryption.

Your work reminds me to something similar I did without AJAX. It was for saving data on an untrusted host only, no communication with a third party involed only between me and the host, so no use for AJAX here. I used XTEA for the algorithm because one end was a very low-end handheld, not capable of running any complicated algorithms in an acceptable amount of time.

Is there any good reason that I need Javascript to post a comment? Your page does not "degrade gracefully", it is therefore buggy, please repair, especially if it is as easy to repair as this example here.

Your Live-Preview does not work in Opera (8.5), but that seems a bit harder to repair.


2. Richard Schwartz08/15/2006 08:15:43 PM

@Christoph: Thanks for the comments. Implicit in my model is something I should have stated explicitly: David is trusted by both Alice and Bob. They trust his signature. David could even be Alice or Bob, if either of them is qualified to evaluate the code. But you are correct. No conspiracy is needed. If a trusted party is not really trustworthy, there can be no security.

The reason you need JavaScript is that that's what the implementors of this open source blog template for IBM Lotus Domino used, and this is the template that I chose. I've been running with it for quite some time, and you are the first to complain -- but point noted. I'll raise it with the implementors, or perhaps look into addressing it from a graceful degradation point of view myself.

As for the Opera issue, it's really that I disabled the preview entirely because it causes some awful problems in IE that I was unable to fix. I forgot to disable the label. Thanks for pointing that out.

3. Christoph Zurnieden08/20/2006 03:59:19 PM

Oh, what a week *sigh*
I live in Europe, so I can use the railway in most cases, but it isn't very

> Implicit in my model is something I should have stated explicitly:
> David is trusted by both Alice and Bob. They trust his signature.

No, they don't, they trust his ability to audit the code and find every bug,
the signature comes after that and is in no way connected to the bug-finding
ability. The signature is just a way to be "cryptographically sure" (which
differs infinite from "absolutly sure", of course) that the signed data hasn't
been altered after the point "signing"; it's not even sure who signed.

> David could even be Alice or Bob, if either of them is qualified to evaluate
the code.

How do you qualify "qualified"? It's still a matter of trust, even if you trust
yourself to find all of the bugs. It's possible in theory to nail all of the
software bugs because of the finite nature of the underlying hardware if the
*ware is turing-incomplete. You may even find all hardware bugs, including
the random bit-flipping caused by the smallness of the wiring and the
associated incrementing of the influence of the uncertainty relation (you don't
need a reason for the bit-flipping, no exotic cosmic rays or anything, the
chance for a bit-flip is above zero by itself) just by following all possible
paths. But there are a lot of paths.
And checking cryptographical code is very hard. Do you remember the breakage of
the MD5 and the SHA1 algorithms not so long ago? Have you read the paper and
understood that you can still use both algorithms if you use both algorithms
(meaning, that you hash the same data with both MD5 and SHA1 and use both
hashes for checking)? I can't recommend it, but it works.
But it's not all lost, statistics will save our precious elongated backs.
It's proved that time matters [BishBloo96], so it's good style to use old and
often approved algorithms in old and often approved implementations, published
often and at a lot of different places. To get the same advantages for your own
implementation you need to publish your implementation at a place with some
high frequency of capable people (e.g sci.crypt), some patience (and a thick
skin and most important: an alternative at hand.
With a bit of luck and/or money you'll have a lot of "Davids", a "web of trust"
as the PGP people call it. The individual nodes are not wheighed equal and the
web-of-trust is only able to falsify. That means, if somebody like Ron Rivest,
Bruce Schneier, Donald Knuth; Xiaoyun Wang, Dengguo Feng, Xuejia Lai, Hongbo Yu
(the people who broke MD5); Hongbo Yu, Xiaoyun Wang, Lisa Yiqun Yin (the people
who broke SHA1) -- just to name a few -- find a flaw in your implementation you
can be quite sure that there is a flaw in your implementation but not
vice versa. You can't even ignore the not-so-famous people like me too easily,
you have to give them a short glimpse at least to find out, that you missed one
attack vector that weakens your design a bit more.
But I digress. You have to have an alternative at hand, as I mentioned above,
because there is only one algorithm mathematically proven to be secure: the
one-time-pad where the key has the same size as the clear-text.
For example if you want to use a cryptographic hash you'll choose not only more
than one, but you prepare for the time that all of the choosen algorithms are
broken and you have to use a completely different algorithm not known at the
time of your first design or work around it with a completly different design.
The former is easy with asymetric encryption (there are now logarithmic or
elliptic-curve based algorithms and I heard off some very exotic ones too) but
the latter might be difficult, one solution is the same as the one with the
broken hash-algorithms: use multiple different algorithms in a row. I have no
knowledge of any other Javascript implementation than the standard RSA one based
on the difficulty of factorization.

> If a trusted party is not really trustworthy, there can be no security.

Well, there can be some security, even if you do not know who to trust, that
would be a kind of a Byzantine Agreement. An arbitrary Google finding with all
the needed bibliography: (you may find the
Lamport papers here: Or a bit newer
(but the mathmatics have not changed in the meantime :
A related problem with trust and signatures is described here: You might find it
interresting, how David Wheeler solved the problem Paul Karger and Roger
Schell described in 1974 (I guess Ken Thompsons speech is more wildly known and
can be found here:
Wheelers Paper can be found here: It had been ripped apart here:

A paper fitting to the "mechanics" of your theme found while looking for online
versions of some papers (all successes listed above):

> I've been running with it for quite some time, and you are the first to

No, I didn't complain, but it is really easy to change: replace the "normal"
button with a submit-button. This may get you in trouble with a couple of
browsers if you want to keep the javascript form validation. The easiest way to
solve that problem is to exchange the submit-button with a normal button with a
line of javascript.
The reason I stumbled over that, mmh, glitch is, that I used an old but
shockproof laptop. I need the robustness and you can't get that level of
robustness anymore today: it survived a fall from the 5th story into a pile of
gravel sand, had been run over by a 40 ton truck several times (I had to dig it
out!) and much more including some very unappetizingly things. But it's old,
has a PI-133 (including the F0-0F bug processor, 32MiB (minus some kiB for
video) RAM and some 1.2 GiB disc. So, every time I need Javascript I have to
start Opera. I could surf with Opera but it starts swapping after a small
couple of small pages. You too will admit: that doesn't make much fun


PS: If you have a lot of time at hand:
The second page has links to copies of the individual chapters of the "Handbook
of Applied Cryptography"

[BishBloo96] P. Bishop, R. Bloomfield, "A Conservative Theory for Long-Term Reliability/Growth Prediction", IEEE Transactions on Reliability v. 45 no. 4 (Dec 96) pp 550560.

4. Richard Schwartz08/21/2006 12:14:23 PM

Thanks again for the comments.

I hadn't been thinking in terms of whether David is a qualified cryptography coder, really. I had been thinking only in terms of whether David is qualified to verify whether or not the code is diverting the plaintext data stream before it is encrypted and sending it somewhere that it shouldn't go. Obviously, you are correct that David must be qualified farther than that.

My intention all along has been to suggest using well-known and established algorithms. I used Blowfish in my symmetric prototype, and if I ever do get around to doing asymmetric I will assuredly not try and invent my own algorithm -- as I would surely end up in Schneier's doghouse as a result. The only thing novel (if it even is novel) that I am suggesting is that it could be possible to use these algorithms in JavaScript because the Ajax-related capabilities current browsers may finally make it possible to send more than one transaction to a server without re-prompting for key information each time. The fact that JavaScript is inherently open to inspection is part of what could make this workable. The use of well-known and established algorithms is another.

So long as the algorithms that are used are well-known and trusted reference implementations exist, David does not need to be an expert crypto coder to test that the output of the JavaScript version matches the output for the reference version for a wide variety of plaintext inputs. That, IMHO, would be sufficient validation, and it doesn't require that David have the skills of a Knuth, Schneier, et al. Of course it doesn't remove the possibility that a well known algorithm is flawed.

As to the button issue, looking at the code more carefully indicates that it could be easier to change than I thought, but it's still something to bring to the open source group that maintains the blogsphere template rather than doing myself, as I don't know exactly why they did what they did -- and there may be implications related to comment spam prevention.

5. chenjinyan11/22/2016 02:59:06 AM
Homepage: http://

6. 20161125caihuali11/25/2016 12:24:10 AM

7. chenyingying12/01/2016 09:24:00 PM

8. dongdong803/06/2017 10:16:36 PM

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.