SILC - Secure Internet Live Conferencing
========================================
-SILC (Secure Internet Live Conferencing) is a protocol which provides
-secure conferencing services in the Internet over insecure channel.
-SILC is IRC like softwarre although internally they are very different.
-Biggest similarity between SILC and IRC is that they both provide
-conferencing services and that SILC has almost same commands as IRC. Other
-than that they are nothing alike. Biggest differences are that SILC is
-secure what IRC is not in any way. The network model is also entirely
-different compared to IRC.
+SILC (Secure Internet Live Conferencing) is a modern and secure
+conferencing protocol.
+
+
+Features
+========
+
+SILC provides all the common conferencing services like private messages,
+instant messages, channels and groups, and video and audio conferencing.
+The main difference to other protocols is that SILC has been designed with
+security as its main feature - it is not an add-on or optional plugin -
+and security cannot be turned off.
+
+All SILC connections execute SILC Key Exchange protocol, an authenticated
+Diffie-Hellman key exchange algorithm, to generate a shared secret session
+key. All SILC packets exchanged between SILC clients and servers are
+protected with these keys.
+
+All private messages (instant messages) are protected with private message
+keys established using the SILC Key Exchange protocol over the SILC network.
+Private messages can be read only by the sender and the recipient of the
+message. SILC servers along the way cannot decrypt the messages.
+Optionally, private message key may also be a shared secret, such as
+passphrase, or the SILC Key Exchange may be performed peer-to-peer between
+clients. If all these methods fail the session keys are used as the last
+resort fallback to encrypt private messages.
+
+All channel and group messages are protected with channel specific keys
+generated by the SILC routers and only the members of the channel may read
+the messages. Optionally, channel members may set up a shared secret,
+such as passphrase, as the channel key to exclude SILC routers from knowing
+the key.
Running SILC
This will launch the server on to the background.
-SILC Commands
-=============
-
-
- /SERVER [<server>[:<port>]]
-
- Connects to remote SILC server.
-
- /NICK [<nickname>]
-
- Changes/sets nickname. Note that in SILC there can be
- multiple same nicknames. However, the logic on working
- with multiple nicknames on user interface is pretty much
- still missing. Also note that nicknames in SILC are
- case-sensitive.
-
- /JOIN <channel>
-
- Joins to a channel. Channel names start with `#'
- character.
-
- /LEAVE <channel>
-
- Leaves the channel. If /leave * is given the client
- leaves the current channel.
-
- /CMODE <channel> +|-<modes> [{ <arguments>}]
-
- Changes/sets channel mode. Most of the modes require
- special privileges, such as channel operator or channel
- founder privileges to work. The mode is added by adding
- + before the option(s) and removed by adding - before
- the option(s). Following modes are available:
-
- p Set/unset channel as private channel
- s Set/unset channel as secret channel
- k Set/unset that channel uses private channel key
- i Set/unset channel as invite only channel
- t Set/unset that only channel operator or
- founder may set channel topic
- l <limit> Set/unset channel's user limit
- a <passphrase> Set/unset passphrase for channel that must
- be provided when joining to the channel.
- c <cipher> Set/unset channel's cipher
- h <hmac> Set/unset channel's hmac
- f <-pubkey|<password>
- Set/unset channel founder authentication.
- Channel founder may set this mode so that
- if the client leaves the channel it can
- claim the founder rights when it returns
- to the channel. If -pubkey is set then
- the authentication will be done using the
- client's public key. You can claim the
- founder rights using the CUMODE command.
-
- Multiple modes can be set/unset at once if the modes does not
- require any arguments. If mode requires an argument then only
- one mode can be set at once.
-
- /CUMODE <channel> +|-<modes> <nickname>[@<server>] [-pubkey|<passwd>]
-
- Changes/set user's mode on a channel. Most of the modes
- require that the client who changes some client's mode must
- be channel founder or channel operator. Following channel
- user modes are available:
-
- a <nickname>[@<server>]
-
- Set/unset all modes (cannot be used to set
- both founder and operator rights, can be used
- only to remove both modes at once).
-
- f <nickname>[@<server>] [-pubkey|<password>]
-
- Set/Unset channel founder. If the -pubkey
- option or <password> is provided then the
- client is claiming the founder rights by
- providing the channel founder authentication
- data. If the -pubkey is provided then the
- authentication is performed using the
- client's public key. If you are channel
- founder you can set the channel founder
- authentication using CMODE command.
-
- o <nickname>[@<server>]
-
- Set/unset channel operator. Requires that
- you are channel operator or channel founder.
-
- /UMODE +|-<modes>
-
- Sets/unsets user mode. Note that some of the modes the
- client cannot set itself. The following user modes are
- available:
-
- a Unset all modes
- s Unset server operator privileges
- r Unset router operator privileges
- g Set/unset to be gone (or use /AWAY command)
-
-
- /MSG <nickname> <message>
-
- Sends private message to remote client. Support for
- handling multiple same nicknames with /MSG command is
- still missing.
-
- /WHOIS <nickname>[@<server>] [<count>]
-
- Gives a little information about a client. Support for
- handling multiple same nicknames with this command is
- still missing.
-
- /WHOWAS <nickname>[@<server>] [<count>]
-
- Gives a little history information about a client.
-
- /INVITE <channel> [<nickname>[@server>]
- [+|-[<nickname>[@<server>[!<username>[@hostname>]]]]]
-
- Invites client to a channel or manages the invite list of
- the channel. The first <nickname> argument is used if an
- client is invited to the channel. The second +|-<nickname>
- argument is used to either add or delete invite from the
- channel's invite list. Wildcards may be used with this
- command.
-
- /BAN <channel> [+|-[<nickname>[@<server>[!<username>[@hostname>]]]]]
-
- Manages the ban list of the channel. Wildcards may be used
- with this command. You must be channel operator to be
- able to use this command.
-
- /KICK <channel> <nickname>[@<server>] [<comment>]
-
- Kicks client from channel. You have to be at least channel
- operator to be able to kick client from channel. Note:
- you cannot kick channel founder even if you are channel
- operator.
-
- /PING [<server>]
-
- Pings server. Only locally connected server may be
- pinged.
-
- /INFO [<server>]
-
- Requests information about a server. If argument is
- not specified current server is used.
-
- /AWAY [<message>]
-
- Sets away message. When private message is received and
- away message is set the client automatically replies to
- the sender with the away message. To remove away message
- give the command without arguments.
-
- /QUIT
-
- Quits session. Connection to remote server is closed.
-
- /CLEAR
-
- Clears current screen.
-
- /VERSION
-
- Shows client version.
-
- /OPER <username> [<public key>]
-
- Obtains server operator privileges.
-
- /SILCOPER <username> [<public key>]
-
- Obtains router operator privileges.
-
- /KILL <nickname> [<comment>]
-
- Router operator can use this command to remove an client
- from the SILC Network temporarily.
-
- /CONNECT <server> [<port>]
-
- Connects to server the remote <server>. You must be
- server operator to be able to do this.
-
-
- /CLOSE <server> [<port>]
-
- Closes connection to the <server>. You must be server
- operator to be able to do this.
-
- /SHUTDOWN
-
- Shutdowns the server. You must be server operator to be
- able to do this.
-
- /MOTD [<server>]
-
- Display the MOTD of the server. If server is not specified
- the current server is used.
-
- /LIST [<channel>]
-
- Lists all channels in the current server, or the channel
- specified. If the channel cannot be found then all
- channels are listed.
-
- /KEY msg|channel <nickname|channel>
- set|unset|list|agreement|negotiate [<arguments>]
-
- This command is used to set and unset private keys for
- channels, set and unset private keys for private messages
- with remote clients and to send key agreement requests and
- negotiate the key agreement protocol with remote client.
- The key agreement is supported only to negotiate private
- message keys, it currently cannot be used to negotiate
- private keys for channels, as it is not convenient for that
- purpose.
-
- Types:
-
- msg The command is performed for private messages
- affecting the <nickname>.
-
- channel The command is performed for channel affecting
- the <channel>.
-
-
- Commands:
-
- set [<key> [<cipher>] [<hmac>]]
-
- Set the key into use. If the <key> is provided it
- is used as the key material. If the <key> is not
- provided the negotiated key material is used. If
- the negotiation has not been performed this command
- has no effect.
-
- If the type is `msg' and the <key> is `*' then
- random key will be generated automatically.
-
- The <cipher> may be set for both private message
- and channel private keys and the <hmac> may be set
- only to the channel private keys.
-
- unset [<number>]
-
- Unset the key. The private key is not used after
- this command. The key must be set again or the key
- material must be re-negotiated to be able to use
- the private keys again.
-
- The channel may have several private keys set. The
- <number> can be used to indicate what key is being
- unset. If it is not provided all keys are removed.
-
-
- list List all private keys that has been set.
-
- If the type is `msg' and the <nickname> is ´*' then
- all private message keys that you've set will be
- listed.
-
- agreement [<hostname> [<port>]]
-
- Send key agreement request to remote client. If
- the <hostname> is provided it is sent in the request.
- The receiver may use the hostname to start the
- key agreement. If the <port> is also provided your
- key agreement protocol server is bound to that
- port. Note that it cannot be privileged port (<1023).
- If the <hostname> and <port> is not provided then
- the receiver will never initiate the key agreement.
- In this case you must start the key agreement after
- receiving the reply to the request, by giving the
- /KEYAGR start command.
-
- This command may be used to send reply to the
- remote client. When receiving empty key agreement
- you can reply to the sender with the hostname and
- port of your key agreement server with this command.
-
- negotiate [<hostname> [<port>]]
-
- This may be called to start the key agreement with
- <nickname>. This command has effect only if the
- <nickname> has replied to your key agreement request.
- You will see a notify on the screen when the reply
- arrives. The <hostname> and <port> is the hostname
- and port of the remote client's key agreement
- server.
-
- /ME <channel> <action message>
-
- This command is used to send an action to the channel.
- This equals to CTCP's ACTION (IRC's /ME) command.
-
- /NOTICE <channel> <message>
-
- This command is used to send for example informational
- notice messages to the channel.
-
- /GETKEY <nickname>
-
- Fetches remote client's public key.
-
-Features
-========
-
-Features to be included into the final release of SILC. [Note that the
-current Developer's Version does not include all of these features, read
-TODO file for more information.]
-
- o Normal conferencing services such as private messages, channels,
- channel messages, etc. All traffic is secured and authenticated.
-
- o No unique nicknames. There can same nicknames in SILC without
- collisions. SILC has unique Client ID's, Server ID's and Channel ID's
- to assure that there are no collisions.
-
- o Secure key exchange and authentication protocol. SILC Key Exchange
- protocol provides key material used in the SILC sessions in secure
- manner. The protocol is immune for example to man-in-the-middle
- attacks. The SILC Authentication protocol provides strong
- authentication. Authentication may be based on passphrase or public
- key (RSA) authentication. For clients there is an option not to
- use authentication when connecting to servers.
-
- o All traffic is encrypted and authenticated using the best cryptographic
- algorithms out there. Command messages, private messages and channel
- messages are all protected by encryption. User can set private keys
- for both private message and for channels so that even SILC servers do
- not know the keys. Cipher keys are, by default, 128 bits in length and
- public keys, by default, 1024 bits in length.
-
- o Supports data compression with GZIP to improve performance.
-
- o Supports SOCKS4 and SOCKS5 firewall traversal protocols.
-
- o SIM (SILC Module) support. Support for loading of shared objects at
- run-time that provides new and extended features to both SILC client
- and server. These can provide extra ciphers and extra features to
- the software.
-
- o SILC client can be installed and used without root privileges.
-
- o SILC client can be configured by system wide configuration files but
- with user specific configuration files as well.
-
-
History
=======
-Even though SILC were released in summer 2000 to the public the idea and
-the protocol itself is quite old. I got the idea about SILC in its
-current form in the year 1996 and first lines of codes were written in
-early 1997. This release is now third rewrite of the SILC. The very first
-version were written in 1997 and it included SILC client and very very
-preliminary SILC server. The server actually weren't usable but the
-client looked pretty much the same as it does now. At that time the SILC
-also included RSA implementation and 3DES implementation. The random
-number generator that exists in this current release is actually based on
-the RNG written in 1997. The RNG written in 1997, on the other hand, were
-based on the SSH's random number generator. The RNG has been rewritten
-twice since the first version.
-
-I stopped writing the SILC later in 1997 when I got busy at school and in
-work. The pause lasted several months. The development resumed in 1998
-when my friend (Juha Räsänen) and I implemented ElGamal algorithm. I
-rewrote some other parts as well. However, for the same reasons as
-previously the development stopped again. I resumed the development later
-in 1998 by doing rewrite of the SILC in C++. This was obviously a mistake
-but at that time it seemed like a good idea. Again, in the winter 1999 I
-got very busy writing my thesis and was forced to stop the development
-again. I also, started a new job in the spring.
-
-Later, in 1999, I decided that this time I'm going to make it the right
-way. C++ was obviously a bad choice so I decided to fall back to plain C
-language. I also decided to do complete rewrite and started doing more
-thorough planning of what the SILC actually should include. I also
-decided that this time it is going to kill me before I stop the
-development. I started writing SILC in the weekends and actually
-everytime I had some spare time. I also started a new job but I didn't
-let that get to my way. The result of this development effort is the
-release now in public.
-
-I've learned a lot by doing the SILC. I guess, when I started it I wasn't
-that good of a C programmer. That alone was a reason why SILC hasn't seen
-the day of light before now. My programming style has also changed
-dramatically during these years. Actually, it has changed couple times
-since this last rewrite as well. However, the code style of current SILC
-release is quite consistent (actually the coding style SILC has been
-written now I've learned in my current job).
-
-There is probably over 85% of new code in this third rewrite. Rest has
-just been copied from the old versions and only minor changes has been
-made (like changed function names and overall coding style). I've
-preserved the dates of the old files (dating back to 1997) that has
-existed in some forms in the old versions. There is a lot of new code but
-already I see a lot that needs rewriting. The development continues.
+SILC was developed between 1996 and 1999 and released to public in 2000.
+SILC was originally developed by Pekka Riikonen.
Contact
development mailing list.
Official SILC project web site : http://silcnet.org/
-FTP archive for SILC project : ftp://silc.pspt.fi/pub/silc/
-Development mailing list address : silc-devel@lists.sourceforge.net
+FTP archive for SILC project : ftp://ftp.silcnet.org/
+Development mailing list address : silc-devel@lists.silcnet.org
+SILC Server : /server silc.silcnet.org
- Pekka Riikonen <priikone@poseidon.pspt.fi>