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.2 / 22 October 2003">
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.2 / 22 October 2003</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 protocol is currently stabilizing and has reached a version
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 - 2003 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 Secure Internet Live Conferencing, or SILC in short, is a modern
86 conferencing protocol which provides rich conferencing features with
87 high security. One of the main design principles of the protocol was
88 security. Many of the SILC features are found in traditional chat
89 protocols such as IRC but many of the SILC features can also be found
90 in Instant Message (IM) style protocols.
93 SILC combines features from both of these chat protocol styles, and
94 can be implemented as either IRC-like system or IM-like system. In
95 fact, SILC removes the need to make such distinction between these
96 two protocol styles. Some of the more advanced and security features
97 of the protocol are new to all conferencing protocols. SILC also
98 supports multimedia messages and can also be implemented as a
99 video and audio conferencing system. The protocol is also compact
100 and robust and suites well for mobile environments where the low
101 bandwidth sets special requirements for protocols. All packet sizes
102 in SILC can be even further reduced by utlizing compression.
105 The packets and messages in the SILC network are always encrypted and
106 authenticated. It is not possible to send unencrypted messages in SILC
107 at all. This assures that end user cannot even accidently send unencrypted
108 messages while thinking that it is encrypted. This is one of the problems
109 of most of the other chat protocols that provide so called plugin encryption.
110 They are not secure by default but try to provide security by applying
111 external security protocol such as PGP or SSL over the insecure
112 protocol. In these cases the security is achieved usually by encrypting the
113 data while key management, message authentication and other security issues
114 may be left out, leaving the implementation vulnerable to various security
115 problems. The other problem is also that the external protocols tend to
116 leave the network only partly secured; usually only two points in the
117 network are secured with for example SSL. While SSL does provide provable
118 security it is not enough to provide security for a chat network as a whole.
121 SILC is secure in environment of mutual distrust between entities
122 in the network. It is possible to encrypt messages end to end, so that only
123 the sender and the receiver is able to encrypt and decrypt messages. It
124 is also possible to send messages to group of users, so that only the
125 specified group of users is able to encrypt and decrypt messages. Many
126 times the protocol use keys that are generated by the servers, so that
127 if other external key exchange methods fail the network still remains
128 encrypted. However, it is always possible to negotiate and use locally
129 generated keys to secure messages, so that the servers do not know the
133 Like so many other contemporary chat protocols, SILC too provides
134 file transfer. It is possible to transfer files securely between users
135 in the SILC Network. The actual file transfer stream is always sent
136 outside the network peer to peer. Before the file transfer is started
137 a key exchange protocol is executed to negotiate file transfer session
141 The SILC protocol also supports so called detaching, a novel idea where
142 it is possible to detach from the server without actually quitting the
143 network. It is then later possible to resume the connection back to some
144 server in the network, and be like you were never gone.
147 The SILC protocol also allows distribution and exchange of public keys
148 and certificates through the SILC network. It is also possible to fetch
149 detailed user information from other users through the SILC network. It
150 is possible to fetch for example users's business card, pictures,
151 certificates, etc. SILC protocol also supports secure file transfer to
152 allow document and file exchange securely between users.
155 SILC protocol also supports services, which are extensions to the core
156 protocol. They can be used to augment the features of the protocol or
157 to add entirely new features without breaking backwards compatibility.
158 Services can be negotiated online and authenticated with passphrases or
159 with digital signatures.
162 The network topology is also different from traditional conferencing and
163 chat protocols. The SILC network forms so called hybrid ring-mesh network
164 at the router level, and star network at the server level. This sort of
165 network topology allows better scalability and faster delivery of packets
166 than traditional spanning tree style network. The router servers and normal
167 servers also has the distinction that only router's know global information
168 and keep the global network state up to date, and normal servers keep only
169 local information up to date. This significantly increases the scalability
170 of the network. The network also supports backup routers which can be
171 used to protect the network against netsplits.
174 <object data="silc_network.jpg" type="application/postscript">
175 <a href="silc_network.png">
176 <img src="s_silc_network.png" alt="SILC Network" align="center"
181 The diagram above illustrates a portion of the SILC network. It shows
182 two cells that both have several servers, and backup routers and several
183 clients. Clients can connect to server and routers if they want to.
184 The following sections will describe the entities of the SILC Network
193 A client is a piece of software connecting to SILC server. The software
194 is usually run by the end user, a real person that is. The purpose of the
195 clients is to provide the end user an interface to the SILC services.
196 They are used to actually engage the conversations on the SILC Network,
197 and they can be used to execute various SILC commands.
200 The clients are distinquished from other clients by unique Client ID.
201 There cannot be multiple same Client IDs in the SILC Network at the same time.
202 The end user, however does not use Client IDs. The end users usually selects
203 a preferred nickname they want to use, and identifies themself with that
204 nickname to other users on the network. The nicknames are not unique in
205 the SILC Network. There can be multiple same nicknames at the same time
206 on the network. The maximum length for the nickname is 128 bytes.
209 Most of the other chat protocols have unique nicknames. This is where SILC
210 differs from most of the other chat protocols. The purpose of this
211 feature is to make IRC style nickname wars obsolete, as no one owns their
212 nickname; there can always be somene else with the same nickname. This
213 feature also makes nickname registering services obsolete.
216 When client connects to the server the SILC Key Exchange (SKE) protocol and
217 SILC Connection Authentication protocol are executed. The result of the
218 SKE protocol is the session key that the client and server use to secure
219 their communication. All commands, for example, that the client sends
220 to the server are secured with the session key. The session key expires
221 periodically and the rekey process can be executed with or without the
222 Perfect Forward Secrecy (PFS). The connection authentication protocol is
223 used to authenticate the client to the server. The server may allow the
224 client to connect without authentication, or it may require a passphrase or
225 public key based (or certificates) authentication.
232 Servers forms the basis for the SILC Network, by providing a point to which
233 clients may connect. There are two kinds of servers in SILC; normal servers
234 and router servers. The next section describes the function of router
238 Normal servers connect to router server. Normal servers cannot directly
239 connect to other normal servers. Messages that are destined outside the
240 local server are always sent to the router for further routing.
241 The clients usually connect to the normal server, however, clients may
242 connect to router servers as well. The SILC Network diagram above
243 illustrates how normal servers connects to the router server.
246 The servers are distinquished by other servers in the network by unique
247 Server ID. There cannot be multiple same Server IDs in the SILC Network
248 at the same time. The servers keep track of local information. It knows
249 all locally connected clients and it knows all channels that its clients
250 have joined. However, it does not know any global information. It
251 usually does not keep track of global clients, however, it may cache
252 that information if it was queried. The reason for this is that the
253 server does not need to keep global information up to date and thus
254 makes the server faster (and in the end the entire network faster).
255 They can always query the information from the router.
258 When server connects to its router the SILC Key Exchange (SKE) protocol
259 and the SILC Connection Authentication protocol are executed, just like
260 when client connects to server. The SKE results in to the session key
261 that is used to secure the communication between the server and the
262 router. The connection authentication protocol is used to authenticate
263 the server to the router. The authentication is always based in either
264 passphrase or public key (or certificates).
271 The router servers are servers that actually handles the message routing
272 in the network. They are, however also normal servers and they do accept
273 client connections. Each of the router in the network is called a cell.
274 A cell can have only one active router and it may have several servers
275 and several clients. The cell, however may have backup routers that can
276 take over the tasks of the primary router if it becomes unresponsive.
277 The switch to the backup router should be transparent and only local
278 connections to the primary router are lost. Other connections in the
279 cell are intact, and clients and servers merely experience some lag in
280 the network connection during the switch to the backup router.
283 The normal server knows only local information. Router server on the
284 other hand knows local information and global information. It considers
285 the cell as local and outside cells as global. It knows all the clients
286 connected to the network, all created channels, and all routers and servers
287 in the network. The server may query the global information if it is needed.
288 For example, when client sends WHOIS command, the server may query the
289 information from the router. If the router does not know all the details
290 that the WHOIS command requires it can query the information from a router
291 or a server which knows all the details. It may then cache that information.
294 The primary purpose of the router server is to route the messages to
295 local servers and local clients, and messages that are destined to outside
296 the cell are routed to the primary route or some other secondary
297 route if it is a faster route. The routers in the network forms a ring.
298 Each router has a primary route to other router in the network. Finally
299 the ring is closed by the last router using the first router in the
300 network as its primary route.
303 <object data="silc_routers.jpg" type="application/postscript">
304 <a href="silc_routers.png">
305 <img src="s_silc_routers.png" alt="SILC Routers" align="center"
310 The diagram above illustrates how the routers forms a ring in the network.
311 A router may have several secondary routes which it may use when it
315 When routers connect to its primary router the SKE and the SILC Connection
316 Authentication protocols are executed just like when normal server connects
317 to its router. The session key is used to secure the communication between
318 the routers. All the secondary routes also have their own session keys.
322 <h1>SILC Packet Protocol</h1>
325 The basis of SILC protocol relies in the SILC packets and they are with
326 out a doubt the most important part of the protocol. The SILC Packet
327 protocol is a secure binary packet protocol. The protocol provides secure
328 binary packets and assures that the contents of the packets are secured
332 Packets are used in the SILC protocol all the time to send for example
333 channel messages, private messages, commands and other information. All
334 packets in SILC network are always encrypted and their integrity is
335 assured by computed Message Authentication Codes (MAC). The protocol
336 defines several packet types and packet payloads. Each packet type
337 usually has a specific packet payload that actually defines the contents
338 of the packet. Hence, the actual data in the packet is the packet payload
339 defined in the protocol.
342 <object data="silc_packet.jpg" type="application/postscript">
343 <a href="silc_packet_png">
344 <img src="s_silc_packet.png" alt="Typical SILC Packet" align="center"
349 As the diagram above illustrates the SILC packet is constructed from the
350 SILC Packet Header that is included in all SILC packets, data area that
351 includes the packet payloads, and MAC area which assures the integrity of the
352 packet. Entire SILC packet is always encrypted, except for the MAC area
353 which is never encrypted. The encryption process and the key used,
354 however depends on the packet payload. Some of the payloads are encrypted
355 with the session key and some are encrypted with other keys, for example
356 with channel message keys. The SILC Packet Header is always encrypted with
357 the session key. The MAC is computed from the SILC Packet Header and the
358 data area after encryption. This is so called Encrypt-Then-MAC order.
362 <h1>SILC Key Exchange Protocol</h1>
365 SILC Key Exchange Protocol (SKE) is used to exchange shared secret
366 between connecting entities. The result of this protocol is a key material
367 used to secure the communication channel. This protocol is executed when,
368 for example client connects to server. It is also executed when server
369 connects to router. And, there is no reason why it could not be executed
370 between two clients too, if two clients would need to create secret key.
371 The purpose of the SKE protocol is to create session keys to be used
372 in current SILC session. The SKE is based on the Diffie-Hellman key
373 exchange algorithm, and is immune to for example man-in-the-middle attacks
374 by using digital signatures.
377 This is the first protocol that is executed when creating connection to,
378 for example SILC server. All the other protocols are always executed
379 after this protocol. This way all the other protocols are secured since
380 the SKE creates the session key that is used to secure all subsequent
381 packets. The session keys created in the SKE are valid only for some
382 period of time (usually an hour) or at most until the session ends.
383 The rekey process can be executed with or without the Perfect Forward
387 The security properties that are used in the SILC session are also
388 negotiated during the SKE. The protocol has initiator and responder.
389 The initator is the one who starts the SKE negotiation and responder is
390 the one who receives the SKE negotiation. When the protocol is started
391 initiator sends a list of security properties that it supports. The
392 responder then selects the security properties it supports and sends
393 its reply to the initiator. The security properties includes ciphers,
394 hash functions, public key algorithms, HMAC functions and other
395 security properties. The responder can always choose the properties
399 After the security properties are selected the protocol continues
400 by performing the Diffie-Hellman key exchange algorithm. At the same
401 time the intiator and responder also sends their public keys or
402 certificates to each other. The initiator and responder also computes a
403 signature that the other party will verify. By default the protocol is
404 executed in so called mutual authentication mode, where both of the
405 parties computes a signature which are verified by each other
406 independently. This way both of the parties will have prove the
407 posession of the private key to the public key they are providing
408 in the protocol. If any of the phases of the protocol are to fail the
409 connection is closed immeadiately.
412 The public key or certificate that is received during the SKE protocol
413 must be verified. If it is not verified it would be possible to
414 execute a man-in-the-middle attack against the SKE protocol. If
415 certificates are used they can be verified by a third party Certification
416 Authority (CA). Verifying a public key requires either confirming
417 a fingerprint of the public key over phone or email, or the server
418 can for example publish the fingerprint (and the public key) on some
419 website. In real life systems accepting the public key without
420 verification, however is often desired. In many security protocols,
421 such as in SSH2, the public key is accepted without verification
422 in the first time when the connection is created. The public key is
423 then cached on local hard disk. When connecting next time to the
424 server the public key on local cache is verified against the public
425 key server sent. In real life this works most of the time. However,
426 if client (or server) cannot trust this, it must find some other way
427 to verify the received public key or certificate.
431 <h1>SILC Connection Authentication Protocol</h1>
434 Purpose of SILC Connection Authentication protocol is to authenticate the
435 connecting party with server or router. This protocol is executed when
436 for example client connects to server. It is also executed when server
437 connects to router. Its other purpose is to provide information for the
438 server about which type of connection it is. The type of the connection
439 defines whether it is client, server or router. If it is client then
440 the server will create a new Client ID for the client. If it is server
441 then it will except the server to send its Server ID. Server IDs are
442 created by the servers and routers itself.
445 Since the SILC Connection Authentication protocol is always executed after
446 the SKE protocol, session keys has been established already. This means
447 that all packets sent in the connection authentication protocol are encrypted
451 The authentication may be based either in passphrase or public key
452 encryption. It is also possible to not require authentication at all.
453 If the authentication is based to passphrase the passphrase is sent
454 to the server. As the packet sent by, for example client, is entirely
455 encrypted it is safe to send the passphrase inside the packet.
458 If the authentication is based to public key then, for example the client,
459 signs data with its private key and sends it to the server. The server
460 then verifies this signature by using the client's public key. The
461 packet is also encrypted in the case of public key authentication.
464 If the authentication is to fail the connection to the server or router
465 will be refused. If it is successful the connection is granted. After
466 this the client is ready to communicate in the SILC Network.
473 A channel is a named group of one or more clients which will all receive
474 messages addressed to that channel. The channel is created when first
475 client joins to it, and the channel ceases to exist when the last client
476 leaves it. When channel exists, any client can reference it using the
477 name of the channel. Channel is a place where group of people can engage
481 Channel names are unique in the SILC Network. There cannot be multiple
482 same channels in the network at the same time. However, channel has also
483 a Channel ID which is actually used to reference the channel in the
484 SILC Network. The maximum length for the channel name is 256 characters.
487 Channels can have operators that can administrate the channel and operate
488 all of its modes. There are two types of operators on the channel:
489 channel founder and channel operator.
492 The channel founder is the client which created the channel. Channel
493 founder is channel operator with some more privileges. Channel founder
494 can operate all of the channel's modes. Furthermore, channel founder
495 privileges cannot be removed by any other operator on channel and channel
496 founder cannot be removed from the channel by force. It is also possible
497 for the channel founder to regain its privileges at later time, even if
498 they have left the channel.
501 Channel operator is operator that can operate most of the channel's
502 modes and administrate the channel. However, it cannot operate all
503 modes which are strictly reserved for channel founder. Channel operator
504 is, however able to adminstrate the channel, set some modes on the
505 channel, remove a badly behaving client from the channel, and promote
506 other clients to become channel operator.
510 <h2>Channel Message Delivery</h2>
513 All clients that have joined the channel can send messages to the channel.
514 All channel messages are secured and authenticated by channel key. The
515 channel key is generated by the server when the channel is created,
516 a client joins the channel, or a client leaves the channel. The channel
517 key is also regenerated periodically. The reason for the regeneration
518 of channel key everytime someone joins or leaves the channel is that
519 it prevents new clients joining the channel, and old clients leaving the
520 channel, to encrypt or decrypt old or new messages. They can encrypt
521 and decrypt channel messages only when they have joined on the channel.
524 Channel keys are cell specific in the SILC Network. Each cell that
525 have clients joined on a particular channel have also own key for the
526 channel. That key is not shared by other cells in the network. Inside
527 the cell the channel key is known by the router and all servers that
528 have clients on the channel and all clients that have joined the channel.
531 <object data="silc_channel.jpg" type="application/postscript">
532 <a href="silc_channel.png">
533 <img src="s_silc_channel.png" alt="Channel Message Delivery"
534 align="center" border="0"></a>
538 The diagram above illustrates typical delivery of channel messages inside
539 a cell and between two cells. Both of the cells have their own channel
540 key. Both cells knows all clients joined on the channel. When message
541 is sent to the channel by an client, it is encrypted with the current
542 channel key in that cell. The servers and the router in the local cell
543 then routes the message to all local clients who have joined the channel.
544 If the channel has clients that belong to other cell in the network the
545 router will route the channel message to that cell. When channel
546 messages are sent between routers they are first decrypted with the
547 current channel key, and then re-encrypted with the session key shared
548 between the two routers. The router who receives the channel message
549 then decrypts it with the session and re-encrypts it with the
550 current channel key in that cell. It then distributes the channel message
551 to all clients on the channel. The clients who have joined the channel
552 always knows the current channel key and can decrypt all channel messages
553 they receive. Note that normal servers in the SILC network never decrypt
554 the channel messages even though the have the key. There is no reason
555 for servers to decrypt the message. The router decrypts the message
556 only when sending it between two routers.
559 This method of channel message delivery is the default way to send
560 channel messages in the SILC Network. However, this is not perfect
561 solution on all circumstances. If the clients joined on a particular
562 channel cannot trust, or do not want to trust the servers and routers
563 in the SILC Network they can consider the fact, that servers and routers
564 knows the channel key is actually a breach of security.
567 If the clients on the other hand can trust their servers and routers
568 in the SILC Network this is the recommended way of sending channel
569 messages. This method is the simplest method for end user since it
570 does not require any special settings before engaging the conversation
571 on the channel. The client merely joins the channel, receives the
572 channel key from the server and can start the conversation on the
576 In addition of encrypting channel messages it also possible to digitally
577 sign all sent channel messages. The receiver could then verify the
578 signature of each of the message using the sender's public key.
582 <h2>Channel Message Delivery With Channel Private Key</h2>
585 If the clients cannot trust the servers and routers in the SILC Network
586 they should not use the default way of sending the channel messages.
587 Instead, they should use channel private keys to encrypt and decrypt
588 the channel messages. Channel private keys are keys that are known
589 only by the clients who have joined the channel. Servers and
590 routers do not know the key and cannot decrypt the messages. When
591 message is sent between two routers they are merely re-encrypted with
592 the session key but not decrypted since the router do not have the
596 The clients who have joined the channel must first agree on the channel
597 private key they are going to use. The key may generally be anything.
598 It may be a passphrase or a random string, or the key may negotiated
599 using some key exchange protocol which provides negotiating the
600 key for multiple clients at the same time.
603 As the channel private key is actually entirely local setting in the
604 client, it is possible to set several channel private keys for one
605 channel. It is possible to have multiple channel private keys that
606 are not known by all channel members. When encrypting messages with
607 one channel private key only the clients who have that key can decrypt
608 the message. The other key could be shared for example by all clients
609 on the channel and thus all clients can decrypt messages encrypted with
610 that key. In this way it is actually possible to have a private group
611 conversation inside the channel while having global conversation at the
616 <h1>Private Messages</h1>
618 Private messages are messages that are sent from one client to another
619 through the SILC Network. They are private because they are not sent to
620 anyone else except to the true receiver of the message. Private messages
621 can be used to engage private conversation with another client if channels
625 As all messages in SILC the private message are also encrypted and
626 authenticated. There are several ways to secure private messages. By
627 default private messages are encrypted using the session keys established
628 in the SKE protocol. It is also possible to negotiate a private message
629 key between the two clients and encrypt the messages with that key. It
630 is even possible to encrypt the messages with public key cryptosystem,
631 if desired. The next sections will describe all these private message
635 The SILC protocol provides these three methods of delivering private messages
636 because none of the methods alone can satisfy the security requirements
637 of all people. The end user should decide the acceptable level of risk,
638 the required level of security and other security and usability aspects when
639 deciding what way of sending private message suites for them.
642 In addition of encrypting private messages it also possible to digitally
643 sign all sent private messages. The receiver could then verify the
644 signature of each of the message using the sender's public key.
648 <h2>Private Message Delivery With Session Keys</h2>
650 Sending private messages are by default secured with session keys established
651 in the SKE protocol. This means that the private message is always encrypted
652 with the session key of the next receiver of the message enroute to the
653 receiving client. This also means that the message is decrypted and
654 re-encrypted everytime it is sent further to the receiving client.
657 <object data="silc_priv1.jpg" type="application/postscript">
658 <a href="silc_priv1.png">
659 <img src="s_silc_priv1.png" alt="Basic Private Message Delivery"
660 align="center" border="0"></a>
664 As the diagram above shows the private messages sent by Client A to the
665 Client B travels through the SILC Network and is always decrypted and
666 re-encrypted with the session key of the next receiver. The Client B then
667 finally decrypts the private messages that is encrypted with the session
668 key shared between the Client B and the Server Y.
671 This way of securing private messages is not perfect and cannot be used
672 in all circumstances. If the clients having the conversation cannot trust
673 the servers and routers in the SILC Network they should not send private
674 messages that are secured in this manner. Messages secured in this manner
675 can be decrypted by the servers and routers that the clients may consider
679 If the clients on the other hand trust the servers and routers in their
680 SILC Network, or they do not care that servers can decrypt their messages,
681 sending private messages in this way is very simple from client's point
682 of view. For servers and routers this of course means that they need
683 to decrypt and re-encrypt each private message. Since this way of securing
684 private message cannot be used at all times the SILC protocol provides
685 other ways of securing private messages.
689 <h2>Private Message Delivery With Private Message Key</h2>
691 Private messages can be secured with private message key as well. This
692 key is known only by the sender of the message and the receiver of the
693 message. This way no one else except the sender and the receiver can encrypt
694 and decrypt the private messages. The message is encrypted by the sender
695 with the private message key and all the servers and routers pass the message
696 through enroute to the receiver. They cannot decrypt the message since
697 they do not have the key. When sending private messages in this way it
698 does not matter whether the clients trust or do not trust the servers and
699 routers in the SILC network.
702 <object data="silc_priv2.jpg" type="application/postscript">
703 <a href="silc_priv2.png">
704 <img src="s_silc_priv2.png" alt="Private Messages with Private Message
705 Key" align="center" border="0"></a>
709 As the diagram above shows the Client A encrypts the message with private
710 message key and sends the message to the SILC Network. All servers and
711 routers merely pass the message through since they cannot decrypt it.
712 The Client B then receives the message and decrypts it with the private
716 Sending private messages in this manner is always secure since the key is
717 shared only by the sender and the receiver. The problem of this method
718 is that the sender and the receiver must somehow agree about the key
719 they are going to use. The private message key can generally be anything.
720 It can be a passphrase that only the sender and the receiver knows. They
721 could have been agreed to use some word or phrase as the key sometime
722 earlier before they started the conversation. Or the key maybe from some
723 random string from a code book that only the sender and the receiver poses.
724 Or it can be a key that is negotiated using some key exchange protocol.
727 The problem however is fundamental. How to agree to use some key when
728 you cannot reach the other person over secure channel? The SILC protocol
729 solves this problem by providing a possiblity to negotiate the key
730 between two clients using the SKE protocol. One or both of the clients
731 can set up the SKE server running in their host and ask the other client
732 to connect to it. In this case the SKE is executed outside the SILC
733 Network. As a result of the SKE protocol the clients have now shared
734 secret that they can use as private message key. The key is known only
735 by the two clients that executed the SKE protocol. They can then use
736 that key to secure all subsequent private messages.
739 Using this method of private messages delivery is recommended if the
740 clients cannot trust the servers and routers in the SILC Network. The
741 drawback is the extra phase of setting the private message key before
742 starting the conversation. However, using the SKE protocol is the
743 recommended way to negotiate the private message key since it can be
744 automatized and does not cause any extra tasks for end user.
749 <h2>Private Message Delivery With Public Key Encryption</h2>
751 If the clients cannot trust the servers and routers in the SILC Network
752 they can use the private message key. As described in the previous section
753 it is easy to set up with the SKE protocol. However, sometimes the two
754 clients do not want to use any passphrases as private message key or
755 negotiate the key with SKE, or perhaps they are unable to negotiate the
756 key because of some other external problem. The SILC protocol provides
757 yet another way of securing the private messages. This way does not
758 require setting or negotiating private message key. And, in this method
759 also it does not matter whether the clients trust or do not trust the
760 servers and routers in the SILC Network. The method is public key
761 encryption. The clients can encrypt the private messages with the
762 receiver's public key and send the message to the network. The servers
763 and routers cannot decrypt the messages since they do not have the
764 receiver's private key. The receiver on the other hand has the private
765 key which it uses to decrypt the message.
768 Even this method of private message delivery is not perfect. The drawbacks
769 of this method is that the sender must first assure that the public key
770 it is using in the encryption is actually the receiver's public key.
771 This is a absolute requirement in this method. If the sender cannot
772 authenticate the receiver's public key this method of private message
773 delivery should not be used. In SILC protocol clients can fetch other
774 clients public keys from servers, but the client still must verify the
775 key. Use of certificates can solve the problem. The receiver's certificate
776 could be authenticated by a third party Certification Authority (CA).
779 Usually verifying the public key is not a problem since the receiver
780 can provide the public key on some website, or verify the fingerprint of
781 the key over email, or phone call. The clients can also fetch the
782 public keys from SILC servers. If both of the clients trust that the
783 public keys are authentic using this method of private message delivery
784 is very simple and recommended.
789 <h1>MIME Messages</h1>
791 SILC Protocol supports MIME messages as normal channel and private
792 messages. By using MIME messages it is possible to send for example
793 images, music and video and audio stream in SILC. Any MIME type that is
794 supported by the application can be sent via SILC network.
797 The MIME messages are utilized by using so called Message Flags in the
798 message payload that is used in SILC protocol. The Message Flags
799 indicates the recipient that the message is a MIME message and it then
800 knows how to interpret the message. Using Message Flags it possible also
801 to send other kind of messages and to augment features of normal channel
802 and private messages.
807 <h1>Secure File Transfers</h1>
809 The file transfer support in chat protocols are a absolute requirement
810 nowadays, and chat protocol without one is no chat protocol at all. SILC
811 also supports file transfer with the addition that the file transfer
812 stream is secured. When a user wants to transfer a file to another
813 user, the SILC Key Exchange (SKE) protocol is first executed to negotiate
814 a session key for the file transfer stream. This key is then used to
815 protect the peer to peer stream between users.
818 The file transfer protocol used in SILC protocol is the SSH File Transfer
819 protocol (SFTP). Even though the name of the protocol relates to SSH,
820 the actual file transfer protocol has nothing to do with Secure Shell.
821 The SFTP is totally independent file transfer protocol and its stream
822 is secured using SILC. The SFTP is very good protocol because in addition
823 of providing simple file transfer support, it can also support complex
824 file and directory manipulation.
827 The support for file transfer in SILC has been designed so that using
828 practically any file transfer protocol is possible. The mandatory protocol
829 is SFTP but in the future adding support for other protocols is also
834 <h1>Future of the Protocol</h1>
836 The protocol has matured into the version 1.2 over the past few years.
837 It has reached a level where it is the most rich featured conferencing
838 protocol as of today. It is the SILC Project's intention to standardize
839 the SILC protocol in the IETF and this is where the focus is now moving.
845 Secure Internet Live Conferencing is a modern conferencing protocol which
846 provides rich conferencing features with high security. It has a wide
847 range of security properties and features that should meet the highest
848 levels of security requirements, while not forgetting ease of use. The
849 network topology offers new architectural solution with better scalability
850 over traditional chat protocols.
854 <h1>Further Information</h1>
856 More detailed information about the SILC protocol is available in the
857 SILC protocol specification documents. There exists currently six
858 Internet Drafts that defines the protocol in great detail. The Internet
859 Drafts are available from the <a href="http://silcnet.org">SILC Project
860 website</a> but also from the <a href="http://www.ietf.org">IETF website</a>.
863 For comprehensive introduction to cryptography refer to the
864 <a href="http://www.ssh.com/tech/crypto/">Cryptography A-2-Z document</a>.
868 <h1>Terms and Abbreviations</h1>
871 - Asymmetric cryptosystem
873 Asymmetric cryptosystem provides public encryption. It has two keys,
874 one public key and one private key (also called as secret key). The public
875 key is publicly available allowing anyone to encrypt messages with the
876 public key. Only the posessor of the private key can decrypt those messages.
877 Difference to symmetric cryptosystem is that symmetric cryptosystem use only
878 one key, and the key is usually used to both encryption and decryption. The
879 asymmetric cryptosystem is also called as public key encryption, public key
880 cryptosystem or public key algorithm. SILC supports RSA and DSS asymmetric
886 The verification of the identity of a person, host or process in order
887 to gain access to a service or prove identity. In data communications
888 it also means verifying the origin of a message.
893 Certificate is a digital document which can be used to verify the
894 identity of a person or host. In SILC, certificates can be used to prove
895 identity of clients, servers and routers. Basically certificate is a public
896 key with subject name. SILC supports X.509, OpenPGP and SPKI certificates.
897 Supported public keys are SILC style public key and SSH2 style public
901 - Certification Authority (CA)
903 A third party entity that can verify identity of a person or host. CA
904 is usually external company that provides certificates and their
905 verification services.
908 - Diffie-Hellman key exchange
910 First public key algorithm ever invented. It is used to generate a secret
911 key between two or more parties. It gets its security from the difficulty
912 of calculating discrete logarithms.
917 A mechanism (usually mathematical) to transfer plaintext (or cleartext)
918 to ciphertext to provide confidentiality. A process to transfer
919 the ciphertext back to plaintext is called decryption.
924 The verification of data to detect any modifications. If data is
925 modified enroute from the sender to the receiver, the modification will
931 Hash Message Authentication Code. Also called as keyed hash function.
932 It is a secret key authentication algorithm which proves that the message
933 is not modified and that the HMAC was computed by the sender of the
939 Key management is a set of processes and mechanisms which support key
940 exchange and maintainance of current keying relationships between parties,
941 including replacing older keys with new keys as necessary, by executing
945 - Man-in-the-middle attack
947 An attack against two connecting entities where the attacker executes
948 key exchange protocol with both of the parties indepently without
949 their knowledge. Both of the connecting entities will end up having secret
950 key with the attacker, and the attacker can encrypt and decrypt all the
951 messages that goes between the two entities.
954 - Message Authentication Code (MAC)
956 MAC provides message integrity by computing the MAC using a secret
957 key authentication algorithm (HMAC).
960 - Perfect Forward Secrecy (PFS)
962 A property of rekey (or key regeneration) which defines whether the
963 new key is derived from the old key. If Perfect Forward Secrecy is
964 selected the new key is never dependent of the old key which means
965 that if the old key would get compromised at later time it will not
966 compromise the new key. In SILC setting PFS in the SKE protocol means
967 executing the SKE protocol again. If PFS is not selected the new key
968 is always derived from the old key.
973 A key regeneration process where the old key has expired or is not
974 secure anymore to use. In this case rekey is performed and new key
978 - Symmetric cryptosystem
980 Symmetric cryptosystem is one key cryptosystem where one key is used
981 usually to both encryption and decryption process. The symmetric
982 cryptosystems are usually significantly faster than asymmetric cryptosystems.
983 DES, AES, Twofish and Blowfish are examples of symmetric cryptosystems.
984 SILC supports all the common symmetric cryptosystems including AES.
985 SILC does not support DES as it is insecure and 3DES as it is too slow.
projects / silc.git / blob