Jump to content


Check out our Community Blogs

Register and join over 40,000 other developers!


Recent Status Updates

View All Updates

Photo
* * * * * 1 votes

Full Encryption using javascript and PHP only

encrytion rsa rc4 php encryption javascript encryption tutorial library function library

  • This topic is locked This topic is locked
18 replies to this topic

#1 jerrywickey

jerrywickey

    CC Resident

  • Advanced Member
  • PipPipPipPip
  • 51 posts

Posted 10 February 2014 - 01:42 PM

I am offering an encryption library for anyone to use.  I encourage all developers to employ encryption pervasively.  

 

If we encrypt only important docs, those who snoop know exactly on which docs to focus all their decryption computing power.   Encrypt everything.  Not just passwords, but every AJAX call.

js: <body onload= initCrypto( 1024 bit)
js: encryptToServer( clientPlainText)
PHP: decryptFromClient( encryptedDataFromClient)
PHP: encryptToClient( serverPlainText)
js: decryptFromServer( encryptedDataFromServer)

It really is just this easy.   Below are code snippets and example code of an encrypted HTML FORM  

 

Check out the link below to see full examples plus source code. 

 

Use it for free.  Improve it and post your improvements.  The library is entirely javascript and PHP.  Nothing else.  You can fully test at http://jerrywickey.c...rrysLibrary.php  

 

Download the library at http://jerrywickey.c...rrysLibrary.php

or from GitHub https://github.com/j...-Encryption.git

 

The page explains how to use and includes lots of sample code.  The library also offers AJAX functions.  So you don't need JQuery if you don't need it otherwise.  It's light.  The javascript library is only 18K

 

The html and javascript below really needs no explanation.  It is very self explanatory.  Other than download the jerrysLibrary.php and jerrysLibrary.js scripts and save them to your server, this is really all that you need to do to encrypt every comment, every post, every message going back and forth on your web pages.  Both the javascript and PHP scripts can be found at the links above.

 

Many more examples and sample PHP code is found at http://jerrywickey.c...rrysLibrary.php

multihttp( urlGET, POST, callBackFunctionName)

is an AJAX function found in the jerrysLibrary.js library.  It is fully explained at the link above.  It merely sends the GET and POST and upon the servers response calls the callBackFunctionName with the response javascript escaped  unescape( escape( a))

encryptToServer( plainText)
decryptFromServer( encryptedResponseFromServer)

These two are also fully explained at http://jerrywickey.c...rrysLibrary.php

There is no need to use encodeURIComponent() the encrypt function returns an URL safe string.

<script src="jerrysLibrary.js"></script>

<body onload="initCrypto( 1024)">

<input type="text" id="testName">
<input type="password" id="testPass">
<textarea id="testComment" style="width: 200px; height: 50px;"></textarea>
<button onclick="sendEncryptedForm()">Submit</button>

<div id="encResponse"></div>

</body>

<script>

function sendEncryptedForm(){
   var a= '&testName=' +document.getElementById( 'testName').value;
   a+= '&testPass='+document.getElementById('testPass').value;
   a+= '&testComment='+document.getElementById('testComment').value;
   var enc= encryptToServer( a);
   multihttp( '', ( '&encrypted='+ enc), 'viewResponse');
}

function viewResponse( a){
   document.getElementById('encResponse').innerHTML= decryptFromServer( unescape( a));
}
</script>

  • 0

#2 Alexander

Alexander

    YOL9

  • Moderator
  • 3963 posts
  • Location:Vancouver, Eh! Cleverness: 200
  • Programming Language:C, C++, PHP, Assembly

Posted 10 February 2014 - 07:03 PM

Your library is only as secure as the clients' connection, and this should not be relied on as the only layer of security ("No SSL, no secure server needed.")

 

The issue with using this over something such as (or without) explicit SSL/TLS, is that the library and website must be sent over plaintext to the user during initial condition and the user is exposed to a MITM attack, where the page is altered to collect data before encryption.

 

This means circumventing this encryption is not much more difficult than if it were unencrypted.

 

SSL/TLS with proper origin assurance on the current session can ensure the library, and scripts retrieved are what you expect them to be.

 

Alexander.


