/
ENCRYPT1_4.html
166 lines (147 loc) · 6.53 KB
/
ENCRYPT1_4.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
<!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>