Encryption Algorithms

Different encryption algorithms use proprietory methods of generating these keys and are therefore useful for different applications. Here are some nitty gritty details about some of these encryption algorithms. Strong encyrption is often discerend by the key length used by the algorithm.

RSA
In 1977, shortly after the idea of a public key system was proposed, three mathematicians, Ron Rivest, Adi Shamir and Len Adleman gave a concrete example of how such a method could be implemented. To honour them, the method was referred to as the RSA Scheme. The system uses a private and a public key. To start two large prime numbers are selected and then multiplied together; n=p*q.

If we let f(n) = (p-1) (q-1), and e>1 such that GCD(e, f(n))=1. Here e will have a fairly large probability of being co-prime to f(n), if n is large enough and e will be part of the encryption key. If we solve the Linear Diophantine equation; ed congruent 1 (mod f(n)), for d. The pair of integers (e, n) are the public key and (d, n) form the private key. Encryption of M can be accomplished by the following expression; Me = qn + C where 0<= C < n. Decryption would be the inverse of the encryption and could be expressed as; Cd congruent R (mod n) where 0<= R < n. RSA is the most popular method for public key encryption and digital signatures today.

DES/3DES
The Data Encryption Standard (DES) was developed and endorsed by the U.S. government in 1977 as an official standard and forms the basis not only for the Automatic Teller Machines (ATM) PIN authentication but a variant is also utilized in UNIX password encryption. DES is a block cipher with 64-bit block size that uses 56-bit keys. Due to recent advances in computer technology, some experts no longer consider DES secure against all attacks; since then Triple-DES (3DES) has emerged as a stronger method. Using standard DES encryption, Triple-DES encrypts data three times and uses a different key for at least one of the three passes giving it a cumulative key size of 112-168 bits.

BLOWFISH
Blowfish is a symmetric block cipher just like DES or IDEA. It takes a variable-length key, from 32 to 448 bits, making it ideal for both domestic and exportable use. Bruce Schneier designed Blowfish in 1993 as a fast, free alternative to the then existing encryption algorithms. Since then Blowfish has been analyzed considerably, and is gaining acceptance as a strong encryption algorithm.

IDEA
International Data Encryption Algorithm (IDEA) is an algorithm that was developed by Dr. X. Lai and Prof. J. Massey in Switzerland in the early 1990s to replace the DES standard. It uses the same key for encryption and decryption, like DES operating on 8 bytes at a time. Unlike DES though it uses a 128 bit key. This key length makes it impossible to break by simply trying every key, and no other means of attack is known. It is a fast algorighm, and has also been implemented in hardware chipsets, making it even faster.

SEAL
Rogaway and Coppersmith designed the Software-optimized Encryption Algorithm (SEAL) in 1993. It is a Stream-Cipher, i.e., data to be encrypted is continuously encrypted. Stream Ciphers are much faster than block ciphers (Blowfish, IDEA, DES) but have a longer initialization phase during which a large set of tables is done using the Secure Hash Algorithm. SEAL uses a 160 bit key for encryption and is considered very safe.

RC4
RC4 is a cipher invented by Ron Rivest, co-inventor of the RSA Scheme. It is used in a number of commercial systems like Lotus Notes and Netscape. It is a cipher with a key size of up to 2048 bits (256 bytes), which on the brief examination given it over the past year or so seems to be a relatively fast and strong cypher. It creates a stream of random bytes and 'XORing' those bytes with the text. It is useful in situations in which a new key can be chosen for each message.

script.aculo.us

script.aculo.us is a JavaScript library built on the Prototype JavaScript Framework, providing dynamic visual effects and user interface elements via the Document Object ModelIt is most notably included with Ruby on Rails, but also provided separately to work with other web application frameworks and scripting languages.
script.aculo.us was extracted by Thomas Fuchs from his work on fluxiom, a web based digital asset management tool by the design company wollzelle. It was first released to the public in June 2005.

Features

script.aculo.us extends the Prototype Javascript Framework by adding visual effects, user interface controls, and utilities.

edit Visual Effects

There are five core effects script.aculo.us offers: Opacity, Scale, MoveBy, Highlight, and Parallel. Through these effects there are over 16 additional effects using combinations of the core effects out of the box. Programmers can even extend and make new effects.

Enabling an effect is a matter of assigning an element with an ID name and one line of code for the effect. Below is an example for the Effect.Fade effect applied to a DOM element with ID of 'id_of_element':