Edited by Alexander, 10 February 2014 - 07:07 PM.

  • 4

All new problems require investigation, and so if errors are problems, try to learn as much as you can and report back.


#3 jerrywickey

jerrywickey

    CC Resident

  • Advanced Member
  • PipPipPipPip
  • 51 posts

Posted 10 February 2014 - 07:27 PM

Thank you for your comment.

 

I am not sure you understand what an asymmetric RSA public key is.

 

It doesn't matter that everyone knows the whole encryption scheme and ALL messages even from the very first GET request for the page, they still can't decrypt the message generated on the client page, because not even the client has the decryption key.

 

It does't matter what the origin or route of the messages.  The only way they could decrypt anything or even send a message to the client is if they have the RSA private key.  That is never sent anywhere at any time.


  • 0

#4 Alexander

Alexander

    YOL9

  • Moderator
  • 3963 posts
  • Location:Vancouver, Eh! Cleverness: 200
  • Programming Language:C, C++, PHP, Assembly

Posted 10 February 2014 - 07:42 PM

It is not a misunderstanding, absolutely nothing is done to the data while the user is typing it in to their keyboard on to the unsecured web page.

 

My concerns come from your examples:

<input type="password" id="testPass">
...
<button onclick="sendEncryptedForm()">Submit</button>

If I have a textbox and type "alexander123" or my credit card number, the initial webpage could have been altered to send this data to a malicious server before the data is ever encrypted and sent to the server. Your library is protecting only one part of the route, both the client and the server are both vulnerable in your example configuration ("No secured server.").

 

This defeats any confidence of the original data being secured, it only enables some certainty that the actual data can only be encrypted or decrypted in a controlled manner, it does not stop the attacker from replacing the 'decrypted data' with their own, for example coercing the user in to following instructions to compromise their data or account.

 

If the client's connection is not secured, then your library alone does not add any valuable security.

 

Am I missing the purpose of your library?


  • 3

All new problems require investigation, and so if errors are problems, try to learn as much as you can and report back.


#5 Vaielab

Vaielab

    Programming God

  • Expert Member
  • PipPipPipPipPipPipPip
  • 1382 posts
  • Location:Quebec City
  • Programming Language:Java, C++, C#, PHP, JavaScript, Visual Basic .NET, Transact-SQL, ActionScript

Posted 10 February 2014 - 07:46 PM

Javascript encryption does NOT trully exists

Only obfuscation exists, so if a hacker listen to your network and see obfuscated code, since he has the code to unobfuscate it, it may stop wannabe hacker, but the one who are able to listen to a network will know how to unobfuscate your data.

Like Alexander said, you will need an SSL/TLS, that is the safest (and easiest) way to protect your data.

 

And mmmm, I was looking at your code, and there this function that is kinda strange


function JL_geturl( $url, $agent, $timeout, $post, $cookiejar){
$page= false;
if ( strlen( $url)>10 && strtolower( substr( $url, 0, 7))=='http://'){
$a= ' (Jerrybot; http://www.botproject.jerrywickey.net/ ) ';
if ( strlen( $agent)<5){ $agent= $a;}
if ( strlen( $timeout)<1){ $timeout= 6;}
if ( strlen( $post)<5){ $post= false;}
if ( strlen( $cookiejar)<5){ $cookiejar= false;}
$curl= curl_init();
curl_setopt( $curl, CURLOPT_FOLLOWLOCATION, true);
curl_setopt( $curl, CURLOPT_MAXREDIRS, 3);
curl_setopt( $curl, CURLOPT_URL, $url);
curl_setopt( $curl, CURLOPT_USERAGENT, $agent);
curl_setopt( $curl, CURLOPT_TIMEOUT, ($timeout+1));
curl_setopt( $curl, CURLOPT_CONNECTTIMEOUT, $timeout);	
if ( $post!=false){
curl_setopt( $curl, CURLOPT_POST, true);
curl_setopt( $curl, CURLOPT_POSTFIELDS, $post);
}
if ( $cookiejar!=false){
curl_setopt( $curl, CURLOPT_COOKIEJAR, $cookiejar);
}
curl_setopt( $curl, CURLOPT_RETURNTRANSFER, true);	
$page= curl_exec( $curl);
$error= curl_error( $curl);
curl_close( $curl);
if ( strlen( $error)>0){ $page= 'ERROR [' . $error . '] ' . $page;}
}
return $page;
}

