<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Mozilla/4.79 [en] (X11; U; SunOS 5.8 sun4u) [Netscape]">
</head>
<body>
<blockquote>
<blockquote>
<blockquote>
<h1>
<b>Encryption Protocol Document</b></h1>
</blockquote>
</blockquote>
</blockquote>
<b>(Author : Mandar Shinde)</b>
<h1>
<b>Introduction</b></h1>
This document is required to be read by both the developers and the users.
The
<br>ENCRYPT protocol will not work by directly compiling the javagroups
source
<br>and then using the required "encrypt.xml" file. Since an external provider
needs
<br>to be used (JDK1.4 does not provider for RSA as of now), hence this
provider
<br>needs to be added to the users/developers security list.
<br>
<h1>
<b>Installation</b></h1>
The following steps need to be followed to make sure that ENCRYPT protocol
<br>can ne used
<br>
<ul>
<li>
Make sure that JDK1.4 is installed, ENCRYPT will not work with any other<br>
version under JDK1.4.</li>
<li>
After installation JDK1.4, set <b>$JAVA_HOME</b> to the installation root.</li>
<li>
<b>cd $JAVA_HOME/jre/lib/security</b>. Open <b>java.security</b> file.</li>
<li>
Search for <b>security.provider.{list}</b> in the opened file.</li>
<li>
At the end of the list <b>add</b> <b><i>Provider.{list+1}=org.bouncycastle.jce.provider.BouncyCastleProvider</i></b>.</li>
<li>
The above provider is the default provider that comes along with Javagroups; <br>
users can use their own providers by adding the right provider jars in
the classpath<br>
and adding the provider to the required list.</li>
<li>
The <i>encrypt.xml </i>file is the default configuration on top of <i>default.xml.
</i>Any stack can use the <br>
<b>Encrypt protocol</b> by adding this stack below GMS.<br>
<protocol></li>
<br>
<protocol-name> Encryption Protocol </protocol-name>
<br>
<description> Protocol provides encryption to all communication </description>
<br>
<class-name>org.jgroups.protocols.ENCRYPT1_4</class-name>
<br>
<protocol-params>
<br>
<protocol-param name="asymInit" value="512"/>
<br>
<protocol-param name="symInit" value="56"/>
<br>
<protocol-param name="asymAlgorithm" value="RSA"/>
<br>
<protocol-param name="symAlgorithm" value="DES/ECB/PKCS5Padding"/>
<br>
</protocol-params>
<br></protocol></ul>
<h1>
<b>Demo</b></h1>
To test the usage of the protocol use any demo; I have used the Draw demo
for this purpose;.
<ul>
<li>
First up uncomment the Print protocol and comment the Encrypt protocol
from the <br>
encrypt.xml file. When the Draw demo is used, the user will see the deserialized<br>
messages being exchanged between the 2 members.</li>
<li>
Now, uncomment the Encrypt protocol (leave the Print Protocol intact)
from the protocol <br>
stack. Run the same demo as above; the user will see that an ioexception
will thrown while <br>
deserializing the message because it has been encrypted by the Encrypt
protocol.</li>
</ul>
<b></b>
<h1>
<b>How does Encrypt protocol <i>work</i></b> ?</h1>
The mechanism used by this protocol is the oldest know way for high performing
peer communication
<br>protocols. To understand the working a couple algos need to be
detailed; these are very basic in
<br>today's encryption world.
<br><b>Asymmetric algo:</b> this algo uses a set of keys; a <i><b>public-key</b>
</i>and a <i><b>private-key</b>. </i>The<b> public-key</b> is
<br>public; it is published to the public. The <b>private-key</b> is known
only to the entity which makes the
<br>public-key available. Any other entity will <b><i>encrypt a message
</i></b>using the former <b><i>public-key </i></b>and the
<br>former will <b><i>decrypt the message </i></b>using the<b><i>
private-key.</i></b>
<br><b>Symmetric algo</b>: this algo is the simplest known where a set
of communication peers know a single
<br>shared <b><i>secret-key(private-key) </i></b>and <b><i>ecrypt/decrypt
</i></b>messages to communicate with each other.
<br><b>Final algo : </b>It is obvious that the asym algo seems more powerful
than the symm algo. But, the asym
<br>algorithm is very expensive and the symm algorithm has a basic fault
on how to distribute the key. A
<br>combination where the asym algo is used only for handshake and distribute
the shared key is the best bet.
<br>Only when a member leaves does it require to re-generate a shared key.
<br>
<h1>
<b>Step-by-Step</b></h1>
<ol>
<li>
The first-member in the group becomes the admin and <i>generates</i> the
<i>shared-key</i>.</li>
<li>
When a new peer requests to join, the <i>new-member</i> publishes its public-key.</li>
<li>
Using the <i>public-key</i> the admin encodes its <i>shared-key</i>.</li>
<li>
Using its own <i>private-key</i>, client decodes the <i>shared-key</i>.</li>
<li>
New member lets the admin know, it is <i>ready</i>.</li>
<li>
Members use <i>shared-key to encrypt/decrypt messages</i>.</li>
<li>
When member leaves, admin <i>regenerates</i> <i>shared-key</i>. If admin
leaves, another member becomes admin <br>
and regenerates key.</li>
</ol>
<ul>
<br>
<br>
<br> </ul>
</body>
</html>
