Javascript Encryptor
Written by David Lariviere - dal2103@columbia.edu
For Professor Zeph Grunschlag
Requirements :
You’ll need Java 1.4 on your system.
1) Installation & Use
 Download “jsencryptor.zip” or “jsencryptor.tar.gz” and unpack the archive
 Note the following portion of the unpacked directory structure:
program  output  BigIntEncap.class
 Make sure the user running the program has read/write access to all
files/directories within “program” (including “program”)
Running:
 Run JavascriptEncryptor.class (if the OS allows simply click on it, otherwise ‘cd’
into “program” dir, and then type “java JavascriptEncryptor”)
 The JavascriptEncryptor GUI should popup.
 Enter the number of student keys required (# of unique keys, one per student)
 Type in a password (this will be used as the seed for a lot of the random
generations of BigIntegers required), password can be reused to regenerate all
data. NOTE: Password is NOT case sensitive.
 Paste the desired javascript hash function that one wishes to encrypt, or use the
provided default javascript code (NOTE: the provided function makes no attempt
to obfuscate the student’s password which will be apparent directly from the
URL. Thus another student looking at the web-browser’s URL, or viewing the
browser’s history cache would be able to figure out the password. If this behavior
is undesirable, you should replace the code by a secure hash function).
 Click the button "Generate files"
This should generate three files in the Output dir (or overwrite the three already there)
1) encode.js: the javascript file that is used by any webpage to decode and run
the encrypted javascript function
2) summary.html: a webpage containing a summary of all the RSA values used,
as well as the # of keys requested to be given to students.
3) login.html: this is a demo webpage, designed to show how to use encode.js &
BigIntEncap.class to create a login page, allowing users to enter their
password and then be forwarded to a site determined by the encrypted
javascript hash function.
*Reminder* BigIntEncap.class should already be in the Output directory. encode.js and
BigIntEncap.class must always be in the same directory as the html page that contains the
login form.
Webpage Use:
 The exact html of the webpage is dependant upon the provided javascript hash
function that is encoded.
 In the provided demo ("login.html") a form is used that contains a text box for a
UNI and for the hash function.
 That page includes the "encode.js" file at the top of it:
 <script type="Javascript" src="encode.js">
That javascript file & encrypted hash function assume certain properties about the
webpage that will call it:
1. the name of the form calling the javascript file will be "LoginForm"
a. (i.e. <form name="LoginForm" action=" ">)
2. the UNI or whatever text element holds the user's "login" will be called "login"
a. (i.e. <input type="text" name="login">)
3. the text element containing the user's key will be called "password"
a. (i.e. <input type ="text" name="password">)
4. When the user of the webpage wants to call the javascript file, it will somehow
call the function "ValidateLogin()"
a. (for example but not limited to a button: <input type="button"
value="Login" onClick="ValidateLogin();">)
5. Somewhere within the body of the webpage, it includes the applet with code
source of "BigIntEncap" and is named "bigInt"
a. (for example <APPLET CODE ="BigIntEncap.java" WIDTH=0
HEIGHT=0 NAME="bigInt"></APPLET>)
i. **note** the width & height = 0 values of the applet insures that
the user does not actually see the applet
b. Methods for including applets in webpages have become increasing
complex over the years as different browser makers support different
standards. Must browsers still recognize and process correctly the original
<applet> tags, but may consider them deprecated. Using the newer applet
inclusion methods at present are a poor choice because they prevent
compatibility with older browsers. For more information about methods of
including applets within a webpage see
http://java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/using_ta
gs.html
The javascript file also requires certain properties of the javascript code to be encrypted:
1) if the function desires the user's login, it will acquire it through "var login =
document.LoginForm.login.value;"
2) if the function desires the user's key, it will acquire it through "var pwd =
document.LoginForm.password.value;"
3) the encrypted function is responsible for actually opening up the desired URL
(or whatever other action the user has in mind)
i. (i.e.: self.location.href=theURL;)
Notes:
All previous stated requirements are often interconnected among the
implementation between the example login page and the provided default to-be encrypted
javascript function. If one were to change, for example, the name of the password
textbox, this would be acceptable so long as the corresponding encrypted hash function
that tries to access the value of the textbox also is aware of and uses that name.
Some browsers and computers (namely Windows XP Service Pack 2) require
authorization before allowing javascript or java to now run. It may be useful to provide a
note on the login page informing users that they must enable javascript and java in order
for the login page to work. The majority of users, however, do already have this enabled
The default hash function for the user's webpage is the following:
 The URL is formed from taking the UNI and adding to it '_' and then the
