SILC Protocol FAQ
 
 
1. SILC Protocol Questions
1.1 What is the status of SILC protocol in the IETF?
1.2 How much the SILC protocol is based on IRC?
1.3 Why use SILC? Why not IRC with SSL?
1.4 Can I talk from SILC network to IRC, ICQ, Jabber, etc. network?
1.5 Does SILC support file transfer?
1.6 Does SILC support DCC or alike?
1.7 I am behind a firewall, can I use SILC?
1.8 How secure SILC really is?
1.9 Does SILC support instant messaging?
1.10 Why SILC does not have LINKS command like in IRC?
1.11 What does the session detaching/resuming mean?
1.12 Is anyone outside a channel able to see the channel messages?
1.13 How can I register my channel in SILC?
1.14 Is it true that all messages are encrypted in SILC?
1.15 Can a server or SILC operator gain operator mode on a channel?
1.16 Channel name doesn't have a #-character or does it?
1.17 Does SILC support moderated channels?
1.18 What does the "watching" mean?
1.19 Is it possible to reject watching?
1.20 Is it possible to block private messages?
1.21 Is it possible to block channel messages?
1.22 Is it possible to block invites?
1.23 Does SILC support multimedia messages, like video/audio streaming?
1.24 Is it possible to send picture/image messages?
1.25 What kind of presence modes SILC support?
1.26 What are the Requested Attributes in SILC?
1.27 What format the business card use?
1.28 Does SILC support anonymity?
1.29 Does SILC support services?
1.30 What SILC services actually are?
1.31 Does SILC support off-line messages?
1.32 Does SILC support UTF-8?
1.33 What are channel public keys?
1.34 I have suggestions to SILC Protocol, what can I do?



1. SILC Protocol Questions
 
Q: What is the status of SILC protocol in the IETF?
A: The SILC protocol specifications has been submitted currently as individual submissions. There does not currently exist a working group for this sort of project. Our goal is to fully standardize the SILC and thus submit it as RFC to the IETF at a later time. This can happen only after we have requested the IETF to accept SILC as RFC. As of today, we have not yet even requested this from the IETF. We want to let the protocol mature a bit more.
 
Q: How much SILC Protocol is based on IRC?
A: SILC is not based on IRC. The SILC Client superficially resembles IRC client but everything that happens under the hood is nothing alike IRC. SILC could *never* support IRC because the entire network topology is different (more scalable and powerful). So no, SILC protocol (client or server) is not based on IRC. Instead, We've taken good things from IRC (and from other protocols) and left all the bad things behind and not even tried to burden the SILC with the IRCs problems that will burden IRC and future IRC projects till the end. SILC Client resembles IRC client because it is easier for new users to start using SILC when they already know all the commands.
 
Q: Why use SILC? Why not IRC with SSL?
A: Sure, that is possible, although, does that secure the entire IRC network? And does that increase or decrease the lags and splits in the IRC network? Does that provide user based security where some specific private message are secured? Does that provide security where some specific channel messages are secured? And I know, you can answer yes to some of these questions. But, security is not just about applying encryption to traffic and SILC is not just about `encrypting the traffic`. You cannot make insecure protocol suddenly secure just by encrypting the traffic. SILC is not meant to be IRC replacement. IRC is good for some things, SILC is good for same and some other things. Read also the SILC Crypto FAQ for more information.
 
Q: Can I talk from SILC network to IRC, ICQ, Jabber, etc. network?
A: Simple answer for this is No. The protocols are not compatible which makes it impossible to directly talk from SILC network to IRC network or vice versa. Developing a gateway between these networks would technically be possible but from security point of view strongly not recommended. We have no plans for developing such a gateway.
 
Q: Does SILC support file transfer?
A: Yes. The SILC protocol support SFTP as mandatory file transfer protocol. It provides simple client to client file transfer, but also a possibility for file and directory manipulation. Even though the SFTP is the file transfer protocol the support for file transferring has been done so that practically any file transfer protocol may be used with SILC protocol.
 
Q: Does SILC support DCC or alike?
A: SILC does not support the DCC commonly used in IRC. It does not need it since it has builtin support for same features that DCC have. You can transfer files securely and encrypted directly with another client. You can also negotiate secret key material with another client directly to use it in private message encryption. The private messages are not, however sent directly between clients. The protocol, on the other hand does not prohibit sending messages directly between clients if the implementation would support it. The current SILC Client implementation does not support it. This means that private messages travel through the SILC Network. SILC protocol also has a capability to support DCC and CTCP like protocols with SILC. However, none of them has been defined to be used with SILC at the present time.
 
Q: I am behind a firewall, can I use SILC?
A: Yes. If your network administrator can open the remote port 706 (TCP) you can use SILC without problems. You may also compile your SILC Client with SOCKS support which will proxy your SILC session through the firewall.
 