If I read this correctly, you are sending the $post variable (I assume this represent $_POST, so all our form) and our cookies, to a third party page (your personnal page)?!?!?!

Please explain this!


  • 0

You can now stalk me on linkedin: http://ca.linkedin.c...elle/24/b44/88/ !


#6 jerrywickey

jerrywickey

    CC Resident

  • Advanced Member
  • PipPipPipPip
  • 51 posts

Posted 10 February 2014 - 07:52 PM

I appreciate your attention to this.

 

If I understand your argument correctly, the page contents could be altered by some intermediate routing server upon the initial GET for the page.  At that point additional code very specific to the particular page being attacked could have been placed in the page that sends unencrypted content from the client.

 

Is that correct?

 

Because if so, such a change in the initial page content is easily detectable.  if someone suspects the extraordinary effort and time some nefarious individual must dedicate to such a specific effort, and if you'd like I can show how.


  • 0

#7 Alexander

Alexander

    YOL9

  • Moderator
  • 3963 posts
  • Location:Vancouver, Eh! Cleverness: 200
  • Programming Language:C, C++, PHP, Assembly

Posted 10 February 2014 - 08:29 PM

 

extraordinary effort

 

This attack can be completely passive and automated, what makes you think such a particular attack is difficult over others? The scope of this is not to explain the minor details of how this MITM situation can occur, it is to inform you of the simplicity of circumventing your layer of security in common situations users may be exposed to.

 

 

such a change in the initial page content is easily detectable.

 

You run in to precisely the same problem, any detection is at that point unreliable. The data you enter is completely insecure if the web page you are typing it on is, you have little assurance of its origin.

 

If the user investigates if all traffic is legitimate in the first place, you are relying on them to secure themselves and users are not very reliable (your script implies broad ease of use for example.)

 

If your tools are not used properly, they are useless.


Edited by Alexander, 10 February 2014 - 08:31 PM.

  • 0

All new problems require investigation, and so if errors are problems, try to learn as much as you can and report back.


#8 jerrywickey

jerrywickey

    CC Resident

  • Advanced Member
  • PipPipPipPip
  • 51 posts

Posted 10 February 2014 - 08:33 PM

Vaielab

curl_setopt( $curl, CURLOPT_URL, $url);

That's where the post data is going.  That is the $url that comes from what ever you type.  Not me.

$a= ' (Jerrybot; http://www.botproject.jerrywickey.net/ ) ';
if ( strlen( $agent)<5){ $agent= $a;}
curl_setopt( $curl, CURLOPT_USERAGENT, $agent);

That's the user agent.  That isn't where the info is going.  So that what ever web page YOU are accessing, knows that a bot is access it, not a browser.

 

I'm trying to be helpful here.  I am trying to give developers options and make it easy to encrypt everything.  Every POST and every GET.  That is how we get the ** NSA off our backs.

 

 

Here's the thing. 

 

javascript is slow.  That is why javascript encryption is difficult , but not impossible.  I had to rewrite the bcmath package.  You can check that out too.  It's in the .js library.  It is twice as fast as the fastest arbitrary precision javascript math package I found out there.

 

The client gets the page in plain text while the server is already busy generating large prime numbers.  

 

The client sends the server the results of a speed test it ran on itself.  The server chooses the highest, most robust RSA key set it can fit into that speed and sends the client the public keys.

 

Of course anyone can see these public keys.  They encrypt but do not decrypt.  The client then generates its symmetric key that can encrypt and decrypt very fast.  It uses my bcmath package to encrypt this key with the public key it just got from the server.  

 

Everyone can know this public key it won't do them any good.  It does't decrypt.  That's why its called the public key.  It can be published in a phone book.

 

Only the server knows the private key.  It was never sent to anyone anywhere at any time. Only the server can decrypt the RC4 key.  So now only the client and server know the key.  This despite everyone and his dentist looking in on the conversation.  Even someone hijacking the com between the two can't decrypt the key.  Even if they broke into the users house and held a gun to the guy typing, he doesn't have and the client machine doesn't have the decryption key.