specific user's key. That URL is then opened by redirecting the current
window to the generated URL (as described above in 3))
Student use:
 Students should go to the page, type in their UNI, paste in their key, and then
click the submit button.
 A window should then popup taking them to their respective webpage (with
an address that is defined by the encrypted hash function)
2) Theory:
 The program relies on RSA encryption. The fundamental premise being one
generates two very large unique primes, (p & q).
 The product of those two primes is then calculated (p*q=N).
 Then Phi(p, q) is calculated, where Phi = (p-1)(q-1).
 Then e & d are calculated. E is generated by continuing to generate random
numbers until one is found that is less than and relatively prime to Phi.
 d is the inverse of E mod Phi (i.e. e^(-1) mod Phi = d)
 The hash function provided is then treated as a base-128 representation (using
ASCII) of a number.
 That number is then encrypted by raising that number to e, and then taking mod
N.
 Fermat's Theorem dictates that the inverse of that function is to take that resultant
number, raise it to d, and then take mod n.
 This returns the original #, which is then again converted into a base-128
representation (using ASCI).
 To keep the student keys small, the base 36 representation of d is split into two
parts, a large part, and a small part. The large part is simply stored in the
javascript, but the last several digits are encrypted and made unique to each
student.
 KeyExpansion KE satisfies smallD + Rand*KE = studentKey
 Then to generate x # of keys, the program
1) generates a random integer (in actual implementation it has a bitlength of
32)
2) multiplies that random integer by the keyExpansion
3) adds that product to the small part of d, creating an individual user’s key
 this is done x number of times, resulting in x unique keys




The original d value used to decrypt is acquired by simply taking the resultant
student's key mod keyExpansion, which will return the small part of d, and then
adding it to the end of the large part to get the full base 36 representation of d.
The javascript function can then acquired by simply taking the resultant encrypted
number to the d power mod N. (encrypted ^ d mod N)
This is relatively secure because of the difficulties of factoring the product of two
primes. Given the extremely large N, it is very difficult to determine the original p
& q which generated it (if the p & q chosen is relatively large, which in this case
they certainly are).
If one could easily factor the product of two primes, then they could determine p
& q, and therefore Phi, e, & d. This is STILL secure even if they could determine
all those values, because the actual passwords also revolves around the individual
key given to each user which is used to access a specific webpage. The small part
of d is always multiplied by some large number which is a product of the
keyExpansion & another random integer.
3) Potential Weaknesses
RSA is deemed very secure assuming the difficulty of factoring the product of
large primes, however, if that difficulty were to be eliminated then it would result in a
weakness. All users who have key will be able to reverse engineer the javascript hash
function. To do so, they would download the javascript file, java applet, and login page,
and then alter the contents of the javascript file to read "alert(decoded)" instead of
“eval(decoded)". They would then see the actual hash function being used. This, alone,
however does not allow them to figure other students keys, and so long as the hash
function used does require use of that key, then they can not access other students pages
with just the hash function.
If two students were to share one another's keys, they could then determine the
keyExpansion.
To calculate the key expansion they would do the following: *small D refers to the
smaller portion of the base 128 representation of D that is encoded within each userKey*
1. Assume two random unique ints, x & y
2. Key #1 = (keyExpansion * x) + smallD
3. Key #2 = (keyExpansion * y) + smallD
4. smallD can also be seen by running the altered javascript file on their own
computer with “alert(sD)”.
5. then by taking the ratio of (key #1 - smallD)/(key #2 - smallD), they would get the
a number equal to (x/y).
6. If they could then calculate the whole number ratio (the integers that correspond
to x & y), they could find the keyExpansion
Knowing the keyExpansion still does not help much in calculating other user's
webpage URLs, because each user’s other random int is large (2^32) or roughly 4 billion
possibilities. They would have to write a brute force program to calculate the various
keys by taking keyExpansion * (i) + d, where i is every number on the order of 2^32, and
then running that combined with the particular person's login they are trying to crack
through the known javascript function, and then seeing if that resultant URL points to an
actual page.
The weakest link lies in the distribution of the keys to the users. The keys must be emailed to people, which could be intercepted with packet sniffers. Also, because of the
length of the keys, one is not likely to remember them, and therefore they must be stored
on the person's computer. Finally, when actually accessing the page, a packet sniffer
could intercept the URL. The user may even bookmark their site, storing the URL. The
url/webpage may also be stored in their history & potentially in their temporary internet
files folder.