+<!-- This file is processed with html2ps to generate PostiScript.
+ Do not edit the HTML syntax unless you know what you are doing. -->
<html>
-<header>
+<head>
<title>SILC Protocol White Paper</title>
<link rev=made href="mailto:priikone@silcnet.org">
<meta name="Author" content="Pekka Riikonen - SILC Project">
<meta name="Description"
content="SILC - Secure Internet Live Conferencing Protocol">
-<meta name="Created" content="Version 1.0 / 05 Aug 2001">
+<meta name="Created" content="Version 1.2 / 22 October 2003">
</head>
<body bgcolor="#ffffff">
<font face="Helvetica">
-<font size="10"><b>SILC Protocol White Paper</b></font><br>
-<font size="2">Version 1.0 / 05 Aug 2001</font>
+<font size="6"><b>SILC Protocol White Paper</b></font><br>
+<font size="2">Version 1.2 / 22 October 2003</font>
-<p><br>
+<p>
<h1>Introduction</h1>
Chat protocols are very popular on the Internet. They have actually
have something in common; they are all insecure.
<p>
-The security is important feature in applications and protocols in
+The security is important feature in applications and protocols in
contemporary network environment. The older chat protocols, however have
-failed to deal with the growing security requirements on the Internet.
+failed to meet the growing security requirements on the Internet.
It is not anymore enough to just provide services, like for example
chat services. Now, they need to be secure services.
<p>
The SILC Protocol have been developed as Open Source project. The
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 protocol is currently stabilizing and has reached a version
+1.2.
+<p><br>
<h1>About This White Paper</h1>
<p>
The purpose of this white paper is to give short but deep enough introduction
audience. This document should be easy to understand for non-technical
person and still be detailed enough for technically oriented person. See
the section <a href="#terms">Terms and Abbreviations</a> for terms used
-in this documents.
+in this document.
<p>
<p>
-(c) Copyright 2001 Pekka Riikonen
+(c) Copyright 2001 - 2003 Pekka Riikonen
(<a href="mailto:priikone at silcnet.org">priikone at silcnet.org</a>)
<p>
This document is free document; you can redistribute it and/or modify
<h1>SILC Protocol</h1>
<p>
-<img src="silc_network.JPG" alt="SILC Network" align="center" border"0">
+Secure Internet Live Conferencing, or SILC in short, is a modern
+conferencing protocol which provides rich conferencing features with
+high security. One of the main design principles of the protocol was
+security. Many of the SILC features are found in traditional chat
+protocols such as IRC but many of the SILC features can also be found
+in Instant Message (IM) style protocols.
+<p>
+
+SILC combines features from both of these chat protocol styles, and
+can be implemented as either IRC-like system or IM-like system. In
+fact, SILC removes the need to make such distinction between these
+two protocol styles. Some of the more advanced and security features
+of the protocol are new to all conferencing protocols. SILC also
+supports multimedia messages and can also be implemented as a
+video and audio conferencing system. The protocol is also compact
+and robust and suites well for mobile environments where the low
+bandwidth sets special requirements for protocols. All packet sizes
+in SILC can be even further reduced by utlizing compression.
+<p>
+
+The packets and messages in the SILC network are always encrypted and
+authenticated. It is not possible to send unencrypted messages in SILC
+at all. This assures that end user cannot even accidently send unencrypted
+messages while thinking that it is encrypted. This is one of the problems
+of most of the other chat protocols that provide so called plugin encryption.
+They are not secure by default but try to provide security by applying
+external security protocol such as PGP or SSL over the insecure
+protocol. In these cases the security is achieved usually by encrypting the
+data while key management, message authentication and other security issues
+may be left out, leaving the implementation vulnerable to various security
+problems. The other problem is also that the external protocols tend to
+leave the network only partly secured; usually only two points in the
+network are secured with for example SSL. While SSL does provide provable
+security it is not enough to provide security for a chat network as a whole.
+<p>
+
+SILC is secure in environment of mutual distrust between entities
+in the network. It is possible to encrypt messages end to end, so that only
+the sender and the receiver is able to encrypt and decrypt messages. It
+is also possible to send messages to group of users, so that only the
+specified group of users is able to encrypt and decrypt messages. Many
+times the protocol use keys that are generated by the servers, so that
+if other external key exchange methods fail the network still remains
+encrypted. However, it is always possible to negotiate and use locally
+generated keys to secure messages, so that the servers do not know the
+key.
+<p>
+
+Like so many other contemporary chat protocols, SILC too provides
+file transfer. It is possible to transfer files securely between users
+in the SILC Network. The actual file transfer stream is always sent
+outside the network peer to peer. Before the file transfer is started
+a key exchange protocol is executed to negotiate file transfer session
+key.
+<p>
+
+The SILC protocol also supports so called detaching, a novel idea where
+it is possible to detach from the server without actually quitting the
+network. It is then later possible to resume the connection back to some
+server in the network, and be like you were never gone.
+<p>
+
+The SILC protocol also allows distribution and exchange of public keys
+and certificates through the SILC network. It is also possible to fetch
+detailed user information from other users through the SILC network. It
+is possible to fetch for example users's business card, pictures,
+certificates, etc.
+<p>
+
+SILC protocol also supports services, which are extensions to the core
+protocol. They can be used to augment the features of the protocol or
+to add entirely new features without breaking backwards compatibility.
+Services can be negotiated online and authenticated with passphrases or
+with digital signatures.
+<p>
+
+The network topology is also different from traditional conferencing and
+chat protocols. The SILC network forms so called hybrid ring-mesh network
+at the router level, and star network at the server level. This sort of
+network topology allows better scalability and faster delivery of packets
+than traditional spanning tree style network. The router servers and normal
+servers also has the distinction that only router's know global information
+and keep the global network state up to date, and normal servers keep only
+local information up to date. This significantly increases the scalability
+of the network. The network also supports backup routers which can be
+used to protect the network against netsplits.
+
+<p><br>
+<object data="silc_network.jpg" type="application/postscript">
+<a href="silc_network.png">
+<img src="s_silc_network.png" alt="SILC Network" align="center"
+border="0"></a>
+</object>
+<p><br>
+
+The diagram above illustrates a portion of the SILC network. It shows
+two cells that both have several servers, and backup routers and several
+clients. Clients can connect to server and routers if they want to.
+The following sections will describe the entities of the SILC Network
+in greater detail.
+<p>
+
<p><br>
<h2>Clients</h2>
The clients are distinquished from other clients by unique Client ID.
There cannot be multiple same Client IDs in the SILC Network at the same time.
The end user, however does not use Client IDs. The end users usually selects
-a perferred nickname they want to use, and identifies themself with that
+a preferred nickname they want to use, and identifies themself with that
nickname to other users on the network. The nicknames are not unique in
the SILC Network. There can be multiple same nicknames at the same time
-on the network. The maximum length for the nickname is 128 characters.
+on the network. The maximum length for the nickname is 128 bytes.
<p>
Most of the other chat protocols have unique nicknames. This is where SILC
differs from most of the other chat protocols. The purpose of this
feature is to make IRC style nickname wars obsolete, as no one owns their
-nickname; there can always be somene else with the same nickname.
+nickname; there can always be somene else with the same nickname. This
+feature also makes nickname registering services obsolete.
<p>
When client connects to the server the SILC Key Exchange (SKE) protocol and
Perfect Forward Secrecy (PFS). The connection authentication protocol is
used to authenticate the client to the server. The server may allow the
client to connect without authentication, or it may require a passphrase or
-public key encryption based authentication.
+public key based (or certificates) authentication.
<p><br>
usually does not keep track of global clients, however, it may cache
that information if it was queried. The reason for this is that the
server does not need to keep global information up to date and thus
-makes the server faster. They can always query the information from
-the router.
+makes the server faster (and in the end the entire network faster).
+They can always query the information from the router.
<p>
When server connects to its router the SILC Key Exchange (SKE) protocol
when client connects to server. The SKE results in to the session key
that is used to secure the communication between the server and the
router. The connection authentication protocol is used to authenticate
-the server to the router. The authentication is always based in either
-passphrase or public key encryption.
+the server to the router. The authentication is always based in either
+passphrase or public key (or certificates).
<p><br>
Each router has a primary route to other router in the network. Finally
the ring is closed by the last router using the first router in the
network as its primary route.
-<p>
-<img src="silc_routers.JPG" alt="SILC Routers" align="center" border"0">
+<p><br>
+<object data="silc_routers.jpg" type="application/postscript">
+<a href="silc_routers.png">
+<img src="s_silc_routers.png" alt="SILC Routers" align="center"
+border="0"></a>
+</object>
<p><br>
The diagram above illustrates how the routers forms a ring in the network.
<h1>SILC Packet Protocol</h1>
<p>
-<img src="silc_packet.JPG" alt="Typical SILC Packet" align="center" border"0">
+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 secure 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><br>
+<object data="silc_packet.jpg" type="application/postscript">
+<a href="silc_packet_png">
+<img src="s_silc_packet.png" alt="Typical SILC Packet" align="center"
+border="0"></a>
+</object>
+<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 after encryption. This is so called Encrypt-Then-MAC order.
<p><br>
<h1>SILC Key Exchange Protocol</h1>
<p>
+SILC Key Exchange Protocol (SKE) is used to exchange shared secret
+between connecting entities. The result of this protocol is a key material
+used to secure the communication channel. This protocol is executed when,
+for example client connects to server. It is also executed when server
+connects to router. And, there is no reason why it could not be executed
+between two clients too, if two clients would need to create secret key.
+The purpose of the SKE protocol is to create session keys to be used
+in current SILC session. The SKE is based on the Diffie-Hellman key
+exchange algorithm, and is immune to for example man-in-the-middle attacks
+by using digital signatures.
+<p>
+
+This is the first protocol that is executed when creating connection to,
+for example SILC server. All the other protocols are always executed
+after this protocol. This way all the other protocols are secured since
+the SKE creates the session key that is used to secure all subsequent
+packets. The session keys created in the SKE are valid only for some
+period of time (usually an hour) or at most until the session ends.
+The rekey process can be executed with or without the Perfect Forward
+Secrecy (PFS).
+<p>
+
+The security properties that are used in the SILC session are also
+negotiated during the SKE. The protocol has initiator and responder.
+The initator is the one who starts the SKE negotiation and responder is
+the one who receives the SKE negotiation. When the protocol is started
+initiator sends a list of security properties that it supports. The
+responder then selects the security properties it supports and sends
+its reply to the initiator. The security properties includes ciphers,
+hash functions, public key algorithms, HMAC functions and other
+security properties. The responder can always choose the properties
+it supports.
+<p>
+
+After the security properties are selected the protocol continues
+by performing the Diffie-Hellman key exchange algorithm. At the same
+time the intiator and responder also sends their public keys or
+certificates to each other. The initiator and responder also computes a
+signature that the other party will verify. By default the protocol is
+executed in so called mutual authentication mode, where both of the
+parties computes a signature which are verified by each other
+independently. This way both of the parties will have prove the
+posession of the private key to the public key they are providing
+in the protocol. If any of the phases of the protocol are to fail the
+connection is closed immeadiately.
+<p>
+
+The public key or certificate that is received during the SKE protocol
+must be verified. If it is not verified it would be possible to
+execute a man-in-the-middle attack against the SKE protocol. If
+certificates are used they can be verified by a third party Certification
+Authority (CA). Verifying a public key requires either confirming
+a fingerprint of the public key over phone or email, or the server
+can for example publish the fingerprint (and the public key) on some
+website. In real life systems accepting the public key without
+verification, however is often desired. In many security protocols,
+such as in SSH2, the public key is accepted without verification
+in the first time when the connection is created. The public key is
+then cached on local hard disk. When connecting next time to the
+server the public key on local cache is verified against the public
+key server sent. In real life this works most of the time. However,
+if client (or server) cannot trust this, it must find some other way
+to verify the received public key or certificate.
+
<p><br>
-<h1>SILC Connection Authentcation Protocol</h1>
+<h1>SILC Connection Authentication Protocol</h1>
+<p>
+
+Purpose of SILC Connection Authentication protocol is to authenticate the
+connecting party with server or router. This protocol is executed when
+for example client connects to server. It is also executed when server
+connects to router. Its other purpose is to provide information for the
+server about which type of connection it is. The type of the connection
+defines whether it is client, server or router. If it is client then
+the server will create a new Client ID for the client. If it is server
+then it will except the server to send its Server ID. Server IDs are
+created by the servers and routers itself.
<p>
+Since the SILC Connection Authentication protocol is always executed after
+the SKE protocol, session keys has been established already. This means
+that all packets sent in the connection authentication protocol are encrypted
+and authenticated.
+<p>
+
+The authentication may be based either in passphrase or public key
+encryption. It is also possible to not require authentication at all.
+If the authentication is based to passphrase the passphrase is sent
+to the server. As the packet sent by, for example client, is entirely
+encrypted it is safe to send the passphrase inside the packet.
+<p>
+
+If the authentication is based to public key then, for example the client,
+signs data with its private key and sends it to the server. The server
+then verifies this signature by using the client's public key. The
+packet is also encrypted in the case of public key authentication.
+<p>
+
+If the authentication is to fail the connection to the server or router
+will be refused. If it is successful the connection is granted. After
+this the client is ready to communicate in the SILC Network.
<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>
-<img src="silc_channel.JPG" alt="Channel Message Delivery" align="center" border"0">
+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><br>
+<object data="silc_channel.jpg" type="application/postscript">
+<a href="silc_channel.png">
+<img src="s_silc_channel.png" alt="Channel Message Delivery"
+align="center" border="0"></a>
+</object>
+<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 sent 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 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>
+
+In addition of encrypting channel messages it also possible to digitally
+sign all sent channel messages. The receiver could then verify the
+signature of each of the message using the sender's public key.
+
<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. 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 exchange protocol which provides negotiating 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 a private group
+conversation inside the channel while having global conversation at the
+same time.
+
<p><br>
<h1>Private Messages</h1>
<p>
-Private messages are messages that are sent from one client to another
+Private messages are messages that are sent from one client to another
through the SILC Network. They are private because they are not sent to
anyone else except to the true receiver of the message. Private messages
can be used to engage private conversation with another client if channels
of all people. The end user should decide the acceptable level of risk,
the required level of security and other security and usability aspects when
deciding what way of sending private message suites for them.
+<p>
+
+In addition of encrypting private messages it also possible to digitally
+sign all sent private messages. The receiver could then verify the
+signature of each of the message using the sender's public key.
<p><br>
<p>
Sending private messages are by default secured with session keys established
in the SKE protocol. This means that the private message is always encrypted
-with the session key of the next receiver of the message enroute to the
+with the session key of the next receiver of the message enroute to the
receiving client. This also means that the message is decrypted and
re-encrypted everytime it is sent further to the receiving client.
-<p>
-<img src="silc_priv1.JPG" alt="Basic Private Message Delivery" align="center" border"0">
+<p><br>
+<object data="silc_priv1.jpg" type="application/postscript">
+<a href="silc_priv1.png">
+<img src="s_silc_priv1.png" alt="Basic Private Message Delivery"
+align="center" border="0"></a>
+</object>
<p><br>
-As the above diagram shows the private messages sent by Client A to the
+As the diagram above shows the private messages sent by Client A to the
Client B travels through the SILC Network and is always decrypted and
re-encrypted with the session key of the next receiver. The Client B then
finally decrypts the private messages that is encrypted with the session
to be untrusted.
<p>
-If the clients on the other hand trust the servers and routers in their
+If the clients on the other hand trust the servers and routers in their
SILC Network, or they do not care that servers can decrypt their messages,
sending private messages in this way is very simple from client's point
of view. For servers and routers this of course means that they need
they do not have the key. When sending private messages in this way it
does not matter whether the clients trust or do not trust the servers and
routers in the SILC network.
-<p>
-<img src="silc_priv2.JPG" alt="Private Messages with Private Message Key" align="center" border"0">
+<p><br>
+<object data="silc_priv2.jpg" type="application/postscript">
+<a href="silc_priv2.png">
+<img src="s_silc_priv2.png" alt="Private Messages with Private Message
+Key" align="center" border="0"></a>
+</object>
<p><br>
-As the above diagram shows the Client A encrypts the message with private
+As the diagram above shows the Client A encrypts the message with private
message key and sends the message to the SILC Network. All servers and
routers merely pass the message through since they cannot decrypt it.
The Client B then receives the message and decrypts it with the private
could have been agreed to use some word or phrase as the key sometime
earlier before they started the conversation. Or the key maybe from some
random string from a code book that only the sender and the receiver poses.
-Or it can be a key that is negotiated using some key negotiation protocol.
+Or it can be a key that is negotiated using some key exchange protocol.
<p>
The problem however is fundamental. How to agree to use some key when
solves this problem by providing a possiblity to negotiate the key
between two clients using the SKE protocol. One or both of the clients
can set up the SKE server running in their host and ask the other client
-to connect to it. As a result of the SKE protocol the clients have
-now shared secret that they can use as private message key. The key
-is known only by the two clients that exexcuted the SKE protocol. They
-can then use that key to secure all subsequent private messages.
+to connect to it. In this case the SKE is executed outside the SILC
+Network. As a result of the SKE protocol the clients have now shared
+secret that they can use as private message key. The key is known only
+by the two clients that executed the SKE protocol. They can then use
+that key to secure all subsequent private messages.
<p>
Using this method of private messages delivery is recommended if the
-clients cannot trust the servers and routers in the SILC Network. The
+clients cannot trust the servers and routers in the SILC Network. The
drawback is the extra phase of setting the private message key before
starting the conversation. However, using the SKE protocol is the
recommended way to negotiate the private message key since it can be
-automized and does not cause any extra tasks for end user.
+automatized and does not cause any extra tasks for end user.
+<!--
<p><br>
<h2>Private Message Delivery With Public Key Encryption</h2>
<p>
key which it uses to decrypt the message.
<p>
-<img src="silc_priv3.JPG" alt="Private Messges with Public Key Cryptosystem" align="center" border"0">
-<p><br>
-
-As the above diagram shows the Client A has the Client B's public key.
-It will encrypt the message with that key and sends the message to the
-SILC Network. All servers and routers pass the message through since
-they cannot decrypt it. The Client B then uses its private key to
-decrypt the message. The Client B has also the Client A's public key
-that it can use to encrypt messages that it will send to Client A.
-<p>
-
Even this method of private message delivery is not perfect. The drawbacks
-of this method is that the public key encryption process, as being
-assymmetric cryptosystem, is much slower than encryption process with
-symmetric cryptosystems. This is not probably problem with short messages
-but may be inconvenient with long messages. The other drawback is that the
-sender must first assure that the public key it is using in the encryption
-is actually the receiver's public key. This is a absolute requirement
-in this method. If the sender cannot authenticate the receiver's public
-key this method of private message delivery should not be used. In SILC
-protocol clients can fetch other clients public keys from servers.
-However, the servers may not have authenticated the fetched public key so
-that should not be fully trusted. Use of certificates can solve the
-problem. The receiver's certificate could be authenticated by a third
-party Certificate Authority (CA).
+of this method is that the sender must first assure that the public key
+it is using in the encryption is actually the receiver's public key.
+This is a absolute requirement in this method. If the sender cannot
+authenticate the receiver's public key this method of private message
+delivery should not be used. In SILC protocol clients can fetch other
+clients public keys from servers, but the client still must verify the
+key. Use of certificates can solve the problem. The receiver's certificate
+could be authenticated by a third party Certification Authority (CA).
<p>
Usually verifying the public key is not a problem since the receiver
can provide the public key on some website, or verify the fingerprint of
the key over email, or phone call. The clients can also fetch the
-public keys from SILC servers if they trust that the keys are authentic.
-If both of the clients trust that the public keys are authentic using this
-method of private message delivery is very simple and recommended.
+public keys from SILC servers. If both of the clients trust that the
+public keys are authentic using this method of private message delivery
+is very simple and recommended.
+-->
<p><br>
-<h1>Conclusions</h1>
+<h1>MIME Messages</h1>
+
+SILC Protocol supports MIME messages as normal channel and private
+messages. By using MIME messages it is possible to send for example
+images, music and video and audio stream in SILC. Any MIME type that is
+supported by the application can be sent via SILC network.
+<p>
+
+The MIME messages are utilized by using so called Message Flags in the
+message payload that is used in SILC protocol. The Message Flags
+indicates the recipient that the message is a MIME message and it then
+knows how to interpret the message. Using Message Flags it possible also
+to send other kind of messages and to augment features of normal channel
+and private messages.
+
<p><br>
-<h1>Further Information</h1>
+<h1>Secure File Transfers</h1>
+
+The file transfer support in chat protocols are a absolute requirement
+nowadays, and chat protocol without one is no chat protocol at all. SILC
+also supports file transfer with the addition that the file transfer
+stream is secured. When a user wants to transfer a file to another
+user, the SILC Key Exchange (SKE) protocol is first executed to negotiate
+a session key for the file transfer stream. This key is then used to
+protect the peer to peer stream between users.
<p>
-More detailed information about the SILC Protocol is available in the
-SILC Protocol specification documents. There exists currently four
-Internet Drafts that defines the protocol in great detail. The Internet
-Drafts are available from the following sources but also from the
-<a href="http://www.ietf.org">IETF website</a>.
+
+The file transfer protocol used in SILC protocol is the SSH File Transfer
+protocol (SFTP). Even though the name of the protocol relates to SSH,
+the actual file transfer protocol has nothing to do with Secure Shell.
+The SFTP is totally independent file transfer protocol and its stream
+is secured using SILC. The SFTP is very good protocol because in addition
+of providing simple file transfer support, it can also support complex
+file and directory manipulation.
<p>
-- <a href="http://silcnet.org/docs/draft-riikonen-silc-spec-03.txt">
-Secure Internet Live Conferencing (SILC), Protocol Specification</a>
-<br>
+The support for file transfer in SILC has been designed so that using
+practically any file transfer protocol is possible. The mandatory protocol
+is SFTP but in the future adding support for other protocols is also
+possible.
-- <a href="http://silcnet.org/docs/draft-riikonen-silc-pp-03.txt">
-SILC Packet Protocol</a>
-<br>
-- <a href="http://silcnet.org/docs/draft-riikonen-silc-ke-auth-03.txt">
-SILC Key Exchange and Authentication Protocols</a>
-<br>
+<p><br>
+<h1>Future of the Protocol</h1>
+
+The protocol has matured into the version 1.2 over the past few years.
+It has reached a level where it is the most rich featured conferencing
+protocol as of today. It is the SILC Project's intention to standardize
+the SILC protocol in the IETF and this is where the focus is now moving.
-- <a href="http://silcnet.org/docs/draft-riikonen-silc-commands-01.txt">
-SILC Commands</a>
-<br>
+<p><br>
+<h1>Conclusion</h1>
+
+Secure Internet Live Conferencing is a modern conferencing protocol which
+provides rich conferencing features with high security. It has a wide
+range of security properties and features that should meet the highest
+levels of security requirements, while not forgetting ease of use. The
+network topology offers new architectural solution with better scalability
+over traditional chat protocols.
+
+
+<p><br>
+<h1>Further Information</h1>
+<p>
+More detailed information about the SILC protocol is available in the
+SILC protocol specification documents. There exists currently six
+Internet Drafts that defines the protocol in great detail. The Internet
+Drafts are available from the <a href="http://silcnet.org">SILC Project
+website</a> but also from the <a href="http://www.ietf.org">IETF website</a>.
+<p>
+
+For comprehensive introduction to cryptography refer to the
+<a href="http://www.ssh.com/tech/crypto/">Cryptography A-2-Z document</a>.
<p><br>
<a name="terms"></a>
<h1>Terms and Abbreviations</h1>
+<p>
+
+- Asymmetric cryptosystem
+<p>
+Asymmetric cryptosystem provides public encryption. It has two keys,
+one public key and one private key (also called as secret key). The public
+key is publicly available allowing anyone to encrypt messages with the
+public key. Only the posessor of the private key can decrypt those messages.
+Difference to symmetric cryptosystem is that symmetric cryptosystem use only
+one key, and the key is usually used to both encryption and decryption. The
+asymmetric cryptosystem is also called as public key encryption, public key
+cryptosystem or public key algorithm. SILC supports RSA and DSS asymmetric
+cryptosystems.
+<p>
+
+- Authentication
+<p>
+The verification of the identity of a person, host or process in order
+to gain access to a service or prove identity. In data communications
+it also means verifying the origin of a message.
+<p>
+
+- Certificate
+<p>
+Certificate is a digital document which can be used to verify the
+identity of a person or host. In SILC, certificates can be used to prove
+identity of clients, servers and routers. Basically certificate is a public
+key with subject name. SILC supports X.509, OpenPGP and SPKI certificates.
+Supported public keys are SILC style public key and SSH2 style public
+key.
+<p>
+
+- Certification Authority (CA)
+<p>
+A third party entity that can verify identity of a person or host. CA
+is usually external company that provides certificates and their
+verification services.
+<p>
+
+- Diffie-Hellman key exchange
+<p>
+First public key algorithm ever invented. It is used to generate a secret
+key between two or more parties. It gets its security from the difficulty
+of calculating discrete logarithms.
+<p>
+
+- Encryption
+<p>
+A mechanism (usually mathematical) to transfer plaintext (or cleartext)
+to ciphertext to provide confidentiality. A process to transfer
+the ciphertext back to plaintext is called decryption.
+<p>
+
+- Integrity
+<p>
+The verification of data to detect any modifications. If data is
+modified enroute from the sender to the receiver, the modification will
+be detected.
+<p>
+
+- HMAC
+<p>
+Hash Message Authentication Code. Also called as keyed hash function.
+It is a secret key authentication algorithm which proves that the message
+is not modified and that the HMAC was computed by the sender of the
+message.
+<p>
+
+- Key management
+<p>
+Key management is a set of processes and mechanisms which support key
+exchange and maintainance of current keying relationships between parties,
+including replacing older keys with new keys as necessary, by executing
+rekey.
+<p>
+
+- Man-in-the-middle attack
+<p>
+An attack against two connecting entities where the attacker executes
+key exchange protocol with both of the parties indepently without
+their knowledge. Both of the connecting entities will end up having secret
+key with the attacker, and the attacker can encrypt and decrypt all the
+messages that goes between the two entities.
+<p>
+
+- Message Authentication Code (MAC)
+<p>
+MAC provides message integrity by computing the MAC using a secret
+key authentication algorithm (HMAC).
+<p>
+
+- Perfect Forward Secrecy (PFS)
+<p>
+A property of rekey (or key regeneration) which defines whether the
+new key is derived from the old key. If Perfect Forward Secrecy is
+selected the new key is never dependent of the old key which means
+that if the old key would get compromised at later time it will not
+compromise the new key. In SILC setting PFS in the SKE protocol means
+executing the SKE protocol again. If PFS is not selected the new key
+is always derived from the old key.
+<p>
+
+- Rekey
+<p>
+A key regeneration process where the old key has expired or is not
+secure anymore to use. In this case rekey is performed and new key
+is generated.
+<p>
+
+- Symmetric cryptosystem
+<p>
+Symmetric cryptosystem is one key cryptosystem where one key is used
+usually to both encryption and decryption process. The symmetric
+cryptosystems are usually significantly faster than asymmetric cryptosystems.
+DES, AES, Twofish and Blowfish are examples of symmetric cryptosystems.
+SILC supports all the common symmetric cryptosystems including AES.
+SILC does not support DES as it is insecure and 3DES as it is too slow.
+
</font>
projects / silc.git / blobdiff