updates.

diff --git a/doc/whitepaper/silc_protocol.html b/doc/whitepaper/silc_protocol.html
index 62c7aa4dd6161ab8665f024d43472d1454481ded..e7bdaa2365dbce45296cbdf077d538ed295ad26d 100644 (file)
--- a/doc/whitepaper/silc_protocol.html
+++ b/doc/whitepaper/silc_protocol.html
@@ -11,10 +11,10 @@
 
 <font face="Helvetica">
 
 
 <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>
 
 <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
 <h1>Introduction</h1>
 
 Chat protocols are very popular on the Internet.  They have actually


@@ -51,7 +51,7 @@ protocol specifications are freely available and they have been submitted to
 the IETF.  The very first implementations of the protocol are also already
 available.
 
 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>About This White Paper</h1>
 <p>
 The purpose of this white paper is to give short but deep enough introduction


@@ -213,8 +213,36 @@ the routers.  All the secondary routes also have their own session keys.
 <h1>SILC Packet Protocol</h1>
 <p>
 
 <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">
 <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>
 
 
 <p><br>


@@ -232,16 +260,137 @@ the routers.  All the secondary routes also have their own session keys.
 <h1>Channels</h1>
 <p>
 
 <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>
 
 <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">
 <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>
 
 
 <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>
 
 <p><br>
 <h1>Private Messages</h1>