Q: How secure SILC really is?
A: We have tried to make SILC as secure as possible. However, there is no security protocol or security software that has not been vulnerable to some sort of attacks. SILC is in no means different from this. So, it is suspected that there are security holes in the SILC. These holes just need to be found so that they can be fixed. SILC's security features have been developed from attacker's point of view, and we've tried to find all the possible attacks and guard the protocol against them.
 
Please read the SILC Crypto FAQ for more detailed information.
 
Q: Does SILC support instant messaging?
A: Officially SILC is not an instant messaging (IM) system as people usually understand it. However, SILC supports many of the features that are found in traditional IM systems. SILC can be implemented in either IRC-style or IM-style system. Features that are usually found only in IM systems, such as multiple presence settings, persistent sessions etc. are also found in SILC.
 
Q: Why SILC does not have LINKS command like in IRC?
A: It was felt that this information as an own command in SILC is not necessary. Moreover, the topology of the network might be undisclosed information even though the servers and routers in the network are still open. We feel that the network topology information, if it is wanted to be public, and the list of accessible servers can be made available in other ways than providing command like LINKS, which shows the active server links in IRC.
 
Q: What does the session detaching/resuming mean?
A: The new SILC protocol supports a feature called session detachment. This means that a client can detach from the server by giving a DETACH command, but still remains as a valid user in the network. The connection is lost to the server but the user remains in the network. User can then resume the session back next time it connects a server in the network, and be like he was never gone.
 
This feature clearly could be used in many cases. For example, if you want to upgrade your current SILC client, you do not have to quit the network anymore. You just give DETACH command and still remain in the network. Then you upgrade your client and reconnect to the server and continue business as is. If somebody gives WHOIS command to your nickname he will see that you are detached. Messages that are sent to you when you are detached are dropped by the server. Nice thing about this feature is also that you can resume the session from any server in the network; you do not have to reconnect to the same server you originally were connected to.
 
Q: Is anyone outside a channel able to see the channel messages?
A: A short answer is simply No. A longer answer involves assumptions about security conditions. Initially channel keys are generated by the server, so if the server would get compromised it would be possible for an adversary to see the messages. However, users on the channel can prevent this even if the server would be compromised. It is possible to set so called channel private key that only the users on the channel know about. The servers does not know about the key, and therefore cannot see the messages even if they would be compromised. So, the longer answer results into same as the short one: No.
 
Q: How can I register my channel in SILC?
A: There is no channel registering service in SILC. However, SILC does support permanent channels. When you join a non-existing channel for the first time you will become the founder of the channel. You can then set a special founder mode on the channel which makes the channel permanent. When the last user leaves the channel when this mode is set, the channel will not be destroyed. If the founder mode is not set, then empty channels will be destroyed automatically. When the founder mode is set and you leave the channel you can also reclaim the founder rights back on the channel next time you join it. You can call this a channel registering if you want.
 
Q: Is it true that all messages are encrypted in SILC?
A: Most definitely yes. The SILC protocol makes it impossible to send unencrypted messages or packets to the SILC network. All messages are always encrypted, either using session keys, or other secret keys such as channel keys or private message keys.
 
Q: Can a server or SILC operator gain operator mode on a channel?
A: They cannot get operator status, founder status, join invite only channels, escape active bans, escape user limits or anything alike, without explicitly being allowed. The only way to get channel operator status is that someone ops you. Server and SILC operators in the network are normal users with the extra privileges of being able to adminstrate their server. They cannot do anything more than a normal user.
 
Q: Channel name doesn't have a #-character or does it?
A: The #-character is not mandatory part of channel name, like it is in IRC. This means that giving the command /JOIN #silc and /JOIN silc will join to different channels. This is intentional since the #-character clearly is IRC feature and has nothing to do with SILC. If you want it to have the character then just join to the channel with a #-character in the name.
 
Q: Does SILC support moderated channels?
A: Yes. A channel founder can moderate both normal users and channel operators so that they cannot talk on the channel. It is also possible to quiet one specific user on the channel if needed.
 
Q: What does the "watching" mean?
A: You can set a "watch" list for yourself in the server. This means that you can watch for certain nicknames in the network. For example, if you add a nickname "foo" to the watch list you will be notified when the foo logins to the network, leaves the network, changes its user mode or changes its nickname. This way you can watch for example when does you friend login to the network.
 
Q: Is it possible to reject watching?
A: Yes. Since it is clear that not everyone wants to be spied on you can set a mode for yourself which rejects watching you. Even if someone is watching the nickname you have, your logins, logoffs, mode changes or nickname changes will not be notified to the watcher.
 
