SILC, a new generation secure chat protocol

[R. A. Hettinga]

http://www.newsforge.com/article.pl?sid=02/01/25/1727252&mode=thread



	 




Community feature: SILC, a new generation secure chat protocol
Saturday January 26, 09:05 AM EST    [ Open Source ]
- By Pekka Riikonen -
Have you been looking for a secure place to talk? A place where you can be
sure that the message you send to a person really goes to that person, no
one else is able to see the message, and no one is able to alter the
message? More and more people answer yes to the question, but where to find
such a place? The answer comes in the form of new generation chat protocol
called Secure Internet Live Conferencing, or just SILC (casually pronounced
as silk).

Security is the key

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.

Further information

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 helps. The protocol
specifications are also available from the IETF. The J SILC Network is
naturally a nice place to find help as well and talk about SILC. Joining
#silc channel is a good start.



-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com