- About Us
Security has been the primary design goal in the development of the SILC protocol. It is a known fact that chat protocols have been insecure and vulnerable to many security problems. In the contemporary network environment, which is both demanding and full of potential security risks, developing a secure chat protocol is important. In the SILC protocol, all messages are always encrypted and authenticated, either using session keys, channel keys, or other private message keys. In fact, sending unencrypted messages and packets is impossible in the SILC network.
This is the problem of many other chat protocols that provide message encryption. These protocols are not secure by default, but attempt to provide the security by applying external security protocols, such as PGP or SSL on top of the insecure chat protocol. While PGP and SSL have proved to be secure, the result is often something other than the authors expected. These protocols often encrypt only the data of the message, and leave out message authentication, packet authentication, key management and other security issues. They also often secure only part of the network, namely the part where the security protocol, such as SSL, is used, leaving rest of the network open.
Something old, something new, something borrowed, something blue
SILC chat protocol provides all the features that are so familiar to all of us who have been chatting for quite some time. It provides nicknames, channels, private messages, user retrieval, and all the tools that every chatter needs to reach the ultimate chatting experience. For those who have been using IRC, chances are they feel at home with SILC, because most of the commands that are found in IRC are also found in SILC, and the general appearance resembles IRC. The protocol, however, is not based on IRC and does not support it.
But there are new features, too. In addition to providing all the old features now as secure ones, there are many new commands that control various security features of a SILC client. Channel messages are always encrypted, and so are private messages. It is possible to encrypt any message end to end, so that only the sender and the receiver is able to encrypt and decrypt messages. All channels have their own channel key and only the users on the channel are able to encrypt and decrypt messages for that channel. Many times, servers create default keys, so that the network always remains encrypted even if other secret keys are not used or negotiated by an end user. Users can negotiate secret keys with other users, and use the negotiated key material to secure, for example, private messages, or perhaps a file transfer stream.
Yes, a chat protocol is not a chat protocol nowadays without a file transfer support. SILC use the SFTP protocol by default to do its file transfers. The file transfer stream is always sent peer to peer between users, and it is encrypted using negotiated secret keys. The support for file transfer is actually developed so that any file transfer protocol can be used with SILC. The SFTP is the default protocol but others could be used, too.
Keys, keys and keys
It might seem that managing all these keys that do this and that is hard. Managing the keys is extremely important, but the user interface plays an important role in the ease of use. Negotiating the keys for file transfer, for example, can be transparent and can be done automatically when the file transfer request is sent. During the negotiation, the user may be prompted to accept the remote user's public key before continuing. Verifying the public keys before accepting them is, of course, important, the same with the server public key when the user connects for the very first time to the server. The SILC Protocol has its own SILC public key, but it also supports SSH2 public keys, OpenPGP certificates and X.509 certificates.
"Give me my nickname back!"
This is something we have all heard of once or twice on IRC. The fact that there can be only one nickname of a kind in IRC makes it hard to find the nickname you really like without stepping into someone's territory. And, this usually leads into nickname wars. The DALnet IRC network and some others solve the problem by providing nickname registering services, so that you can register the nickname you want and no one else can have it.
SILC takes an entirely different approach to the problem. And it is simple; nicknames are not unique. Just like there are many people in the world with same name, there can be many people with same nickname in the SILC network. Why would you want to enforce that there cannot be same nicknames in the chat network when there are bound to be people with same name chatting in the same network? In the SILC network, it is possible to have multiple copies of the same nickname, and it is always guaranteed that you will get the nickname you want. This renders nickname wars obsolete, and nickname registering services as well.
New users in the SILC network will face this issue when they give WHOIS command to a nickname and the WHOIS returns multiple same nicknames. A user can be identified as different from other users by his real name, username, hostname, and in the end by the fingerprint of his public key. Because there can be same nicknames, identifying the person you really want to talk to is important. Giving the WHOIS command before sending a private message to "joe" might be a good idea.
Deploying the SILC
SILC is meant for Internet-wide use, and the protocol attempts to scale better than IRC. The network design of SILC allows for a more scalable network because it does not require for all servers to keep global data in sync. Normal SILC servers are connected to SILC routers, and the routers are the only entities in the network that know global data, and are responsible of keeping it in sync. This dramatically reduces the number of entities in the network that need to be in sync.
SILC also fits perfectly as a company's internal chat server. Many companies have already reported that they have replaced their IRC servers with SILC servers. Even though the software is still in beta phase, and more client implementations are needed, SILC is usable and can be deployed in any environment. SILC is also distributed as a toolkit to make SILC application development easy and fast for programmers.
The SILC project's home is at http://silcnet.org, and interested readers are asked to take a look at the SILC Whitepaper, SILC FAQ and other documentation. The ultimate resource for those who would like to know how the protocol ticks is the protocol specification drafts. The protocol specifications are also available from the IETF. The SILC Network is naturally a nice place to find help as well as talk about SILC. Joining #silc channel is a good start.