new Effect.Fade('id_of_element');

This will cause the target ID to fade in opacity and end by setting the CSS display property of none.
You can also modify various settings with in the effect such as duration of the effect and range of the effect:

new Effect.Fade('id_of_element',
 { duration:2.0, from:0.0, to:0.8 });

This would fade the element, but stop when the effect is 80% complete (with an opacity of 20%).

Controls

Controls offers user interface elements including:

• Drag And Drop
  
  
  
  • Draggables
    
  
  
  • Droppables
  
  
  • Sortables
  
  
  • Slider
    


• Autocompletion


• In Place Editing
  

Builder

Builder allows the creation of DOM elements dynamically. Using the sample code below:

 element = Builder.node('div',{id:'ghosttrain'},[
 Builder.node('div',{className:'controls',style:'font-size:11px'},[
   Builder.node('h1','Ghost Train'),
   "testtext", 2, 3, 4,
   Builder.node('ul',[
     Builder.node('li',{className:'active', onclick:'test()'},'Record')
   ]),
 ]),
]);

Creates the following (without newlines):

 <div id="ghosttrain">
 <div class="controls" style="font-size:11px">
   <h1>Ghost Train</h1>

   testtext234
   <ul>
     <li class="active" onclick="test()">Record</li>
   </ul>
 </div>
</div>

Usage

Incorporating script.aculo.us into a website requires copying all javascript files in a folder and the following lines inserted in the head of an HTML document:

<script src="javascripts/prototype.js" type="text/javascript"></script>
<script src="javascripts/scriptaculous.js" type="text/javascript"></script>

These lines must be loaded first before any javascript requesting any Prototype or script.aculo.us functions. Once loaded, these functions can be called in any valid javascript location including script tags and event handlers.

References

^ http://ajaxian.com/archives/audible-ajax-episode-12-thomas-fuchs-of-scriptaculous

Related links

• script.aculo.us homepage
  

Prototype JavaScript Framework

The Prototype JavaScript Framework is a JavaScript framework that provides an Ajax framework and other utilities. Though available as a standalone library, Ruby on Rails integrates the framework as well as other projects such as script.aculo.us and Rico

Features

Prototype provides various functions for developing JavaScript applications. The features range from programming shortcuts to major functions for dealing with XMLHttpRequest

Sample utility functions

The $() function

To refer to an element in the DOM of an HTML page, the usual function identifying an element is:

document.getElementById("id_of_element")

The $() function reduces the code to:

$("id_of_element")

This function can be used as the getElementById() function. For example, you can set the CSS text color with this code:

$("id_of_element").style.color = "#ffffff";

The $F() function

Building on the $() function: the $F() function returns the value of the requested form element. For a 'text' input, the function will return the data contained in the element. For a 'select' input element, the function will return the currently selected value.

$F("id_of_input_element")

