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="7"><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 The basis of SILC protocol relies in the SILC packets and they are with
217 out a doubt the most important part of the protocol. The SILC Packet
218 protocol is a binary packet protocol. The protocol provides secure
219 binary packets and assures that the contents of the packets are secured
223 Packets are used in the SILC protocol all the time to send for example
224 channel messages, private messages, commands and other information. All
225 packets in SILC network are always encrypted and their integrity is
226 assured by computed Message Authentication Codes (MAC). The protocol
227 defines several packet types and packet payloads. Each packet type
228 usually has a specific packet payload that actually defines the contents
229 of the packet. Hence, the actual data in the packet is the packet payload
230 defined in the protocol.
233 <img src="silc_packet.JPG" alt="Typical SILC Packet" align="center" border"0">
236 As the diagram above illustrates the SILC packet is constructed from the
237 SILC Packet Header that is included in all SILC packets, data area that
238 includes the packet payloads, and MAC area which assures the integrity of the
239 packet. Entire SILC packet is always encrypted, except for the MAC area
240 which is never encrypted. The encryption process and the key used,
241 however depends on the packet payload. Some of the payloads are encrypted
242 with the session key and some are encrypted with other keys, for example
243 with channel message keys. The SILC Packet Header is always encrypted with
244 the session key. The MAC is computed from the SILC Packet Header and the
245 data area before encrypting the packet.
249 <h1>SILC Key Exchange Protocol</h1>
254 <h1>SILC Connection Authentcation Protocol</h1>
263 A channel is a named group of one or more clients which will all receive
264 messages addressed to that channel. The channel is created when first
265 client joins to it, and the channel ceases to exist when the last client
266 leaves it. When channel exists, any client can reference it using the
267 name of the channel. Channel is a place where group of people can engage
271 Channel names are unique in the SILC Network. There cannot be multiple
272 same channels in the network at the same time. However, channel has also
273 a Channel ID which is actually used to reference the channel in the
274 SILC Network. The maximum length for the channel name is 256 characters.
277 Channels can have operators that can administrate the channel and operate
278 all of its modes. There are two types of operators on the channel:
279 channel founder and channel operator.
282 The channel founder is the client which created the channel. Channel
283 founder is channel operator with some more privileges. Channel founder
284 can operate all of the channel's modes. Furthermore, channel founder
285 privileges cannot be removed by any other operator on channel and channel
286 founder cannot be removed from the channel by force. It is also possible
287 for the channel founder to regain its privileges at later time, even if
288 they have left the channel.
291 Channel operator is operator that can operate most of the channel's
292 modes and administrate the channel. However, it cannot operate all
293 modes which are strictly reserved for channel founder. Channel operator
294 is, however able to adminstrate the channel, set some modes on the
295 channel, remove a badly behaving client from the channel, and promote
296 other clients to become channel operator.
300 <h2>Channel Message Delivery</h2>
303 All clients that have joined the channel can send messages to the channel.
304 All channel messages are secured and authenticated by channel key. The
305 channel key is generated by the server when the channel is created,
306 a client joins the channel, or a client leaves the channel. The channel
307 key is also regenerated periodically. The reason for the regeneration
308 of channel key everytime someone joins or leaves the channel is that
309 it prevents new clients joining the channel, and old clients leaving the
310 channel, to encrypt or decrypt old or new messages. They can encrypt
311 and decrypt channel messages only when they have joined on the channel.
314 Channel keys are cell specific in the SILC Network. Each cell that
315 have clients joined on a particular channel have also own key for the
316 channel. That key is not shared by other cells in the network. Inside
317 the cell the channel key is known by the router and all servers that
318 have clients on the channel and all clients that have joined the channel.
321 <img src="silc_channel.JPG" alt="Channel Message Delivery" align="center" border"0">
324 The diagram above illustrates typical delivery of channel messages inside
325 a cell and between two cells. Both of the cells have their own channel
326 key. Both cells knows all clients joined on the channel. When message
327 is sent to the channel by an client, it is encrypted with the current
328 channel key in that cell. The servers and the router in the local cell
329 then routes the message to all local clients who have joined the channel.
330 If the channel has clients that belong to other cell in the network the
331 router will route the channel message to that cell. When channel
332 messages are send between routers they are first decrypted with the
333 current channel key, and then re-encrypted with the session key shared
334 between the two routers. The router who receives the channel message
335 then decrypts it with the session and re-encrypts it with the
336 current channel key in that cell. It then distributes the channel message
337 to all clients on the channel. The clients who have joined the channel
338 always knows the current channel key and can decrypt all channel messages
339 they receive. Note that normal servers in the SILC network never decrypt
340 the channel messages even though the have the key. There is no reason
341 for servers to decrypt the message. The router decrypts the message
342 only when sending it between two routers.
345 This method of channel message delivery is the the default way to send
346 channel messages in the SILC Network. However, this is not perfect
347 solution on all circumstances. If the clients joined on a particular
348 channel cannot trust, or do not want to trust the servers and routers
349 in the SILC Network they can consider the fact, that servers and routers
350 knows the channel key is actually a breach of security.
353 If the clients on the other hand can trust their servers and routers
354 in the SILC Network this is the recommended way of sending channel
355 messages. This method is the simplest method for end user since it
356 does not require any special settings before engaging the conversation
357 on the channel. The client merely joins the channel, receives the
358 channel key from the server and can start the conversation on the
362 <h2>Channel Message Delivery With Channel Private Key</h2>
365 If the clients cannot trust the servers and routers in the SILC Network
366 they should not use the default way of sending the channel messages.
367 Instead, they should use channel private keys to encrypt and decrypt
368 the channel messages. Channel private keys are keys that are known
369 only by the clients who have joined the channel. All servers and
370 routers do not know the key and cannot decrypt the messages. When
371 message is sent between two routers they are merely re-encrypted with
372 the session key but not decrypted since the router do not have the
376 The clients who have joined the channel must first agree on the channel
377 private key they are going to use. The key may generally be anything.
378 It may be a passphrase or a random string, or the key may negotiated
379 using some key negotiation protocol which provides exchanging the
380 key for multiple clients at the same time.
383 As the channel private key is actually entirely local setting in the
384 client, it is possible to set several channel private keys for one
385 channel. It is possible to have multiple channel private keys that
386 are not known by all channel members. When encrypting messages with
387 one channel private key only the clients who have that key can decrypt
388 the message. The other key could be shared for example by all clients
389 on the channel and thus all clients can decrypt messages encrypted with
390 that key. In this way it is actually possible to have private group
391 conversation inside the channel while having global conversation at the
396 <h1>Private Messages</h1>
398 Private messages are messages that are sent from one client to another
399 through the SILC Network. They are private because they are not sent to
400 anyone else except to the true receiver of the message. Private messages
401 can be used to engage private conversation with another client if channels
405 As all messages in SILC the private message are also encrypted and
406 authenticated. There are several ways to secure private messages. By
407 default private messages are encrypted using the session keys established
408 in the SKE protocol. It is also possible to negotiate a private message
409 key between the two clients and encrypt the messages with that key. It
410 is even possible to encrypt the messages with public key cryptosystem,
411 if desired. The next sections will describe all these private message
415 The SILC protocol provides these three methods of delivering private messages
416 because none of the methods alone can satisfy the security requirements
417 of all people. The end user should decide the acceptable level of risk,
418 the required level of security and other security and usability aspects when
419 deciding what way of sending private message suites for them.
423 <h2>Private Message Delivery With Session Keys</h2>
425 Sending private messages are by default secured with session keys established
426 in the SKE protocol. This means that the private message is always encrypted
427 with the session key of the next receiver of the message enroute to the
428 receiving client. This also means that the message is decrypted and
429 re-encrypted everytime it is sent further to the receiving client.
432 <img src="silc_priv1.JPG" alt="Basic Private Message Delivery" align="center" border"0">
435 As the above diagram shows the private messages sent by Client A to the
436 Client B travels through the SILC Network and is always decrypted and
437 re-encrypted with the session key of the next receiver. The Client B then
438 finally decrypts the private messages that is encrypted with the session
439 key shared between the Client B and the Server Y.
442 This way of securing private messages is not perfect and cannot be used
443 in all circumstances. If the clients having the conversation cannot trust
444 the servers and routers in the SILC Network they should not send private
445 messages that are secured in this manner. Messages secured in this manner
446 can be decrypted by the servers and routers that the clients may consider
450 If the clients on the other hand trust the servers and routers in their
451 SILC Network, or they do not care that servers can decrypt their messages,
452 sending private messages in this way is very simple from client's point
453 of view. For servers and routers this of course means that they need
454 to decrypt and re-encrypt each private message. Since this way of securing
455 private message cannot be used at all times the SILC protocol provides
456 other ways of securing private messages.
460 <h2>Private Message Delivery With Private Message Key</h2>
462 Private messages can be secured with private message key as well. This
463 key is known only by the sender of the message and the receiver of the
464 message. This way no one else except the sender and the receiver can encrypt
465 and decrypt the private messages. The message is encrypted by the sender
466 with the private message key and all the servers and routers pass the message
467 through enroute to the receiver. They cannot decrypt the message since
468 they do not have the key. When sending private messages in this way it
469 does not matter whether the clients trust or do not trust the servers and
470 routers in the SILC network.
473 <img src="silc_priv2.JPG" alt="Private Messages with Private Message Key" align="center" border"0">
476 As the above diagram shows the Client A encrypts the message with private
477 message key and sends the message to the SILC Network. All servers and
478 routers merely pass the message through since they cannot decrypt it.
479 The Client B then receives the message and decrypts it with the private
483 Sending private messages in this manner is always secure since the key is
484 shared only by the sender and the receiver. The problem of this method
485 is that the sender and the receiver must somehow agree about the key
486 they are going to use. The private message key can generally be anything.
487 It can be a passphrase that only the sender and the receiver knows. They
488 could have been agreed to use some word or phrase as the key sometime
489 earlier before they started the conversation. Or the key maybe from some
490 random string from a code book that only the sender and the receiver poses.
491 Or it can be a key that is negotiated using some key negotiation protocol.
494 The problem however is fundamental. How to agree to use some key when
495 you cannot reach the other person over secure channel? The SILC protocol
496 solves this problem by providing a possiblity to negotiate the key
497 between two clients using the SKE protocol. One or both of the clients
498 can set up the SKE server running in their host and ask the other client
499 to connect to it. As a result of the SKE protocol the clients have
500 now shared secret that they can use as private message key. The key
501 is known only by the two clients that exexcuted the SKE protocol. They
502 can then use that key to secure all subsequent private messages.
505 Using this method of private messages delivery is recommended if the
506 clients cannot trust the servers and routers in the SILC Network. The
507 drawback is the extra phase of setting the private message key before
508 starting the conversation. However, using the SKE protocol is the
509 recommended way to negotiate the private message key since it can be
510 automized and does not cause any extra tasks for end user.
514 <h2>Private Message Delivery With Public Key Encryption</h2>
516 If the clients cannot trust the servers and routers in the SILC Network
517 they can use the private message key. As described in the previous section
518 it is easy to set up with the SKE protocol. However, sometimes the two
519 clients do not want to use any passphrases as private message key or
520 negotiate the key with SKE, or perhaps they are unable to negotiate the
521 key because of some other external problem. The SILC protocol provides
522 yet another way of securing the private messages. This way does not
523 require setting or negotiating private message key. And, in this method
524 also it does not matter whether the clients trust or do not trust the
525 servers and routers in the SILC Network. The method is public key
526 encryption. The clients can encrypt the private messages with the
527 receiver's public key and send the message to the network. The servers
528 and routers cannot decrypt the messages since they do not have the
529 receiver's private key. The receiver on the other hand has the private
530 key which it uses to decrypt the message.
533 <img src="silc_priv3.JPG" alt="Private Messges with Public Key Cryptosystem" align="center" border"0">
536 As the above diagram shows the Client A has the Client B's public key.
537 It will encrypt the message with that key and sends the message to the
538 SILC Network. All servers and routers pass the message through since
539 they cannot decrypt it. The Client B then uses its private key to
540 decrypt the message. The Client B has also the Client A's public key
541 that it can use to encrypt messages that it will send to Client A.
544 Even this method of private message delivery is not perfect. The drawbacks
545 of this method is that the public key encryption process, as being
546 assymmetric cryptosystem, is much slower than encryption process with
547 symmetric cryptosystems. This is not probably problem with short messages
548 but may be inconvenient with long messages. The other drawback is that the
549 sender must first assure that the public key it is using in the encryption
550 is actually the receiver's public key. This is a absolute requirement
551 in this method. If the sender cannot authenticate the receiver's public
552 key this method of private message delivery should not be used. In SILC
553 protocol clients can fetch other clients public keys from servers.
554 However, the servers may not have authenticated the fetched public key so
555 that should not be fully trusted. Use of certificates can solve the
556 problem. The receiver's certificate could be authenticated by a third
557 party Certificate Authority (CA).
560 Usually verifying the public key is not a problem since the receiver
561 can provide the public key on some website, or verify the fingerprint of
562 the key over email, or phone call. The clients can also fetch the
563 public keys from SILC servers if they trust that the keys are authentic.
564 If both of the clients trust that the public keys are authentic using this
565 method of private message delivery is very simple and recommended.
573 <h1>Further Information</h1>
575 More detailed information about the SILC Protocol is available in the
576 SILC Protocol specification documents. There exists currently four
577 Internet Drafts that defines the protocol in great detail. The Internet
578 Drafts are available from the following sources but also from the
579 <a href="http://www.ietf.org">IETF website</a>.
582 - <a href="http://silcnet.org/docs/draft-riikonen-silc-spec-03.txt">
583 Secure Internet Live Conferencing (SILC), Protocol Specification</a>
586 - <a href="http://silcnet.org/docs/draft-riikonen-silc-pp-03.txt">
587 SILC Packet Protocol</a>
590 - <a href="http://silcnet.org/docs/draft-riikonen-silc-ke-auth-03.txt">
591 SILC Key Exchange and Authentication Protocols</a>
594 - <a href="http://silcnet.org/docs/draft-riikonen-silc-commands-01.txt">
601 <h1>Terms and Abbreviations</h1>
projects / crypto.git / blob