Edited by jerrywickey, 10 February 2014 - 08:57 PM.

  • 0

#9 Alexander

Alexander

    YOL9

  • Moderator
  • 3963 posts
  • Location:Vancouver, Eh! Cleverness: 200
  • Programming Language:C, C++, PHP, Assembly

Posted 10 February 2014 - 08:36 PM

 

 Even someone hijacking the com between the two can't decrypt the key.

 

At this point the user will have zero encryption capabilities in the first place, the hijacker will simply patch out everything relating to security, and can even do so in a way that looks legitimate to the users. It does not matter to them that previous data is not able to be decrypted they will rely on the user to ignorantly enter it again!

 

This is why you must employ further layers of security to prevent this, there is no all-in-one, you are advertising it without thought of consequence to ignorant users who may be implementing this on completely unsecured systems and then advertising it as secure to their users.

 

A disclaimer of its scope should be minimum in my humble opinion.

 

Alexander.


Edited by Alexander, 10 February 2014 - 08:48 PM.

  • 0

All new problems require investigation, and so if errors are problems, try to learn as much as you can and report back.


#10 jerrywickey

jerrywickey

    CC Resident

  • Advanced Member
  • PipPipPipPip
  • 51 posts

Posted 10 February 2014 - 08:40 PM

Alexander,

 

perhaps you could explain exactly what is involved in getting access to what the client types into the input fields.

 

Explain how you might insert your code into the page as it is first transmitted to the client.  What server hardware having access to what data streams.  And explain exactly what you would have to write that could be used on any other page automatically. 

 

Frankly, it would be easier to break into the users house and hold a gun to his head while robbing him directly.  Any tool can be misused.

 

All I'm saying is that if we encrypt everything, the NSA and other organization who wish that free speech and other ideas that people like you and me cherish find themselves on the defensive rather than feeling smug about pulling the wool over our eyes anymore.

 

I want to see every AJAX call encrypted.    That is a step in the right direction.

 

If we encrypt only important docs, then its easy to focus decryption efforts on those docs alone.   If every software developer employed encryption for every GET and POST,  every packet would have to be decrypted just to find what was important.

 

Encryption isn't about perfection.  It is about making the world a better and more free place to live.


Edited by jerrywickey, 10 February 2014 - 08:44 PM.

  • 0

#11 Alexander

Alexander

    YOL9

  • Moderator
  • 3963 posts
  • Location:Vancouver, Eh! Cleverness: 200
  • Programming Language:C, C++, PHP, Assembly

Posted 10 February 2014 - 09:00 PM

I have a feeling I will not be able to convey the reality of these scenarios to you. If the NSA has backdoors in routers, control over every server between the client, and the web servers almost everybody uses in the US and may give routine access to the authorities - it is hopeless to think hiding a GET/POST request will help you or diminish their capability, meanwhile you promise the user a solution and leave them insecure means of applying it.

 

Real security involves compromises, and generating extra computational headroom for the minimal security it provides is not feasible for some people. TLS with RC4 is shown to be resistant to the recent attacks on cipher block chaining as a minimum, and provides the confidence in security you seem to advertise to the user rather than attempting to obscure the stream for the sole purpose of hiding it from NSA.

 

I have conveyed my thoughts and opinions and hope you have found them useful in some manner.

 

Alexander.


Edited by Alexander, 10 February 2014 - 09:02 PM.

  • 2

All new problems require investigation, and so if errors are problems, try to learn as much as you can and report back.


#12 jerrywickey

jerrywickey

    CC Resident

  • Advanced Member
  • PipPipPipPip
  • 51 posts

Posted 10 February 2014 - 09:09 PM

Alexander,

 

Your' right.  The most robust encryption could be rendered moot by subatomic superimposition quantum processors.  For that matter, the world could end tomorrow.  The Lord could return to judge the living and the dead.

 

But until that happens, let's work together to make the NSA's job harder.  So hard that they give up.

 

So hard that they have to admit defeat to the world of computer programmers.


Edited by jerrywickey, 10 February 2014 - 09:14 PM.

  • 0





Also tagged with one or more of these keywords: encrytion, rsa, rc4, php encryption, javascript encryption, tutorial, library, function library

Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download