Note: Like the underscore _, the $ character is a legal "word character" in JavaScript identifiers, and has no other significance in the language. It was added to the language at the same time as support for regular expressions, so that the Perl-like matching variables could be emulated, such as $` and $'.

The Ajax object
In an effort to reduce the amount of code needed to run a cross-browser XMLHttpRequest function, the Ajax object offers an easier way to invoke the function without the need to code with specific browsers in mind. There are two forms of the Ajax Object. Ajax.Request returns the raw XML output from an AJAX call, while the Ajax.Updater will inject the return inside a specified DOM object.

The Ajax.Request below finds the values of two HTML value inputs, requests a page from the server using the values as POST values, then runs a custom function called showResponse() when complete:

var value1 = $F("name_of_id_1");
var value2 = $F("name_of_id_2");
var url = "http://yourserver/path/server_script";
var pars = "value1=" + value1 + "&value2=" + value2;

var myAjax = new Ajax.Request(
  url,
      {
               method: "post",
               parameters: pars,
               onComplete: showResponse
      });

Prototype Javascript Framework home page

Official Prototype API documentation

Official Prototype API documentation (PDF book)

Sergio Pereira's Prototype API documentation

Prototype Window Library

Rico - A Prototype Based Library

Working With Events In Prototype

Prototype JavaScript Framework documentation wiki with examples

Ajax basics

Using Ajax

Page update without refresh using Javascript, PHP
and XML's XMLHTTPRequest object (also known as 'remote
scripting')

In this tutorial we'll discuss the basic principles of remote scripting using Ajax, a combination of javascript and XML to allow web pages to be updated with new information from the server, without the user having to wait for a page refresh. Ajax therefore allows us to build web applications with user interfaces rather more like those of desktop applications, providing a better experience for the user. Ajax tools are becoming increasingly popular, and a list of ajax development projects is also given.

Keen to learn more? I have a website dedicated entirely to Ajax, at CrackAjax.net, where you'll
find more tutorials, example code and fully-worked projects

Here you'll find:

• a brief tour of the important principles of
  Ajax
  
• code examples of all important
  points
  
• links to further Ajax and related
  resources

This tutorial covers subjects which require some degree

of familiarity with Javascript and PHP. Beginners may therefore find it a
little hard going, but hopefully should still be able to grasp the principles
and uses of Ajax, if not the details. There are some demos and
further links at the bottom of the article and elsewhere on these pages - feel
free to explore..

What is it?
The standard and
well-known method for user interaction with web-based applications involves the
user entering information (e.g. filling out a form), submitting that information
to the server, and awaiting a page refresh or redirect to return the
response from the server.

This is at times frustrating for the user, besides being rather different to

the 'desktop' style of user interface with which (s)he may be more familiar.

Ajax (Asynchronous Javascript And XML) is a
technique (or, more correctly, a combination of techniques) for submitting
server requests 'in the background' and returning information from the server to
the user without the necessity of waiting for a page load.

Ajax is actually a combination of several technologies working together to
provide this capability.

How does it work?
Instead of a user request being made of the server via, for example, a normal HTTP POST or GET request, such as would be made by submitting a form or clicking a hyperlink, an Ajax script makes a request of a server by using the Javascript XMLHTTPRequest object.

Although this object may be unfamiliar to many, in fact it behaves like a
fairly ordinary javascript object. As you may well know, when using a
javascript image object we may dynamically change the URL of the image source
without using a page refresh. XMLHTTPRequest retrieves
information from the server in a similarly invisible manner.

How is it coded?
There are a
few, relatively simple, steps to coding an Ajax application. The
description below is an attempt to describe the salient points without bogging
down the new user in too many of the technicalities.

Firstly, we need to know how to create an
XMLHTTPRequest object. The process differs slightly depending on
whether you are using Internet Explorer (5+) with ActiveX enabled, or a
standards-compliant browser such as Mozilla Firefox.

With IE, the request looks like:

http = new
ActiveXObject("Microsoft.XMLHTTP");

whereas in a standards-compliant browser we can instantiate the object directly:

http = new
XMLHttpRequest();

There's an example of a short piece of code to create the object here, which clearly demonstrates the different approaches for
the two different browser types, along with a browser detection routine.

Secondly, we need to write an event handler

which will be called via some event on our user's page, and will handle sending
our request for data to our server.

The event handler will use various methods of our
XMLHTTPRequest object to:

• make the request of the server
  
• check when the server says that it has completed the request, and
  
• deal with the information returned by the server
  

We can make our request of the server by using a GET method to an appropriate
server-side script. Here's an example event handler
called updateData which assumes that we have created our

XMLHTTPRequest object and called it http:

function updateData(param)
{
var myurl = [here I insert the URL to my server script];

http.open("GET", myurl + "?id=" +
escape(param), true);


http.onreadystatechange = useHttpResponse;

http.send(null);

}

Note that the function listens to the

onreadystatechange property of the
XMLHTTPRequest object and, each time this parameter changes,
calls a further function useHttpResponse.

You will note also that, for the sake of clarity, I have said little
about the server-side script which is called - essentially this can be any
server routine which will generate the required output when called with the
relevant URL and appended parameters, as in any other HTTP GET request.
For the sake of the example we are passing a variable named id
with a value param passed as an argument to the
updateData function.

Thirdly, then, we need to write a
function useHttpResponse which will establish when the server
has completed our request, and do something useful with the data it has
returned:

function useHttpResponse() {
if (http.readyState
== 4) {
var textout =
http.responseText;

document.write.textout;
}
}

Note here that our function checks for a readyState value of

4 - there are various numbered states describing the progress
of such a request, but we are only interested in the value of 4, which indicates
that the request is complete and we can use the returned data.

In this case, we have received our information as simple text via the

responseText property of our XMLHTTPRequest
object. Information can, however, be returned as XML or as properties of a
predefined javascript object, though this is perhaps beyond the scope of this
tutorial.

Making Ajax Easy

There are quite a few toolkits springing up that package the Ajax calls into
useable libraries. You've probably heard of some of the popular
toolkits and frameworks such as those by telerik and
jackbe. For small projects, these may not
be worth using due to the code overhead and learning curve involved, but for
more complex Ajax projects you may find them useful. You'll find some
relevant links below and elsewhere on these pages - feel free to
explore.

JavaScript Recomendations for AJAX Component Writers

With AJAX there are many choices on how to use different aspects of JavaScript. Here are some recommendations we came up with for using JavaScript with the focus on creating AJAX components that will interact with a Java technology based server. Each of these recommendations is linked to a larger document that contains more details and in many cases code samples.
* Use JavaScript Programming Conventions
Standardize style makes code easy to work with and maintain especially in larger organizations. See the of JavaScript Programming Conventions created by the Dojo folks.
* Use object oriented JavaScript
Writing object orient JavaScript will allow for code re-use, enables you or others to extend your objects, and allows your scripts to be loaded and initialized dynamically.
* Use object hierarchies to organize JavaScript objects
When writing components use objects and object hierarchies to organize related objects and prevent naming collision.
* Use the prototype property to define shared behavior and to extend objects
Use the prototype property to extend, add functionality, or provide defaults to your objects. Use the prototype property to define shared functions (behavior) across instances of an object as it will reduce the number of objects in JavaScript and its use provides a good separation of behavior from data.
* Store state specific to the view in JavaScript and state that span pages on the server
Store view state related to a specific page using JavaScript objects. Keep in mind that JavaScript objects are specific to a HTML page and will be lost if the "Reload" button is pressed, if the browser is relaunched/crashes, or if you navigate to another page. Store state that spans pages on the server as Java objects scoped to the HttpSession. The client and server objects should be synched on page refreshes and page loads.
* Write reusable JavaScript
JavaScript should not be tied to a specific component unless absolutely necessary. Consider parameterizing data in your functions instead of hard coding the data.
* Use object literals as flexible function parameters
Object literals are very handy in that they can be used as generic for passing in arguments to a function. Since the function signature does not change if you choose to require more properties in a function, consider using an object literal as the parameter for a function.
* Compress your JavaScript
Not to be confused with a zip compression scheme compression refers to removing the white spaces and shortening the names of variables and functions in a file. Consider compressing your JavaScript resources when you deploy your application.
* Do not compress your Jar files that contain your scripts
Do not use zip compression on jar files with scripts or styles that are served by a server side component. Compressing those jars will cause the server to decompress the file for each client request for the script or resource. Larger scripts could cause performance problems for your server.
* Protect your server side assets
Never put business logic or server-side access code in JavaScript. Always validate request parameters on the server regardless of whether the request originated from an AJAX client or not.
* Consider loading JavaScript on demand
JavaScript may be loaded dynamically at runtime using a library such as JSAN or done manually by using AJAX to load JavaScript code and calling eval() on the JavaScript. This is useful if you have a large library or set of libraries.
* Consider using JSON for model data transport
While the XML is still a valid format for model data transport in AJAX (especially in cases where you're communicating with XML based services or your services must also address non-AJAX based clients), you should consider using JSON to communicate data from your server to your JavaScript based client.
* Provide a clean separation of content, CSS, and JavaScript
A rich web application user interface is made up of content (HTML/XHTML), styles (CSS), and JavaScript. JavaScript is invoked by user gestures such as mouse clicks and can manipulate the content. Separating the CSS styles from the JavaScript is a practice which will make your code more manageable, easier to read, and easier to customize. It is recommended that the CSS and JavaScript are placed in separate files.
* Avoid static content in JavaScript
Keep the amount of static HTML/XHTML content in JavaScript to a minimum. This will make managing the source and updating static content easier. You may want the content in your components updateable without changing your source.
* Use caution with element.innerHTML
If you choose to use element.innerHTML try to write JavaScript that generates minimal HTML. Rely instead on CSS for enhancing the presentation. Remember to always strive to separate content from presentation. Make sure to de-register event listeners in the existing innerHTML of the element before re-setting the element.innerHTML as it will lead to memory leaks. Keep in mind that instances of DOM elements inside the element.innerHTML are lost when you replace the content and references to those elements will be lost as well.
* De-reference unused objects
Make sure you de-reference variables when they are no longer needed so they may be garbage collected. If you are using element.innerHTML, make sure you de-reference any listeners in the code before it is replaced.
* Use care with closures
If you use closures take caution not to hold on to references to browser objects such as DOM related objects using the local variables of a closure as this can lead to memory leak. Objects are not garbage collected until all references to objects are gone. Make sure you understand closures in order to avoid creating them accidentally.
* Enable resource overrides in your components
Provide a means to override the loading of resources such as dependent scripts, CSS files, or images by your JavaScript centric, JSP, Servlets, or JSF components. If you jar your component for distribution with a JSP tag or JSF component, move those resource files into the WEB-INF directory and create code to stream them out to the client. This will allow your customers to customize the component styles or JavaScript on a case by case basis without rebuilding and re-packaging the component.
* Design with I18n in mind
Internationalization should not be an after thought. From the JavaScript client's perspective you need to do two things: Set the page encoding and make sure localized text is passed back to your server backend. Consider using XML as the return content type for localized data as XML can specify encoding information that is understood and applied by the XMLHttpRequest object. If you are passing around localized content you need to make sure you server encodes the return content properly.

Top mistakes when using AJAX

Top mistakes when using AJAX

1. 
   Don't use AJAX to update the complete page by putting everything in a UpdatePanel. You want to save time and traffic when running the web page. Never update parts of the web site that can be changed using JavaScript and DHTML (DOM).
   


2. 
   Have in mind that there are a couple of visitors that have JavaScript disabled or using a web browser with an older or less JavaScript implementation like the most mobile devices have. What does your visitor see if everything is disabled? I don't recommend to have the full web site available as a JavaScript disabled version!
   


3. 
   Cache the same requests on client-side web browser or implement any caching on the web server. The most used scenarios like AutoComplete or DropDown fields are filled everytime the same. A wrong written AutoComplete can slow down your web server (database server) because there more requests done than the version before using PostBacks. Think of pressing F5 (reload) all the time with your old web site. If you have cascading DropDown you can save more traffic/requests!
   


4. 
   Don't run concurrent or long running AJAX requests when using CSS or JavaScript to change the UI. There are only two concurrent http connections possible with all common web browsers (I know you can change this, but the default behavior is set to two). If there are running to many AJAX requests running loading of images will be slow down.
   


5. 
   Use everytime the asynchrouns invoke of the send method of XMLHttpRequest. There is no issue where you want to use the synchronous one. Your web browser will not be forozen when having network problems or slow connections.
   


6. 
   Try your web application using a very slow internet connection. Try it again using a TCP/IP connection with a very high latency for each paket.
   


7. 
   Is your web application running as a desktop replacement? Have a look at the memory usage of common web browsers if you run your application one hour, two hours or couple of days. Not everybody has a development machine like yours!
   


8. 
   Check the http status code you will get back from XMLHttpRequest. There are a couple of common network errors like DNS not available, http server error 500. Did you ever checked for the status code which tells you if your web browser is in offline mode?
   


9. 
   Try to disable the XMLHttpRequest object! With IE7 you can use the native object instead of the ActiveX object, but you can still disable the native object, too.
   


10. 
    Check your AJAX requests for security issues! Did you simple open all your data access layers? Make use of FormsAuthentication and PrincipalPermissions on ASP.NET. Can anybody create requests (not only by clicking on a link)?
    


11. 
    A loading indicator is, of course, very important. This should be added to requests that are slower than usal and to actions that need more time (not requests that are running long time on the server, see above).
    


12. 
    The back button is not very easy to talk about because it depends on what you are doing with AJAX or Web 2.0. If you do complete page updates (so you replace the common page refresh only) you should have an option to use the back button. In a lot of web applications I've done there AJAX is more used to update monitors, run some actions like delete, save,... and there a back button is not needed. The UI should implement there an undo feature i.e. instead.
    


13. 
    A machanism to cancel a requests often isn't as easy as simple call the abort method on XMLHttpRequest because the requests is already running on the web server. The same will happen when you close your web browser during a request. So, there is a need for this but my opinion is that it is not very easy to implement.
    


14. 
    The last issue Dave is talking about is a application feature which is interessting, but is not a Web 2.0 or AJAX related new issue, everyone is interested in script errors.