<font face="Helvetica">
-<font size="10"><b>SILC Protocol White Paper</b></font><br>
+<font size="7"><b>SILC Protocol White Paper</b></font><br>
<font size="2">Version 1.0 / 05 Aug 2001</font>
-<p><br>
+<p>
<h1>Introduction</h1>
Chat protocols are very popular on the Internet. They have actually
the IETF. The very first implementations of the protocol are also already
available.
-
+<p><br>
<h1>About This White Paper</h1>
<p>
The purpose of this white paper is to give short but deep enough introduction
<h1>SILC Packet Protocol</h1>
<p>
+The basis of SILC protocol relies in the SILC packets and they are with
+out a doubt the most important part of the protocol. The SILC Packet
+protocol is a binary packet protocol. The protocol provides secure
+binary packets and assures that the contents of the packets are secured
+and authenticated.
+<p>
+
+Packets are used in the SILC protocol all the time to send for example
+channel messages, private messages, commands and other information. All
+packets in SILC network are always encrypted and their integrity is
+assured by computed Message Authentication Codes (MAC). The protocol
+defines several packet types and packet payloads. Each packet type
+usually has a specific packet payload that actually defines the contents
+of the packet. Hence, the actual data in the packet is the packet payload
+defined in the protocol.
+<p>
+
<img src="silc_packet.JPG" alt="Typical SILC Packet" align="center" border"0">
+<p><br>
+As the diagram above illustrates the SILC packet is constructed from the
+SILC Packet Header that is included in all SILC packets, data area that
+includes the packet payloads, and MAC area which assures the integrity of the
+packet. Entire SILC packet is always encrypted, except for the MAC area
+which is never encrypted. The encryption process and the key used,
+however depends on the packet payload. Some of the payloads are encrypted
+with the session key and some are encrypted with other keys, for example
+with channel message keys. The SILC Packet Header is always encrypted with
+the session key. The MAC is computed from the SILC Packet Header and the
+data area before encrypting the packet.
<p><br>
<h1>Channels</h1>
<p>
+A channel is a named group of one or more clients which will all receive
+messages addressed to that channel. The channel is created when first
+client joins to it, and the channel ceases to exist when the last client
+leaves it. When channel exists, any client can reference it using the
+name of the channel. Channel is a place where group of people can engage
+conversation.
+<p>
+
+Channel names are unique in the SILC Network. There cannot be multiple
+same channels in the network at the same time. However, channel has also
+a Channel ID which is actually used to reference the channel in the
+SILC Network. The maximum length for the channel name is 256 characters.
+<p>
+
+Channels can have operators that can administrate the channel and operate
+all of its modes. There are two types of operators on the channel:
+channel founder and channel operator.
+<p>
+
+The channel founder is the client which created the channel. Channel
+founder is channel operator with some more privileges. Channel founder
+can operate all of the channel's modes. Furthermore, channel founder
+privileges cannot be removed by any other operator on channel and channel
+founder cannot be removed from the channel by force. It is also possible
+for the channel founder to regain its privileges at later time, even if
+they have left the channel.
+<p>
+
+Channel operator is operator that can operate most of the channel's
+modes and administrate the channel. However, it cannot operate all
+modes which are strictly reserved for channel founder. Channel operator
+is, however able to adminstrate the channel, set some modes on the
+channel, remove a badly behaving client from the channel, and promote
+other clients to become channel operator.
+
+
<p><br>
<h2>Channel Message Delivery</h2>
<p>
+All clients that have joined the channel can send messages to the channel.
+All channel messages are secured and authenticated by channel key. The
+channel key is generated by the server when the channel is created,
+a client joins the channel, or a client leaves the channel. The channel
+key is also regenerated periodically. The reason for the regeneration
+of channel key everytime someone joins or leaves the channel is that
+it prevents new clients joining the channel, and old clients leaving the
+channel, to encrypt or decrypt old or new messages. They can encrypt
+and decrypt channel messages only when they have joined on the channel.
+<p>
+
+Channel keys are cell specific in the SILC Network. Each cell that
+have clients joined on a particular channel have also own key for the
+channel. That key is not shared by other cells in the network. Inside
+the cell the channel key is known by the router and all servers that
+have clients on the channel and all clients that have joined the channel.
+
+<p>
<img src="silc_channel.JPG" alt="Channel Message Delivery" align="center" border"0">
+<p><br>
+
+The diagram above illustrates typical delivery of channel messages inside
+a cell and between two cells. Both of the cells have their own channel
+key. Both cells knows all clients joined on the channel. When message
+is sent to the channel by an client, it is encrypted with the current
+channel key in that cell. The servers and the router in the local cell
+then routes the message to all local clients who have joined the channel.
+If the channel has clients that belong to other cell in the network the
+router will route the channel message to that cell. When channel
+messages are send between routers they are first decrypted with the
+current channel key, and then re-encrypted with the session key shared
+between the two routers. The router who receives the channel message
+then decrypts it with the session and re-encrypts it with the
+current channel key in that cell. It then distributes the channel message
+to all clients on the channel. The clients who have joined the channel
+always knows the current channel key and can decrypt all channel messages
+they receive. Note that normal servers in the SILC network never decrypt
+the channel messages even though the have the key. There is no reason
+for servers to decrypt the message. The router decrypts the message
+only when sending it between two routers.
+<p>
+
+This method of channel message delivery is the the default way to send
+channel messages in the SILC Network. However, this is not perfect
+solution on all circumstances. If the clients joined on a particular
+channel cannot trust, or do not want to trust the servers and routers
+in the SILC Network they can consider the fact, that servers and routers
+knows the channel key is actually a breach of security.
+<p>
+
+If the clients on the other hand can trust their servers and routers
+in the SILC Network this is the recommended way of sending channel
+messages. This method is the simplest method for end user since it
+does not require any special settings before engaging the conversation
+on the channel. The client merely joins the channel, receives the
+channel key from the server and can start the conversation on the
+channel.
<p><br>
<h2>Channel Message Delivery With Channel Private Key</h2>
<p>
+If the clients cannot trust the servers and routers in the SILC Network
+they should not use the default way of sending the channel messages.
+Instead, they should use channel private keys to encrypt and decrypt
+the channel messages. Channel private keys are keys that are known
+only by the clients who have joined the channel. All servers and
+routers do not know the key and cannot decrypt the messages. When
+message is sent between two routers they are merely re-encrypted with
+the session key but not decrypted since the router do not have the
+key to do that.
+<p>
+
+The clients who have joined the channel must first agree on the channel
+private key they are going to use. The key may generally be anything.
+It may be a passphrase or a random string, or the key may negotiated
+using some key negotiation protocol which provides exchanging the
+key for multiple clients at the same time.
+<p>
+
+As the channel private key is actually entirely local setting in the
+client, it is possible to set several channel private keys for one
+channel. It is possible to have multiple channel private keys that
+are not known by all channel members. When encrypting messages with
+one channel private key only the clients who have that key can decrypt
+the message. The other key could be shared for example by all clients
+on the channel and thus all clients can decrypt messages encrypted with
+that key. In this way it is actually possible to have private group
+conversation inside the channel while having global conversation at the
+same time.
+
<p><br>
<h1>Private Messages</h1>
projects / silc.git / commitdiff