3 <title>SILC Protocol White Paper</title>
4 <link rev=made href="mailto:priikone@silcnet.org">
5 <meta name="Author" content="Pekka Riikonen - SILC Project">
6 <meta name="Description"
7 content="SILC - Secure Internet Live Conferencing Protocol">
8 <meta name="Created" content="Version 1.0 / 05 Aug 2001">
10 <body bgcolor="#ffffff">
12 <font face="Helvetica">
14 <font size="10"><b>SILC Protocol White Paper</b></font><br>
15 <font size="2">Version 1.0 / 05 Aug 2001</font>
20 Chat protocols are very popular on the Internet. They have actually
21 been very popular since the very first chat protocols appeared on the net.
22 The Internet Relay Chat (IRC) was one of the first chat protocols, and quickly
23 gained the status of being the most popular chat on the net. Today, IRC
24 has several competitors from various other so called Instant Messaging (IM)
25 protocols, such as ICQ. However, all of these different chat protocols
26 have something in common; they are all insecure.
29 The security is important feature in applications and protocols in
30 contemporary network environment. The older chat protocols, however have
31 failed to deal with the growing security requirements on the Internet.
32 It is not anymore enough to just provide services, like for example
33 chat services. Now, they need to be secure services.
36 The Secure Internet Live Conferencing (SILC) protocol is a new generation
37 chat protocol which provides full featured conferencing services, just
38 like any other contemporary chat protocol provides. In addition, it
39 provides security by encrypting and authenticating the messages in
40 the network. The security has been the primary goal of the SILC protocol
41 and the protocol has been designed from the day one security in mind.
42 All packets and messages travelling in the SILC Network are always
43 encrypted and authenticated. The network topology is also different
44 from for example IRC network. The SILC network topology attempts to be
45 more powerful and scalable than the IRC network. The basic purpose
46 of the SILC protocol is to provide secure conferencing services.
49 The SILC Protocol have been developed as Open Source project. The
50 protocol specifications are freely available and they have been submitted to
51 the IETF. The very first implementations of the protocol are also already
55 <h1>About This White Paper</h1>
57 The purpose of this white paper is to give short but deep enough introduction
58 to the SILC Protocol. The document describes the purpose of the protocol
59 and how the protocol works in practice. This document is intended for all
60 audience. This document should be easy to understand for non-technical
61 person and still be detailed enough for technically oriented person. See
62 the section <a href="#terms">Terms and Abbreviations</a> for terms used
67 (c) Copyright 2001 Pekka Riikonen
68 (<a href="mailto:priikone at silcnet.org">priikone at silcnet.org</a>)
70 This document is free document; you can redistribute it and/or modify
71 it under the terms of the GNU General Public License as published by
72 the Free Software Foundation; either version 2 of the License, or
73 (at your option) any later version. This document is distributed in
74 the hope that it will be useful, but WITHOUT ANY WARRANTY; without even
75 the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
76 See the GNU General Public License for more details.
80 <h1>SILC Protocol</h1>
83 <img src="silc_network.JPG" alt="SILC Network" align="center" border"0">
89 A client is a piece of software connecting to SILC server. The software
90 is usually run by the end user, a real person that is. The purpose of the
91 clients is to provide the end user an interface to the SILC services.
92 They are used to actually engage the conversations on the SILC Network,
93 and they can be used to execute various SILC commands.
96 The clients are distinquished from other clients by unique Client ID.
97 There cannot be multiple same Client IDs in the SILC Network at the same time.
98 The end user, however does not use Client IDs. The end users usually selects
99 a perferred nickname they want to use, and identifies themself with that
100 nickname to other users on the network. The nicknames are not unique in
101 the SILC Network. There can be multiple same nicknames at the same time
102 on the network. The maximum length for the nickname is 128 characters.
105 Most of the other chat protocols have unique nicknames. This is where SILC
106 differs from most of the other chat protocols. The purpose of this
107 feature is to make IRC style nickname wars obsolete, as no one owns their
108 nickname; there can always be somene else with the same nickname.
111 When client connects to the server the SILC Key Exchange (SKE) protocol and
112 SILC Connection Authentication protocol are executed. The result of the
113 SKE protocol is the session key that the client and server use to secure
114 their communication. All commands, for example, that the client sends
115 to the server are secured with the session key. The session key expires
116 periodically and the rekey process can be executed with or without the
117 Perfect Forward Secrecy (PFS). The connection authentication protocol is
118 used to authenticate the client to the server. The server may allow the
119 client to connect without authentication, or it may require a passphrase or
120 public key encryption based authentication.
127 Servers forms the basis for the SILC Network, by providing a point to which
128 clients may connect. There are two kinds of servers in SILC; normal servers
129 and router servers. The next section describes the function of router
133 Normal servers connect to router server. Normal servers cannot directly
134 connect to other normal servers. Messages that are destined outside the
135 local server are always sent to the router for further routing.
136 The clients usually connect to the normal server, however, clients may
137 connect to router servers as well. The SILC Network diagram above
138 illustrates how normal servers connects to the router server.
141 The servers are distinquished by other servers in the network by unique
142 Server ID. There cannot be multiple same Server IDs in the SILC Network
143 at the same time. The servers keep track of local information. It knows
144 all locally connected clients and it knows all channels that its clients
145 have joined. However, it does not know any global information. It
146 usually does not keep track of global clients, however, it may cache
147 that information if it was queried. The reason for this is that the
148 server does not need to keep global information up to date and thus
149 makes the server faster. They can always query the information from
153 When server connects to its router the SILC Key Exchange (SKE) protocol
154 and the SILC Connection Authentication protocol are executed, just like
155 when client connects to server. The SKE results in to the session key
156 that is used to secure the communication between the server and the
157 router. The connection authentication protocol is used to authenticate
158 the server to the router. The authentication is always based in either
159 passphrase or public key encryption.
166 The router servers are servers that actually handles the message routing
167 in the network. They are, however also normal servers and they do accept
168 client connections. Each of the router in the network is called a cell.
169 A cell can have only one active router and it may have several servers
170 and several clients. The cell, however may have backup routers that can
171 take over the tasks of the primary router if it becomes unresponsive.
172 The switch to the backup router should be transparent and only local
173 connections to the primary router are lost. Other connections in the
174 cell are intact, and clients and servers merely experience some lag in
175 the network connection during the switch to the backup router.
178 The normal server knows only local information. Router server on the
179 other hand knows local information and global information. It considers
180 the cell as local and outside cells as global. It knows all the clients
181 connected to the network, all created channels, and all routers and servers
182 in the network. The server may query the global information if it is needed.
183 For example, when client sends WHOIS command, the server may query the
184 information from the router. If the router does not know all the details
185 that the WHOIS command requires it can query the information from a router
186 or a server which knows all the details. It may then cache that information.
189 The primary purpose of the router server is to route the messages to
190 local servers and local clients, and messages that are destined to outside
191 the cell are routed to the primary route or some other secondary
192 route if it is a faster route. The routers in the network forms a ring.
193 Each router has a primary route to other router in the network. Finally
194 the ring is closed by the last router using the first router in the
195 network as its primary route.
198 <img src="silc_routers.JPG" alt="SILC Routers" align="center" border"0">
201 The diagram above illustrates how the routers forms a ring in the network.
202 A router may have several secondary routes which it may use when it
206 When routers connect to its primary router the SKE and the SILC Connection
207 Authentication protocols are executed just like when normal server connects
208 to its router. The session key is used to secure the communication between
209 the routers. All the secondary routes also have their own session keys.
213 <h1>SILC Packet Protocol</h1>
216 <img src="silc_packet.JPG" alt="Typical SILC Packet" align="center" border"0">
221 <h1>SILC Key Exchange Protocol</h1>
226 <h1>SILC Connection Authentcation Protocol</h1>
236 <h2>Channel Message Delivery</h2>
239 <img src="silc_channel.JPG" alt="Channel Message Delivery" align="center" border"0">
242 <h2>Channel Message Delivery With Channel Private Key</h2>
247 <h1>Private Messages</h1>
249 Private messages are messages that are sent from one client to another
250 through the SILC Network. They are private because they are not sent to
251 anyone else except to the true receiver of the message. Private messages
252 can be used to engage private conversation with another client if channels
256 As all messages in SILC the private message are also encrypted and
257 authenticated. There are several ways to secure private messages. By
258 default private messages are encrypted using the session keys established
259 in the SKE protocol. It is also possible to negotiate a private message
260 key between the two clients and encrypt the messages with that key. It
261 is even possible to encrypt the messages with public key cryptosystem,
262 if desired. The next sections will describe all these private message
266 The SILC protocol provides these three methods of delivering private messages
267 because none of the methods alone can satisfy the security requirements
268 of all people. The end user should decide the acceptable level of risk,
269 the required level of security and other security and usability aspects when
270 deciding what way of sending private message suites for them.
274 <h2>Private Message Delivery With Session Keys</h2>
276 Sending private messages are by default secured with session keys established
277 in the SKE protocol. This means that the private message is always encrypted
278 with the session key of the next receiver of the message enroute to the
279 receiving client. This also means that the message is decrypted and
280 re-encrypted everytime it is sent further to the receiving client.
283 <img src="silc_priv1.JPG" alt="Basic Private Message Delivery" align="center" border"0">
286 As the above diagram shows the private messages sent by Client A to the
287 Client B travels through the SILC Network and is always decrypted and
288 re-encrypted with the session key of the next receiver. The Client B then
289 finally decrypts the private messages that is encrypted with the session
290 key shared between the Client B and the Server Y.
293 This way of securing private messages is not perfect and cannot be used
294 in all circumstances. If the clients having the conversation cannot trust
295 the servers and routers in the SILC Network they should not send private
296 messages that are secured in this manner. Messages secured in this manner
297 can be decrypted by the servers and routers that the clients may consider
301 If the clients on the other hand trust the servers and routers in their
302 SILC Network, or they do not care that servers can decrypt their messages,
303 sending private messages in this way is very simple from client's point
304 of view. For servers and routers this of course means that they need
305 to decrypt and re-encrypt each private message. Since this way of securing
306 private message cannot be used at all times the SILC protocol provides
307 other ways of securing private messages.
311 <h2>Private Message Delivery With Private Message Key</h2>
313 Private messages can be secured with private message key as well. This
314 key is known only by the sender of the message and the receiver of the
315 message. This way no one else except the sender and the receiver can encrypt
316 and decrypt the private messages. The message is encrypted by the sender
317 with the private message key and all the servers and routers pass the message
318 through enroute to the receiver. They cannot decrypt the message since
319 they do not have the key. When sending private messages in this way it
320 does not matter whether the clients trust or do not trust the servers and
321 routers in the SILC network.
324 <img src="silc_priv2.JPG" alt="Private Messages with Private Message Key" align="center" border"0">
327 As the above diagram shows the Client A encrypts the message with private
328 message key and sends the message to the SILC Network. All servers and
329 routers merely pass the message through since they cannot decrypt it.
330 The Client B then receives the message and decrypts it with the private
334 Sending private messages in this manner is always secure since the key is
335 shared only by the sender and the receiver. The problem of this method
336 is that the sender and the receiver must somehow agree about the key
337 they are going to use. The private message key can generally be anything.
338 It can be a passphrase that only the sender and the receiver knows. They
339 could have been agreed to use some word or phrase as the key sometime
340 earlier before they started the conversation. Or the key maybe from some
341 random string from a code book that only the sender and the receiver poses.
342 Or it can be a key that is negotiated using some key negotiation protocol.
345 The problem however is fundamental. How to agree to use some key when
346 you cannot reach the other person over secure channel? The SILC protocol
347 solves this problem by providing a possiblity to negotiate the key
348 between two clients using the SKE protocol. One or both of the clients
349 can set up the SKE server running in their host and ask the other client
350 to connect to it. As a result of the SKE protocol the clients have
351 now shared secret that they can use as private message key. The key
352 is known only by the two clients that exexcuted the SKE protocol. They
353 can then use that key to secure all subsequent private messages.
356 Using this method of private messages delivery is recommended if the
357 clients cannot trust the servers and routers in the SILC Network. The
358 drawback is the extra phase of setting the private message key before
359 starting the conversation. However, using the SKE protocol is the
360 recommended way to negotiate the private message key since it can be
361 automized and does not cause any extra tasks for end user.
365 <h2>Private Message Delivery With Public Key Encryption</h2>
367 If the clients cannot trust the servers and routers in the SILC Network
368 they can use the private message key. As described in the previous section
369 it is easy to set up with the SKE protocol. However, sometimes the two
370 clients do not want to use any passphrases as private message key or
371 negotiate the key with SKE, or perhaps they are unable to negotiate the
372 key because of some other external problem. The SILC protocol provides
373 yet another way of securing the private messages. This way does not
374 require setting or negotiating private message key. And, in this method
375 also it does not matter whether the clients trust or do not trust the
376 servers and routers in the SILC Network. The method is public key
377 encryption. The clients can encrypt the private messages with the
378 receiver's public key and send the message to the network. The servers
379 and routers cannot decrypt the messages since they do not have the
380 receiver's private key. The receiver on the other hand has the private
381 key which it uses to decrypt the message.
384 <img src="silc_priv3.JPG" alt="Private Messges with Public Key Cryptosystem" align="center" border"0">
387 As the above diagram shows the Client A has the Client B's public key.
388 It will encrypt the message with that key and sends the message to the
389 SILC Network. All servers and routers pass the message through since
390 they cannot decrypt it. The Client B then uses its private key to
391 decrypt the message. The Client B has also the Client A's public key
392 that it can use to encrypt messages that it will send to Client A.
395 Even this method of private message delivery is not perfect. The drawbacks
396 of this method is that the public key encryption process, as being
397 assymmetric cryptosystem, is much slower than encryption process with
398 symmetric cryptosystems. This is not probably problem with short messages
399 but may be inconvenient with long messages. The other drawback is that the
400 sender must first assure that the public key it is using in the encryption
401 is actually the receiver's public key. This is a absolute requirement
402 in this method. If the sender cannot authenticate the receiver's public
403 key this method of private message delivery should not be used. In SILC
404 protocol clients can fetch other clients public keys from servers.
405 However, the servers may not have authenticated the fetched public key so
406 that should not be fully trusted. Use of certificates can solve the
407 problem. The receiver's certificate could be authenticated by a third
408 party Certificate Authority (CA).
411 Usually verifying the public key is not a problem since the receiver
412 can provide the public key on some website, or verify the fingerprint of
413 the key over email, or phone call. The clients can also fetch the
414 public keys from SILC servers if they trust that the keys are authentic.
415 If both of the clients trust that the public keys are authentic using this
416 method of private message delivery is very simple and recommended.
424 <h1>Further Information</h1>
426 More detailed information about the SILC Protocol is available in the
427 SILC Protocol specification documents. There exists currently four
428 Internet Drafts that defines the protocol in great detail. The Internet
429 Drafts are available from the following sources but also from the
430 <a href="http://www.ietf.org">IETF website</a>.
433 - <a href="http://silcnet.org/docs/draft-riikonen-silc-spec-03.txt">
434 Secure Internet Live Conferencing (SILC), Protocol Specification</a>
437 - <a href="http://silcnet.org/docs/draft-riikonen-silc-pp-03.txt">
438 SILC Packet Protocol</a>
441 - <a href="http://silcnet.org/docs/draft-riikonen-silc-ke-auth-03.txt">
442 SILC Key Exchange and Authentication Protocols</a>
445 - <a href="http://silcnet.org/docs/draft-riikonen-silc-commands-01.txt">
452 <h1>Terms and Abbreviations</h1>
projects / runtime.git / blob