Q: Is it possible to block private messages?
A: Yes. You can block incoming private messages by setting a mode that prevents unwanted private messages. Only the private messages that are secured with a private message key are delivered to you. This implies that you have negotiated the private key with the sender of the message, and therefore want to receive messages from that user. Other private messages that are secured with normal session keys are dropped when the mode is set.
 
Q: Is it possible to block channel messages?
A: Yes it is. By setting a mode that accomplishes this you can prevent the server from sending any channel messages to you. There is also a mode that allows blocking channel messages from normal users. This means that you will receive channel messages only when it is sent by a channel operator or a channel founder. It is also possible to block channel messages sent by robots. A user on the channel can have a robot mode set (which means that the user is actually a robot program), and messages sent from that user can be blocked with the mode.
 
Q: Is it possible to block invites?
A: It sure is. You can set a mode that prevents the server from sending invite notifications to you. This can for example prevent invite flooding. The downside is that it may make joining to a invite only channels a bit harder.
 
Q: Does SILC support multimedia messages, like video/audio streaming?
A: Yes it does. The new version of the protocol supports sending of MIME objects as messages. Since MIME objects can easily represent any kind of data, such as video stream, audio stream, images, etc. it is easy to send these multimedia messages in SILC. It also makes video conferencing possible with SILC. It can work by sending the stream(s) to a channel and everybody who joins the channel can receive the stream. This feature in the protocol surely makes possible many kind of multimedia applications in the future.
 
Q: Is it possible to send picture/image messages?
A: Yes. Since it is possible to send any kind of MIME object as a message it is also possible to send pictures and images as messages. It would be possible to for example send hand/mouse written messages.
 
Q: What kind of presence modes SILC support?
A: By presence we mean indication of presence in the network, and SILC supports several different kinds of presence modes. They can be changed with the UMODE command which changes your user mode in the network. Currently there are the following modes for presence: GONE (I'm away), INDISPOSED (I cannot be here), BUSY (I'm busy, don't bother me), PAGE (page me if you want to talk), and HYPER (I'm hyper active, talk to me). When mode is not set it means you are present in the network. There are many other user modes as well, but they are not directly related to presence indication.
 
Q: What are the Requested Attributes in SILC?
A: The Requested Attributes, or user online precense and information attributes, as they are officially called are an extension to the WHOIS command which is used to query information about other users in the network. Using the attributes it is possible to receive more detailed information about the user, such as their business card, pictures, public keys and certificates, user's mood, status texts and messages, geolocation, and other information. In short, the requested attributes are used to deliver information that is not delivered by the default WHOIS command, and you can send pretty much anything with the attributes.
 
Q: What format the business card use?
A: The business card that can be sent using the requested attributes is in the VCard standard format.
 
Q: Does SILC support anonymity?
A: The protocol has a user mode which indicates that user is an anonymous user. The user cannot set or unset the mode itself, but a server which provides these anonymous chatting services can set the mode for an user that connects to the server. User that has the mode set has their username and hostname information scrambled. There are other ways of making anonymity in SILC but they all are implementational methods, and protocol does not handle those methods.
 
Q: Does SILC support services?
A: Yes it does. There is command called SERVICE which can be used by clients and servers to negotiate a service agreement with a remote server. The protocol does not however define any services currently.
 
Q: What SILC services actually are?
A: Often people confuse that SILC services would be similar to IRC services, but this is not the case. The SILC services are actually protocol extensions that augment the features of the core protocol. Usually the services define their own protocol that all the parties of the service support. They are not robot-like services like in IRC where you talk to the services with messages.
 
Q: Does SILC support off-line messages?
A: Off-line messages are messages that sent to users that are not in the network. SILC does not by default support off-line messages. Messages sent to detached users will be dropped by the server. It would be possible to develop a service that allows the server to save the messages sent to detached user. It would be wise to make this user configurable, so that messages are saved only if user requested the service from the server. Security issues still remains in the message saving service that would need to be solved.
 
Q: Does SILC support UTF-8?
A: All text messages, channel messages, private messages and other text messages are always UTF-8 encoded in SILC. It is however possible to send for example textual channel messages with other encodings as well, and tell the encoding in the message so that receiver may render it correctly. However, by default, text messages are UTF-8 encoded.
 
Q: What are channel public keys?
A: Channel public key mode can be set on channel to allow joining to the channel for only those users whose public key has been added to the channel public key list. When a user joins to the channel he must provide a digital signature which is used to authenticate the joining to the channel. If the channel public key is not on the channel public key list the user cannot join. This feature is same as channel passphrase but works with digital signatures.
 
Q: I have suggestions to SILC Protocol, what can I do?
A: All suggestions and improvements are of course welcome. You should read the protocol specifications first to check out whether your idea is covered by them already. The best place to make your idea public is the SILC development mailing list. You might want to checkout the TODO list from the CVS as well.