Javascript Encryptor - User Guide

Written by David Lariviere
For Professor Zeph Grunschlag

 

1) Installation & Use

• Download the compressed archive containing “JsEncrypt”
• Decompress the contained files

 

Encrypt the code and Generate the Pages:

• Run JavascriptEncryptor.class (if the OS allows simply click on it, otherwise ‘cd’ into the "JsEncrypt" 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.
• Paste the desired javascript hash function that one wishes to encrypt, or use the provided default javascript code
• 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.

 

2) Implementation into another Webpage:

• The exact html of the webpage is dependant upon the provided javascript hash funtion that is encoded.
• In the provided demo ("login.html") a form is used that contains a text box for a login 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"
1. (i.e. <form name="LoginForm" action=" ">)
2. the login or whatever text element holds the user's "login" will be called "login"
1. (i.e. <input type="text" name="login">)
3. the text element containing the user's key will be called "password"
1.  (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()"
1. (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"
1. (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

2. The methods of including applets in webpages has 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 compatibability 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_tags.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 login 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 login, 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)

 

3)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).
• In order for each student to have a unique key, a series of keys is generated. Another very large random BigInteger is generated (one which is 5 bits longer than d), referred to as the keyExpansion.
• 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.
• 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.

 

4) Potential Weaknesses

RSA is deemed very secure assuming the maintained 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 e-mailed 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.