1 <!-- This file is processed with html2ps to generate PostiScript.
2 Do not edit the HTML syntax unless you know what you are doing. -->
5 <title>SILC Protocol White Paper</title>
6 <link rev=made href="mailto:priikone@silcnet.org">
7 <meta name="Author" content="Pekka Riikonen - SILC Project">
8 <meta name="Description"
9 content="SILC - Secure Internet Live Conferencing Protocol">
10 <meta name="Created" content="Version 1.0 / 03 Aug 2001">
12 <body bgcolor="#ffffff">
14 <font face="Helvetica">
16 <font size="6"><b>SILC Protocol White Paper</b></font><br>
17 <font size="2">Version 1.1 / 01 Jan 2002</font>
22 Chat protocols are very popular on the Internet. They have actually
23 been very popular since the very first chat protocols appeared on the net.
24 The Internet Relay Chat (IRC) was one of the first chat protocols, and quickly
25 gained the status of being the most popular chat on the net. Today, IRC
26 has several competitors from various other so called Instant Messaging (IM)
27 protocols, such as ICQ. However, all of these different chat protocols
28 have something in common; they are all insecure.
31 The security is important feature in applications and protocols in
32 contemporary network environment. The older chat protocols, however have
33 failed to meet the growing security requirements on the Internet.
34 It is not anymore enough to just provide services, like for example
35 chat services. Now, they need to be secure services.
38 The Secure Internet Live Conferencing (SILC) protocol is a new generation
39 chat protocol which provides full featured conferencing services, just
40 like any other contemporary chat protocol provides. In addition, it
41 provides security by encrypting and authenticating the messages in
42 the network. The security has been the primary goal of the SILC protocol
43 and the protocol has been designed from the day one security in mind.
44 All packets and messages travelling in the SILC Network are always
45 encrypted and authenticated. The network topology is also different
46 from for example IRC network. The SILC network topology attempts to be
47 more powerful and scalable than the IRC network. The basic purpose
48 of the SILC protocol is to provide secure conferencing services.
51 The SILC Protocol have been developed as Open Source project. The
52 protocol specifications are freely available and they have been submitted to
53 the IETF. The very first implementations of the protocol are also already
57 <h1>About This White Paper</h1>
59 The purpose of this white paper is to give short but deep enough introduction
60 to the SILC Protocol. The document describes the purpose of the protocol
61 and how the protocol works in practice. This document is intended for all
62 audience. This document should be easy to understand for non-technical
63 person and still be detailed enough for technically oriented person. See
64 the section <a href="#terms">Terms and Abbreviations</a> for terms used
69 (c) Copyright 2001 - 2002 Pekka Riikonen
70 (<a href="mailto:priikone at silcnet.org">priikone at silcnet.org</a>)
72 This document is free document; you can redistribute it and/or modify
73 it under the terms of the GNU General Public License as published by
74 the Free Software Foundation; either version 2 of the License, or
75 (at your option) any later version. This document is distributed in
76 the hope that it will be useful, but WITHOUT ANY WARRANTY; without even
77 the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
78 See the GNU General Public License for more details.
82 <h1>SILC Protocol</h1>
85 The Secure Internet Live Conferencing (SILC) protocol provides secure
86 conferencing services over insecure network channel. The SILC is IRC
87 like protocol, however it does not support IRC. Strong cryptographic
88 methods are used to protect SILC packets inside the SILC network. SILC
89 provides all the common conferencing services like channels, channel
90 messages, private messages, nicknames and various commands. Difference
91 to other chat protocol is in the design of the protocol. The SILC
92 protocol has been designed from the day one security in mind and it
93 shows in the protocol design.
96 Generally it is assumed that the SILC Network is trusted. This means
97 that clients can fully trust the servers and routers in the SILC Network.
98 In real life this is not always possible. In the Internet it is possible
99 that some server or router would get compromised by a malicious
100 cracker. However, if the SILC Network is closed network, for example
101 inside a orgranization the assumption generally is true. The SILC
102 protocol is secure even if the end users consider the network
103 untrusted, and provides several ways to still have secure conversation
107 The packets in the SILC network are always encrypted. It is not possible
108 to send unencrypted messages in SILC. This assures that end user cannot
109 even accidently send unencrypted messages while thinking that it is
110 encrypted. This is the problem of most other chat protocols that provide
111 so called plugin encryption. They are not secure by default but try
112 to provide security by applying external security protocol such as PGP
113 or SSL. In these cases the security is achieved usually by encrypting the
114 data while key management and other security issues may be left out, leaving
115 the implementation vulnerable to various security problems. The other
116 problem is also that the external protocols tend to leave the network
117 only partly secured; usually only two points in the network are secured
118 with for example SSL. While SSL does provide provable security it is not
119 enough to provide security for a chat network as a whole.
122 The network topology is also different to various other chat protocol,
123 like for example IRC. IRC has tree style network where SILC has so
124 called cellular network. A cell consists of a router, servers and clients.
125 The cell can also have backup routers in case the private router becomes
129 <object data="silc_network.jpg" type="application/postscript">
130 <img src="silc_network.png" alt="SILC Network" align="center" border"0">
134 The diagram above illustrates a portion of the SILC network. It shows
135 two cells that both has several servers, and backup routers and several
136 clients. Clients can connect to server and routers if they want to.
137 The following sections will describe the entities of the SILC Network
146 A client is a piece of software connecting to SILC server. The software
147 is usually run by the end user, a real person that is. The purpose of the
148 clients is to provide the end user an interface to the SILC services.
149 They are used to actually engage the conversations on the SILC Network,
150 and they can be used to execute various SILC commands.
153 The clients are distinquished from other clients by unique Client ID.
154 There cannot be multiple same Client IDs in the SILC Network at the same time.
155 The end user, however does not use Client IDs. The end users usually selects
156 a perferred nickname they want to use, and identifies themself with that
157 nickname to other users on the network. The nicknames are not unique in
158 the SILC Network. There can be multiple same nicknames at the same time
159 on the network. The maximum length for the nickname is 128 characters.
162 Most of the other chat protocols have unique nicknames. This is where SILC
163 differs from most of the other chat protocols. The purpose of this
164 feature is to make IRC style nickname wars obsolete, as no one owns their
165 nickname; there can always be somene else with the same nickname.
168 When client connects to the server the SILC Key Exchange (SKE) protocol and
169 SILC Connection Authentication protocol are executed. The result of the
170 SKE protocol is the session key that the client and server use to secure
171 their communication. All commands, for example, that the client sends
172 to the server are secured with the session key. The session key expires
173 periodically and the rekey process can be executed with or without the
174 Perfect Forward Secrecy (PFS). The connection authentication protocol is
175 used to authenticate the client to the server. The server may allow the
176 client to connect without authentication, or it may require a passphrase or
177 public key based authentication.
184 Servers forms the basis for the SILC Network, by providing a point to which
185 clients may connect. There are two kinds of servers in SILC; normal servers
186 and router servers. The next section describes the function of router
190 Normal servers connect to router server. Normal servers cannot directly
191 connect to other normal servers. Messages that are destined outside the
192 local server are always sent to the router for further routing.
193 The clients usually connect to the normal server, however, clients may
194 connect to router servers as well. The SILC Network diagram above
195 illustrates how normal servers connects to the router server.
198 The servers are distinquished by other servers in the network by unique
199 Server ID. There cannot be multiple same Server IDs in the SILC Network
200 at the same time. The servers keep track of local information. It knows
201 all locally connected clients and it knows all channels that its clients
202 have joined. However, it does not know any global information. It
203 usually does not keep track of global clients, however, it may cache
204 that information if it was queried. The reason for this is that the
205 server does not need to keep global information up to date and thus
206 makes the server faster (and in the end the entire network faster).
207 They can always query the information from the router.
210 When server connects to its router the SILC Key Exchange (SKE) protocol
211 and the SILC Connection Authentication protocol are executed, just like
212 when client connects to server. The SKE results in to the session key
213 that is used to secure the communication between the server and the
214 router. The connection authentication protocol is used to authenticate
215 the server to the router. The authentication is always based in either
216 passphrase or public key.
223 The router servers are servers that actually handles the message routing
224 in the network. They are, however also normal servers and they do accept
225 client connections. Each of the router in the network is called a cell.
226 A cell can have only one active router and it may have several servers
227 and several clients. The cell, however may have backup routers that can
228 take over the tasks of the primary router if it becomes unresponsive.
229 The switch to the backup router should be transparent and only local
230 connections to the primary router are lost. Other connections in the
231 cell are intact, and clients and servers merely experience some lag in
232 the network connection during the switch to the backup router.
235 The normal server knows only local information. Router server on the
236 other hand knows local information and global information. It considers
237 the cell as local and outside cells as global. It knows all the clients
238 connected to the network, all created channels, and all routers and servers
239 in the network. The server may query the global information if it is needed.
240 For example, when client sends WHOIS command, the server may query the
241 information from the router. If the router does not know all the details
242 that the WHOIS command requires it can query the information from a router
243 or a server which knows all the details. It may then cache that information.
246 The primary purpose of the router server is to route the messages to
247 local servers and local clients, and messages that are destined to outside
248 the cell are routed to the primary route or some other secondary
249 route if it is a faster route. The routers in the network forms a ring.
250 Each router has a primary route to other router in the network. Finally
251 the ring is closed by the last router using the first router in the
252 network as its primary route.
255 <object data="silc_routers.jpg" type="application/postscript">
256 <img src="silc_routers.png" alt="SILC Routers" align="center" border"0">
260 The diagram above illustrates how the routers forms a ring in the network.
261 A router may have several secondary routes which it may use when it
265 When routers connect to its primary router the SKE and the SILC Connection
266 Authentication protocols are executed just like when normal server connects
267 to its router. The session key is used to secure the communication between
268 the routers. All the secondary routes also have their own session keys.
272 <h1>SILC Packet Protocol</h1>
275 The basis of SILC protocol relies in the SILC packets and they are with
276 out a doubt the most important part of the protocol. The SILC Packet
277 protocol is a binary packet protocol. The protocol provides secure
278 binary packets and assures that the contents of the packets are secured
282 Packets are used in the SILC protocol all the time to send for example
283 channel messages, private messages, commands and other information. All
284 packets in SILC network are always encrypted and their integrity is
285 assured by computed Message Authentication Codes (MAC). The protocol
286 defines several packet types and packet payloads. Each packet type
287 usually has a specific packet payload that actually defines the contents
288 of the packet. Hence, the actual data in the packet is the packet payload
289 defined in the protocol.
292 <object data="silc_packet.jpg" type="application/postscript">
293 <img src="silc_packet.png" alt="Typical SILC Packet" align="center" border"0">
297 As the diagram above illustrates the SILC packet is constructed from the
298 SILC Packet Header that is included in all SILC packets, data area that
299 includes the packet payloads, and MAC area which assures the integrity of the
300 packet. Entire SILC packet is always encrypted, except for the MAC area
301 which is never encrypted. The encryption process and the key used,
302 however depends on the packet payload. Some of the payloads are encrypted
303 with the session key and some are encrypted with other keys, for example
304 with channel message keys. The SILC Packet Header is always encrypted with
305 the session key. The MAC is computed from the SILC Packet Header and the
306 data area before encrypting the packet.
310 <h1>SILC Key Exchange Protocol</h1>
313 SILC Key Exchange Protocol (SKE) is used to exchange shared secret
314 between connecting entities. The result of this protocol is a key material
315 used to secure the communication channel. This protocol is executed when,
316 for example client connects to server. It is also executed when server
317 connects to router. And, there is no reason why it could not be executed
318 between two clients too, if two clients would need to create secret key.
319 The purpose of the SKE protocol is to create session keys to be used
320 in current SILC session. The SKE is based on the Diffie-Hellman key
321 exchange algorithm, and is immune to man-in-the-middle attack.
324 This is the first protocol that is executed when creating connection to,
325 for example SILC server. All the other protocols are always executed
326 after this protocol. This way all the other protocols are secured since
327 the SKE creates the session key that is used to secure all subsequent
328 packets. The session keys created in the SKE are valid only for some
329 period of time (usually an hour) or at most until the session ends.
330 The rekey process can be executed with or without the Perfect Forward
334 The security properties that are used in the SILC session are also
335 negotiated during the SKE. The protocol has initiator and responder.
336 The initator is the one who starts the SKE negotiation and responder is
337 the one who receives the SKE negotiation. When the protocol is started
338 initiator sends a list of security properties that it supports. The
339 responder then selects the security properties it supports and sends
340 its reply to the initiator. The security properties includes ciphers,
341 hash functions, public key algorithms, HMAC functions and other
342 security properties. The responder can always choose the properties
346 After the security properties are selected the protocol continues
347 by performing the Diffie-Hellman key exchange algorithm. At the same
348 time the intiator and responder also sends their public keys or
349 certificates to each other. The responder also computes a signature
350 that the initiator will verify. It is also possible to perform a
351 mutual authentication where both of the parties computes a signature
352 which are verified by each other independently. If any of the phases
353 of the protocol are to fail the connection is closed immeadiately.
356 The public key or certificate that is received during the SKE protocol
357 must be verified. If it is not verified it would be possible to
358 execute a man-in-the-middle attack against the SKE protocol. If
359 certificates are used they can be verified by a third party Certification
360 Authority (CA). Verifying a public key requires either confirming
361 a fingerprint of the public key over phone or email, or the server
362 can for example publish the fingerprint (and the public key) on some
363 website. In real life systems accepting the public key without
364 verification, however is often desired. In many security protocols,
365 such as in SSH2, the public key is accepted without verification
366 in the first time when the connection is created. The public key is
367 then cached on local hard disk. When connecting next time to the
368 server the public key on local cache is verified against the public
369 key server sent. In real life this works most of the time. However,
370 if client (or server) cannot trust this, it must find some other way
371 to verify the received public key or certificate.
375 <h1>SILC Connection Authentication Protocol</h1>
378 Purpose of SILC Connection Authentication protocol is to authenticate the
379 connecting party with server or router. This protocol is executed when
380 for example client connects to server. It is also executed when server
381 connects to router. Its other purpose is to provide information for the
382 server about which type of connection it is. The type of the connection
383 defines whether it is client, server or router. If it is client then
384 the server will create a new Client ID for the client. If it is server
385 then it will except the server to send its Server ID. Server IDs are
386 created by the servers and routers itself.
389 Since the SILC Connection Authentication protocol is always executed after
390 the SKE protocol, session keys has been established already. This means
391 that all packets sent in the connection authentication protocol are encrypted
395 The authentication may be based either in passphrase or public key
396 encryption. It is also possible to not require authentication at all.
397 If the authentication is based to passphrase the passphrase is sent
398 to the server. As the packet sent by, for example client, is entirely
399 encrypted it is safe to send the passphrase inside the packet.
402 If the authentication is based to public key then, for example the client,
403 signs data with its private key and sends it to the server. The server
404 then verifies this signature by using the client's public key. The
405 packet is also encrypted in the case of public key authentication.
408 If the authentication is to fail the connection to the server or router
409 will be refused. If it is successful the connection is granted. After
410 this the client is ready to communicate in the SILC Network.
417 A channel is a named group of one or more clients which will all receive
418 messages addressed to that channel. The channel is created when first
419 client joins to it, and the channel ceases to exist when the last client
420 leaves it. When channel exists, any client can reference it using the
421 name of the channel. Channel is a place where group of people can engage
425 Channel names are unique in the SILC Network. There cannot be multiple
426 same channels in the network at the same time. However, channel has also
427 a Channel ID which is actually used to reference the channel in the
428 SILC Network. The maximum length for the channel name is 256 characters.
431 Channels can have operators that can administrate the channel and operate
432 all of its modes. There are two types of operators on the channel:
433 channel founder and channel operator.
436 The channel founder is the client which created the channel. Channel
437 founder is channel operator with some more privileges. Channel founder
438 can operate all of the channel's modes. Furthermore, channel founder
439 privileges cannot be removed by any other operator on channel and channel
440 founder cannot be removed from the channel by force. It is also possible
441 for the channel founder to regain its privileges at later time, even if
442 they have left the channel.
445 Channel operator is operator that can operate most of the channel's
446 modes and administrate the channel. However, it cannot operate all
447 modes which are strictly reserved for channel founder. Channel operator
448 is, however able to adminstrate the channel, set some modes on the
449 channel, remove a badly behaving client from the channel, and promote
450 other clients to become channel operator.
454 <h2>Channel Message Delivery</h2>
457 All clients that have joined the channel can send messages to the channel.
458 All channel messages are secured and authenticated by channel key. The
459 channel key is generated by the server when the channel is created,
460 a client joins the channel, or a client leaves the channel. The channel
461 key is also regenerated periodically. The reason for the regeneration
462 of channel key everytime someone joins or leaves the channel is that
463 it prevents new clients joining the channel, and old clients leaving the
464 channel, to encrypt or decrypt old or new messages. They can encrypt
465 and decrypt channel messages only when they have joined on the channel.
468 Channel keys are cell specific in the SILC Network. Each cell that
469 have clients joined on a particular channel have also own key for the
470 channel. That key is not shared by other cells in the network. Inside
471 the cell the channel key is known by the router and all servers that
472 have clients on the channel and all clients that have joined the channel.
475 <object data="silc_channel.jpg" type="application/postscript">
476 <img src="silc_channel.png" alt="Channel Message Delivery" align="center" border"0">
480 The diagram above illustrates typical delivery of channel messages inside
481 a cell and between two cells. Both of the cells have their own channel
482 key. Both cells knows all clients joined on the channel. When message
483 is sent to the channel by an client, it is encrypted with the current
484 channel key in that cell. The servers and the router in the local cell
485 then routes the message to all local clients who have joined the channel.
486 If the channel has clients that belong to other cell in the network the
487 router will route the channel message to that cell. When channel
488 messages are sent between routers they are first decrypted with the
489 current channel key, and then re-encrypted with the session key shared
490 between the two routers. The router who receives the channel message
491 then decrypts it with the session and re-encrypts it with the
492 current channel key in that cell. It then distributes the channel message
493 to all clients on the channel. The clients who have joined the channel
494 always knows the current channel key and can decrypt all channel messages
495 they receive. Note that normal servers in the SILC network never decrypt
496 the channel messages even though the have the key. There is no reason
497 for servers to decrypt the message. The router decrypts the message
498 only when sending it between two routers.
501 This method of channel message delivery is the default way to send
502 channel messages in the SILC Network. However, this is not perfect
503 solution on all circumstances. If the clients joined on a particular
504 channel cannot trust, or do not want to trust the servers and routers
505 in the SILC Network they can consider the fact, that servers and routers
506 knows the channel key is actually a breach of security.
509 If the clients on the other hand can trust their servers and routers
510 in the SILC Network this is the recommended way of sending channel
511 messages. This method is the simplest method for end user since it
512 does not require any special settings before engaging the conversation
513 on the channel. The client merely joins the channel, receives the
514 channel key from the server and can start the conversation on the
518 In addition of encrypting channel messages it also possible to digitally
519 sign all sent channel messages. The receiver could then verify the
520 signature of each of the message using the sender's public key.
524 <h2>Channel Message Delivery With Channel Private Key</h2>
527 If the clients cannot trust the servers and routers in the SILC Network
528 they should not use the default way of sending the channel messages.
529 Instead, they should use channel private keys to encrypt and decrypt
530 the channel messages. Channel private keys are keys that are known
531 only by the clients who have joined the channel. Servers and
532 routers do not know the key and cannot decrypt the messages. When
533 message is sent between two routers they are merely re-encrypted with
534 the session key but not decrypted since the router do not have the
538 The clients who have joined the channel must first agree on the channel
539 private key they are going to use. The key may generally be anything.
540 It may be a passphrase or a random string, or the key may negotiated
541 using some key exchange protocol which provides negotiating the
542 key for multiple clients at the same time.
545 As the channel private key is actually entirely local setting in the
546 client, it is possible to set several channel private keys for one
547 channel. It is possible to have multiple channel private keys that
548 are not known by all channel members. When encrypting messages with
549 one channel private key only the clients who have that key can decrypt
550 the message. The other key could be shared for example by all clients
551 on the channel and thus all clients can decrypt messages encrypted with
552 that key. In this way it is actually possible to have a private group
553 conversation inside the channel while having global conversation at the
558 <h1>Private Messages</h1>
560 Private messages are messages that are sent from one client to another
561 through the SILC Network. They are private because they are not sent to
562 anyone else except to the true receiver of the message. Private messages
563 can be used to engage private conversation with another client if channels
567 As all messages in SILC the private message are also encrypted and
568 authenticated. There are several ways to secure private messages. By
569 default private messages are encrypted using the session keys established
570 in the SKE protocol. It is also possible to negotiate a private message
571 key between the two clients and encrypt the messages with that key. It
572 is even possible to encrypt the messages with public key cryptosystem,
573 if desired. The next sections will describe all these private message
577 The SILC protocol provides these three methods of delivering private messages
578 because none of the methods alone can satisfy the security requirements
579 of all people. The end user should decide the acceptable level of risk,
580 the required level of security and other security and usability aspects when
581 deciding what way of sending private message suites for them.
584 In addition of encrypting private messages it also possible to digitally
585 sign all sent private messages. The receiver could then verify the
586 signature of each of the message using the sender's public key.
590 <h2>Private Message Delivery With Session Keys</h2>
592 Sending private messages are by default secured with session keys established
593 in the SKE protocol. This means that the private message is always encrypted
594 with the session key of the next receiver of the message enroute to the
595 receiving client. This also means that the message is decrypted and
596 re-encrypted everytime it is sent further to the receiving client.
599 <object data="silc_priv1.jpg" type="application/postscript">
600 <img src="silc_priv1.png" alt="Basic Private Message Delivery" align="center" border"0">
604 As the diagram above shows the private messages sent by Client A to the
605 Client B travels through the SILC Network and is always decrypted and
606 re-encrypted with the session key of the next receiver. The Client B then
607 finally decrypts the private messages that is encrypted with the session
608 key shared between the Client B and the Server Y.
611 This way of securing private messages is not perfect and cannot be used
612 in all circumstances. If the clients having the conversation cannot trust
613 the servers and routers in the SILC Network they should not send private
614 messages that are secured in this manner. Messages secured in this manner
615 can be decrypted by the servers and routers that the clients may consider
619 If the clients on the other hand trust the servers and routers in their
620 SILC Network, or they do not care that servers can decrypt their messages,
621 sending private messages in this way is very simple from client's point
622 of view. For servers and routers this of course means that they need
623 to decrypt and re-encrypt each private message. Since this way of securing
624 private message cannot be used at all times the SILC protocol provides
625 other ways of securing private messages.
629 <h2>Private Message Delivery With Private Message Key</h2>
631 Private messages can be secured with private message key as well. This
632 key is known only by the sender of the message and the receiver of the
633 message. This way no one else except the sender and the receiver can encrypt
634 and decrypt the private messages. The message is encrypted by the sender
635 with the private message key and all the servers and routers pass the message
636 through enroute to the receiver. They cannot decrypt the message since
637 they do not have the key. When sending private messages in this way it
638 does not matter whether the clients trust or do not trust the servers and
639 routers in the SILC network.
642 <object data="silc_priv2.jpg" type="application/postscript">
643 <img src="silc_priv2.png" alt="Private Messages with Private Message Key" align="center" border"0">
647 As the diagram above shows the Client A encrypts the message with private
648 message key and sends the message to the SILC Network. All servers and
649 routers merely pass the message through since they cannot decrypt it.
650 The Client B then receives the message and decrypts it with the private
654 Sending private messages in this manner is always secure since the key is
655 shared only by the sender and the receiver. The problem of this method
656 is that the sender and the receiver must somehow agree about the key
657 they are going to use. The private message key can generally be anything.
658 It can be a passphrase that only the sender and the receiver knows. They
659 could have been agreed to use some word or phrase as the key sometime
660 earlier before they started the conversation. Or the key maybe from some
661 random string from a code book that only the sender and the receiver poses.
662 Or it can be a key that is negotiated using some key exchange protocol.
665 The problem however is fundamental. How to agree to use some key when
666 you cannot reach the other person over secure channel? The SILC protocol
667 solves this problem by providing a possiblity to negotiate the key
668 between two clients using the SKE protocol. One or both of the clients
669 can set up the SKE server running in their host and ask the other client
670 to connect to it. In this case the SKE is executed outside the SILC
671 Network. As a result of the SKE protocol the clients have now shared
672 secret that they can use as private message key. The key is known only
673 by the two clients that executed the SKE protocol. They can then use
674 that key to secure all subsequent private messages.
677 Using this method of private messages delivery is recommended if the
678 clients cannot trust the servers and routers in the SILC Network. The
679 drawback is the extra phase of setting the private message key before
680 starting the conversation. However, using the SKE protocol is the
681 recommended way to negotiate the private message key since it can be
682 automatized and does not cause any extra tasks for end user.
686 <h2>Private Message Delivery With Public Key Encryption</h2>
688 If the clients cannot trust the servers and routers in the SILC Network
689 they can use the private message key. As described in the previous section
690 it is easy to set up with the SKE protocol. However, sometimes the two
691 clients do not want to use any passphrases as private message key or
692 negotiate the key with SKE, or perhaps they are unable to negotiate the
693 key because of some other external problem. The SILC protocol provides
694 yet another way of securing the private messages. This way does not
695 require setting or negotiating private message key. And, in this method
696 also it does not matter whether the clients trust or do not trust the
697 servers and routers in the SILC Network. The method is public key
698 encryption. The clients can encrypt the private messages with the
699 receiver's public key and send the message to the network. The servers
700 and routers cannot decrypt the messages since they do not have the
701 receiver's private key. The receiver on the other hand has the private
702 key which it uses to decrypt the message.
705 <object data="silc_priv3.jpg" type="application/postscript">
706 <img src="silc_priv3.png" alt="Private Messges with Public Key Cryptosystem" align="center" border"0">
710 As the diagram above shows the Client A has the Client B's public key.
711 It will encrypt the message with that key and sends the message to the
712 SILC Network. All servers and routers pass the message through since
713 they cannot decrypt it. The Client B then uses its private key to
714 decrypt the message. The Client B has also the Client A's public key
715 that it can use to encrypt messages that it will send to Client A.
718 Even this method of private message delivery is not perfect. The drawbacks
719 of this method is that the public key encryption process, as being
720 asymmetric cryptosystem, is much slower than encryption process with
721 symmetric cryptosystems. This is not probably problem with short messages
722 but may be inconvenient with long messages. The other drawback is that the
723 sender must first assure that the public key it is using in the encryption
724 is actually the receiver's public key. This is a absolute requirement
725 in this method. If the sender cannot authenticate the receiver's public
726 key this method of private message delivery should not be used. In SILC
727 protocol clients can fetch other clients public keys from servers.
728 However, the servers may not have authenticated the fetched public key so
729 that should not be fully trusted. Use of certificates can solve the
730 problem. The receiver's certificate could be authenticated by a third
731 party Certification Authority (CA).
734 Usually verifying the public key is not a problem since the receiver
735 can provide the public key on some website, or verify the fingerprint of
736 the key over email, or phone call. The clients can also fetch the
737 public keys from SILC servers if they trust that the keys are authentic.
738 If both of the clients trust that the public keys are authentic using this
739 method of private message delivery is very simple and recommended.
743 <h1>Secure File Transfers</h1>
749 The Secure Internet Live Conferencing (SILC) protocol is a new generation
750 chat protocol that provides all the common conferencing services with
751 strong support for security. It has wide range of security properties
752 that should meet the highest levels of security requirements, while not
753 forgetting easy of use. The network topology offers new architectural
754 solution with better scalability over traditional chat protocols.
758 <h1>Further Information</h1>
760 More detailed information about the SILC protocol is available in the
761 SILC protocol specification documents. There exists currently four
762 Internet Drafts that defines the protocol in great detail. The Internet
763 Drafts are available from the following sources but also from the
764 <a href="http://www.ietf.org">IETF website</a>.
767 - <a href="http://silcnet.org/docs/draft-riikonen-silc-spec-03.txt">
768 Secure Internet Live Conferencing (SILC), Protocol Specification</a>
771 - <a href="http://silcnet.org/docs/draft-riikonen-silc-pp-03.txt">
772 SILC Packet Protocol</a>
775 - <a href="http://silcnet.org/docs/draft-riikonen-silc-ke-auth-03.txt">
776 SILC Key Exchange and Authentication Protocols</a>
779 - <a href="http://silcnet.org/docs/draft-riikonen-silc-commands-01.txt">
783 For comprehensive introduction to cryptography refer to the
784 <a href="http://www.ssh.com/tech/crypto/">Cryptography A-2-Z document</a>.
788 <h1>Terms and Abbreviations</h1>
791 - Asymmetric cryptosystem
793 Asymmetric cryptosystem provides public encryption. It has two keys,
794 one public key and one private key (also called as secret key). The public
795 key is publicly available allowing anyone to encrypt messages with the
796 public key. Only the posessor of the private key can decrypt those messages.
797 Difference to symmetric cryptosystem is that symmetric cryptosystem use only
798 one key, and the key is usually used to both encryption and decryption. The
799 asymmetric cryptosystem is also called as public key encryption, public key
800 cryptosystem or public key algorithm. SILC supports RSA and DSS asymmetric
806 The verification of the identity of a person, host or process in order
807 to gain access to a service or prove identity. In data communications
808 it also means verifying the origin of a message.
813 Certificate is a digital document which can be used to verify the
814 identity of a person or host. In SILC, certificates can be used to prove
815 identity of clients, servers and routers. Basically certificate is a public
816 key with subject name. SILC supports X.509, OpenPGP and SPKI certificates.
817 Supported public keys are SILC style public key and SSH2 style public
821 - Certification Authority (CA)
823 A third party entity that can verify identity of a person or host. CA
824 is usually external company that provides certificates and their
825 verification services.
828 - Diffie-Hellman key exchange
830 First public key algorithm ever invented. It is used to generate a secret
831 key between two or more parties. It gets its security from the difficulty
832 of calculating discrete logarithms.
837 A mechanism (usually mathematical) to transfer plaintext (or cleartext)
838 to ciphertext to provide confidentiality. A process to transfer
839 the ciphertext back to plaintext is called decryption.
844 The verification of data to detect any modifications. If data is
845 modified enroute from the sender to the receiver, the modification will
851 Hash Message Authentication Code. Also called as keyed hash function.
852 It is a secret key authentication algorithm which proves that the message
853 is not modified and that the HMAC was computed by the sender of the
859 Key management is a set of processes and mechanisms which support key
860 exchange and maintainance of current keying relationships between parties,
861 including replacing older keys with new keys as necessary, by executing
865 - Man-in-the-middle attack
867 An attack against two connecting entities where the attacker executes
868 key exchange protocol with both of the parties indepently without
869 their knowledge. Both of the connecting entities will end up having secret
870 key with the attacker, and the attacker can encrypt and decrypt all the
871 messages that goes between the two entities.
874 - Message Authentication Code (MAC)
876 MAC provides message integrity by computing the MAC using a secret
877 key authentication algorithm (HMAC).
880 - Perfect Forward Secrecy (PFS)
882 A property of rekey (or key regeneration) which defines whether the
883 new key is derived from the old key. If Perfect Forward Secrecy is
884 selected the new key is never dependent of the old key which means
885 that if the old key would get compromised at later time it will not
886 compromise the new key. In SILC setting PFS in the SKE protocol means
887 executing the SKE protocol again. If PFS is not selected the new key
888 is always derived from the old key.
893 A key regeneration process where the old key has expired or is not
894 secure anymore to use. In this case rekey is performed and new key
898 - Symmetric cryptosystem
900 Symmetric cryptosystem is one key cryptosystem where one key is used
901 usually to both encryption and decryption process. The symmetric
902 cryptosystems are usually significantly faster than asymmetric cryptosystems.
903 DES, AES, Twofish and Blowfish are examples of symmetric cryptosystems.
904 SILC supports all the common symmetric cryptosystems including AES.
905 SILC does not support DES as it is insecure and 3DES as it is too slow.
projects / silc.git / blob