Types:
- MSG The command is performed for private messages
- affecting the <nickname>.
+ MSG The command is performed for private messages
+ affecting the <nickname>.
- CHANNEL The command is performed for channel affecting
- the <channel>.
+ 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 (<1024).
- If the <hostname> and <port> is not provided then
- the receiver will never initiate the key agreement.
- In this case you may start the key agreement after
- receiving the reply to the request, by giving the
- negotiate 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.
-
- If the hostname and port are ommitted, the irssi
- boolean variable use_auto_addr will be examined. If
- this variable is set, the value of auto_bind_ip will
- be used as the IP address to listen for the return
- reply, the value of auto_public_ip will be the IP
- address sent to the remote client, and auto_bind_port
- will be the port value to be bound to AND sent to
- the remote client. If auto_public_ip is unset, but
- auto_bind_ip IS, irssi will send the auto_bind_ip
- variable's value to the remote client.
-
- 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.
-
+ 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 (<1024). If the <hostname> and <port> is
+ not provided then the receiver will never initiate the key
+ agreement. In this case you may start the key agreement
+ after receiving the reply to the request, by giving the
+ negotiate 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.
+
+ If the hostname and port are ommitted, the irssi boolean
+ variable use_auto_addr will be examined. If it is set
+ the value of auto_bind_ip will be used as the IP address
+ to listen for the return reply, the value of auto_public_ip
+ will be the IP address sent to the remote client, and the
+ auto_bind_port will be the port value to be bound to and
+ sent to the remote client. If auto_public_ip is unset, but
+ auto_bind_ip is set, irssi will send the auto_bind_ip
+ variable's value to the remote client.
+
+ 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.
1.5 Why SILC? Why not IRC3?</a><br />
<a href="#f1_55" class="normal">
1.6 What platforms SILC supports?</a><br />
+ <a href="#f1_59" class="normal">
+1.7 How do you pronounce SILC?</a><br />
<a href="#f1_60" class="normal">
-1.7 Where can I find more information?</a><br />
+1.8 Where can I find more information?</a><br />
<a href="#f1_70" class="normal">
-1.8 I would like to help out, what can I do?</a>
+1.9 I would like to help out, what can I do?</a>
<br /> <br />
<a href="#f2_0" class="normal">2. Protocol Questions</a><br />
<a href="#f2_90" class="normal">
2.12 Is anyone outside a channel able to see the channel messages?</a><br />
<a href="#f2_100" class="normal">
-2.13 I have suggestions to SILC Protocol, what can I do?</a>
+2.13 Is it true that all messages are encrypted in SILC?</a><br />
+ <a href="#f2_110" class="normal">
+2.14 Can server or SILC operator gain operator mode on a channel?</a><br />
+ <a href="#f2_120" class="normal">
+2.15 I have suggestions to SILC Protocol, what can I do?</a>
<br /> <br />
<a href="#f3_0" class="normal">3. Client Questions</a><br />
<a href="#f3_10" class="normal">
3.1 Where can I find SILC clients?</a><br />
<a href="#f3_20" class="normal">
-3.2 Can I use SILC with IRC client and vice versa?</a>
+3.2 Can I use SILC with IRC client and vice versa?</a><br/>
+ <a href="#f3_25" class="normal">
+3.3 The default theme sucks, where can I find a better one?</a><br />
+ <a href="#f3_30" class="normal">
+3.4 How do I send a private message?</a><br />
+ <a href="#f3_40" class="normal">
+3.5 How do I negotiate secret key with another user?</a><br />
+ <a href="#f3_50" class="normal">
+3.6 How do I negotiate secret keys behind a NAT?</a><br />
+ <a href="#f3_60" class="normal">
+3.7 How do I change channel modes?</a><br />
+ <a href="#f3_70" class="normal">
+3.8 What does the founder mode on channel mean, and how do I set it?</a><br />
+ <a href="#f3_80" class="normal">
+3.9 I am founder of invite only channel, how can I join the channel after I have left it?</a><br />
+ <a href="#f3_90" class="normal">
+3.10 How can I op or deop somebody on channel?</a><br />
+ <a href="#f3_100" class="normal">
+3.11 How do I set private key for channel, and what does that mean exactly?</a><br />
+ <a href="#f3_110" class="normal">
+3.12 How do I transfer a file?</a><br />
+ <a href="#f3_120" class="normal">
+3.13 How can I get other users public keys?</a><br />
+ <a href="#f3_130" class="normal">
+3.14 How can I see the fingerprint of my public key?</a><br />
+ <a href="#f3_140" class="normal">
+3.15 I gave WHOIS to a nick, and it returned multiple replies, why?</a><br />
+ <a href="#f3_150" class="normal">
+3.16 Is there a command to see all linked servers?</a><br />
+ <a href="#f3_160" class="normal">
+3.17 How do I list the users of a channel?</a><br />
+ <a href="#f3_170" class="normal">
+3.18 What is the difference between OPER and SILCOPER commands?</a>
<br /> <br />
<a href="#f4_0" class="normal">4. Server Questions</a><br />
<a href="#f4_10" class="normal">
4.1 Where can I find SILC servers?</a><br />
<a href="#f4_20" class="normal">
-4.2 Can I run own SILC server?</a><br />
+4.2 Can I run my own SILC server?</a><br />
<a href="#f4_30" class="normal">
4.3 What is the difference between SILC server and SILC router?</a><br />
<a href="#f4_40" class="normal">
<a href="#f4_50" class="normal">
4.5 When I connect to to my server, it says "server does not support one of your proposed cipher", what is wrong?</a><br />
<a href="#f4_60" class="normal">
-4.6 Why SILC server runs on privileged port 706?</a>
+4.6 Why SILC server runs on privileged port 706?</a><br />
+ <a href="#f4_70" class="normal">
+4.7 I see [Unknown] in the log file, what does it mean?</a>
<br /> <br />
<a href="#f5_0" class="normal">5. Toolkit Questions</a><br />
5.5 Does the Toolkit package include any sample code?</a><br />
<br /> <br />
+
<a name="f1_0"></a>
<b>1. General Questions</b><br /> <br />
and native Windows.
<br /> <br />
+<a name="f1_59"></a>
+<samp class="highlight">Q: How do you pronounce SILC?</samp><br />
+A: SILC is usually pronounced as `silk', but you are free to pronounce
+it the way you want.
+<br /> <br />
+
<a name="f1_60"></a>
<samp class="highlight">Q: Where can I find more information?</samp><br />
A: For more technical information we suggest reading the SILC Protocol
<samp class="highlight">Q: I would like to help out, what can I do?</samp><br />
A: You might want to take a look at the <a
href="?page=contribute" class="normal">Contributing</a> page and the <a
-href="?page=todo" class="normal">TODO</a> list. You might also want to join the
+href="?page=todo" class="normal">TODO</a> list. You might also want to join the
SILC development mailing list.
<br /> <br />
+
<a name="f2_0"></a><br />
<b>2. Protocol Questions</b><br /> <br />
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 <a href="http://www.ietf.org/" class="normal">IETF</a> at a
-later time.
+thus submit it as RFC to the <a href="http://www.ietf.org/" class="normal">
+IETF</a> 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.
<br /> <br />
<a name="f2_20"></a>
<a name="f2_47"></a>
<samp class="highlight">Q: I am behind a firewall, can I use SILC?</samp><br />
-A: Yes. If your network administrator can open the port 706 (TCP) you can
-use SILC without problems. You may also compile your SILC client with
+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.
<br /> <br />
<a name="f2_50"></a>
<samp class="highlight">Q: How secure SILC really is?</samp><br />
-A: A good question which I don't have an answer for. 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.
+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 has been
+developed from attacker's point of view, and we've tried to find all the
+possible attacks and guard the protocol against them.
<br /> <br />
But to give you some parameters of security SILC uses the most secure
-crytographic algorithms such as AES(Rijndael), Twofish, Blowfish, RC5,
+crytographic algorithms such as AES (Rijndael), Twofish, Blowfish, RC5,
etc. SILC does not have DES or 3DES as DES is insecure and 3DES is just
too slow. SILC also uses cryptographically strong random number generator
when it needs random numbers. Public key cryptography uses RSA (PKCS #1)
To give a list of attacks that are ineffective against SILC:
<br /> <br />
- Man-in-the-middle attacks are ineffective if proper public key
-infrastructure is used. SILC is vulnerable to this attack if the public
-keys used in the SILC are not verified to be trusted (as any other
-protocol for that matter).<br />
- - IP spoofing is ineffective (because of encryption and trusted keys).<br />
- - Attacks that change the contents of the data or add extra data to the
+infrastructure is used, and if all public keys are always verified.<br />
+- IP spoofing is ineffective (because of encryption and trusted keys).<br />
+- Attacks that change the contents of the data or add extra data to the
packets are ineffective (because of encryption and integrity checks).<br />
- - Passive attacks (listenning network traffic) are ineffective (because
+- Passive attacks (listenning network traffic) are ineffective (because
of encryption). Everything is encrypted including authentication data
such as passwords when they are needed.<br />
- - Any sort of cryptanalytic attacks are tried to make ineffective by
-using the best cryptographic algorithms out there.
+- Any sort of cryptanalytic attacks are tried to make ineffective by
+using the best cryptographic algorithms out there, and by designing the
+protocol to guard against them.
<br /> <br />
<a name="f2_60"></a>
-<samp class="highlight">Q: Does SILC support instant messaing?</samp><br />
+<samp class="highlight">Q: Does SILC support instant messaging?</samp><br />
A: SILC is not an instant message (IM) system, like ICQ and the others.
SILC is more IRC like system, "real-time", connection-oriented chat and
-that kind of stuff. But I guess IRC is too called an Instant Messaging
-system.
+that kind of stuff. But I guess IRC is too sometimes called an Instant
+Messaging system.
<br /> <br />
<a name="f2_70"></a>
<br /> <br />
<a name="f2_100"></a>
-<samp class="highlight">Q: I have suggestions to SILC Protocol,
-what can I do?</samp><br />
+<samp class="highlight">Q: Is it true that all messages are encrypted in SILC?</samp><br />
+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.
+<br /> <br />
+
+<a name="f2_110"></a>
+<samp class="highlight">Q: Can server or SILC operator gain operator mode on a channel?</samp><br />
+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. Only way to get channel operator status is that someone
+ops him. 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.
+<br /> <br />
+
+<a name="f2_120"></a>
+<samp class="highlight">Q: I have suggestions to SILC Protocol, what can I do?</samp><br />
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.
+SILC development mailing list. You might want to checkout the TODO list
+from the CVS as well.
<br /> <br />
-
<a name="f3_0"></a><br />
<b>3. Client Questions</b><br /> <br />
<a name="f3_20"></a>
<samp class="highlight">Q: Can I use SILC with IRC client and vice versa?</samp><br />
A: Generally the answer would be no for both. However, there exist already
-at least one IRC client that supports SILC, the <a
-href="http://irssi.org/" class="normal">Irssi client</a>. The current SILC client is
-actually based on the user interface of the Irssi client. So, yes it is
-possible to use SILC with some IRC clients and vice versa. But, this
-does not mean that you can talk from SILC network to IRC network, that is
-not possible.
+at least one IRC client that supports SILC, the <a href="http://irssi.org/"
+class="normal">Irssi client</a>. The current SILC client is actually based
+on the user interface of the Irssi client. So, yes it is possible to use
+SILC with some IRC clients and vice versa. But, this does not mean that you
+can talk from SILC network to IRC network, that is not possible.
+<br /> <br />
+
+<a name="f3_25"></a>
+<samp class="highlight">Q: The default theme sucks, where can I find a better one?</samp><br />
+A: The Irssi SILC client's theme files are almost 100% compatible with
+the original Irssi IRC client's themes. You can get those theme files
+from the <a href="http://irssi.org/" class="normal">Irssi project website</a>.
+You can also try to make a better theme by yourself.
+<br /> <br />
+
+<a name="f3_30"></a>
+<samp class="highlight">Q: How do I send a private message?</samp><br />
+A: Sending private message is done by using the MSG command. For example,
+command: <samp class="highlight">/MSG john hello</samp>, will send a
+`hello' message to a nickname `john'. By default private messages are
+secured with session keys, and the message is re-encrypted by the servers
+when the message travels to the receiver. If you would like to secure the
+private messages with a private key, you can negotiate a secret key with the
+receiver. Always remember to give WHOIS command before sending a private
+message to assure that you are sending the message to correct person.
+<br /> <br />
+
+<a name="f3_40"></a>
+<samp class="highlight">Q: How do I negotiate secret key with another user?</samp><br />
+A: It is important to negotiate secret keys if you cannot trust the servers
+and the network you are using. By negotiating a key with the user you
+want to talk to assures that no one except you and your friend is able
+to encrypt and decrypt the messages. The secret key negotiation is done with
+the KEY command. Here is an example of how to negotiate keys for securing
+private messages.
+<br /> <br />
+By giving command: <samp class="highlight">/KEY MSG john agreement
+192.168.2.100</samp>, you will send a key negotiation request to a nickname
+`john'. The 192.168.2.100 IP address would be your machine's IP address.
+You can also define an port to the KEY command after the IP address. If
+you do not do that the operating system will bind to a port of its choosing.
+John will receive a notification on the screen that you would like to
+negotiate secret keys with him, and he will receive the IP address and port
+where you are listenning for the negotiation. When he gives command:
+<samp class="highlight">/KEY MSG You negotiate 192.168.2.100 31382</samp>,
+the key negotiation is started. During the key negotiation you will be
+prompted on the screen to verify and accept John's public key if you do not
+have his public key already. The John will be prompted to accept your
+public key as well. After the key negotiation is over all private messages
+sent between you and John are secured with the negotiated secret key.
+Note that you must verify the public key you are prompted for, and this is
+very important since someone could be doing man-in-the-middle attack.
+<br /> <br />
+
+<a name="f3_50"></a>
+<samp class="highlight">Q: How do I negotiate secret keys behind a NAT?</samp><br />
+A: If only you are behind a NAT, or firewall then key negotiation works,
+but if both you and your friend are behind a NAT then key negotiation will
+not work, since it is done peer to peer. If you are behind a NAT then you
+obviously cannot receive key negotiations, and cannot bind to any IP address
+and port. However, you can still use KEY command to negotiate the keys.
+<br /> <br />
+By giving command: <samp class="highlight">/KEY MSG john agreement</samp>,
+without any other arguments (such as IP address and port) you will send
+a negotiation request to John, but do not provide an address and port for
+the John to connect to. When John receives the notification on the screen
+that you would like to perform key negotiation, he can give command:
+<samp class="highlight">/KEY MSG You agreement 172.16.100.78</samp>, which
+will send key negotiation request back to you. You will receive the IP
+address and port where you need to connect in order to perform the negotiation.
+After receiving the notification you can give command: <samp class="highlight">
+/KEY MSG john negotiate 172.16.100.78 31181</samp>, which will start the
+key negotiation with John. This way you can negotiate the keys if you are
+behind a NAT.
+<br /> <br />
+
+<a name="f3_60"></a>
+<samp class="highlight">Q: How do I change channel modes?</samp><br />
+A: The command to manage channel modes is CMODE. With this command you
+can change the channel status (to change it to secret channel for example),
+set user limit on the channel, passphrase for the channel, set the channel
+to use private keys on channel, and set the founder mode.
+<br /> <br />
+
+<a name="f3_70"></a>
+<samp class="highlight">Q: What does the founder mode on channel mean, and how do I set it?</samp><br />
+A: Who ever creates the channel by being the first user to join the channel
+becomes automatically the founder of the channel. Founder has some extra
+privileges on the channel. For example, it is not possible to kick the
+founder off the channel, and there are some channel modes that only the
+founder of the channel can change. If the creator of the channel wishes
+to preserve the channel founder mode even if he leave the channel he
+can set the founder mode for the channel.
+<br /> <br />
+The mode is set by giving command: <samp class="highlight">/CMODE #channel
++f -pubkey</samp>. This will set the founder mode and will use the public
+key of the founder as authenticator when the user is reclaiming the mode
+back. If the founder leaves the channel he will be able to get the founder
+mode back by using JOIN or CUMODE commmands. Giving command
+<samp class="highlight">/JOIN #channel -founder -pubkey</samp>,
+will get the founder mode back at the same time he joins the channel, or
+giving commmand <samp class="highlight">/CUMODE #channel +f -pubkey</samp>,
+will also give the founder mode back on the channel after he has joined
+the channel.
+<br /> <br />
+If the channel is destroyed after the last client leaves the channel,
+the founder mode is also reset. Who ever creates the channel after that
+will also get the channel founder mode automatically. Note also that the
+founder mode is local. You can reclaim the mode back only on the same
+server where you set the founder mode in the first place.
+<br /> <br />
+
+<a name="f3_80"></a>
+<samp class="highlight">Q: I am founder of invite only channel, how can I join the channel after I have left it?</samp><br />
+A: Founder can override the invite only status by reclaiming the founder
+status on the channel using the JOIN command. The channel must have the
+founder mode set in order for it to work. Reclaiming founder status using
+JOIN command is important also if the channel has user limit set, and has
+active bans. Founder can override these conditions as well. However,
+founder cannot override the passphrase of the channel if it is set. To
+get the founder mode during JOIN and to override the invite only condition,
+give command: <samp class="highlight">/JOIN #channel -founder -pubkey</samp>.
+This will join the channel and attempt to reclaim the founder status back
+to you. Note that you need to be on the same server where you gave the
+founder mode for the channel for this to work.
+<br /> <br />
+
+<a name="f3_90"></a>
+<samp class="highlight">Q: How can I op or deop somebody on channel?</samp><br />
+A: Giving operator status, or removing the operator status on a channel
+requires you to have at least operator status, or founder status on the
+channel. You can give operator status to another user by using CUMODE
+command. To give ops give the command: <samp class="highlight">/CUMODE
+#channel +o john</samp>, and to remove ops give command:
+<samp class="highlight">/CUMODE #channel -o john</samp>. To indicate
+current channel you can also use `*' character in #channel's stead.
+<br /> <br />
+
+<a name="f3_100"></a>
+<samp class="highlight">Q: How do I set private key for channel, and what does that mean exactly?</samp><br />
+A: Setting private key for channel requires first to set the private key mode
+for the channel. You need to be the founder of the channel to be able to
+do this. Give the command: <samp class="highlight">/CMODE #channel +k</samp>.
+After this mode is set the old channel key will not be used to encrypt and
+decrypt channel messages. To set the key for the channel use the KEY command.
+Every user on the channel must do the same thing and set the same key.
+If some user on the channel does not set the key (or does not know the key)
+he won't be able to see any messages on the channel. Give the command:
+<samp class="highlight">/KEY CHANNEL #channel set verysecretkey</samp>.
+This command will set the `verysecretkey' passphrase as key to the #channel.
+How exactly other users will know this key is out of scope of the SILC
+protocol. SILC does not provide yet a possibility of negotiating secret key
+with many users at the same time. For this reason the secret key on the
+channel is usually a passphrase or a password that all users on the channel
+have to know. Setting a private key for channel means that only the users
+on the channel who know the key is able to encrypt and decrypt messages.
+Servers do not know the key at all. If you remove the private key mode
+from the channel, all users will start automatically using a new channel
+key to secure channel messages.
+<br /> <br />
+
+<a name="f3_110"></a>
+<samp class="highlight">Q: How do I transfer a file?</samp><br />
+A: You can transfer files securely using the FILE command. This command
+will automatically negotiate secret key with the remote user and the
+file transfer stream is secured using that key. The file transfer
+stream is always sent peer to peer. If you would like to send a file
+to another user you can give command: <samp class="highlight">/FILE
+SEND path/to/the/file john</samp>. This command sends, or actually
+makes the `path/to/the/file' available for download for the user `john'.
+The John will decide whether he wants to actually download the file.
+When John gives the command: <samp class="highlight">/FILE RECEIVE</samp>,
+the key negotiation is started. You and John will be prompted to verify
+and accept each other's public key if you do not have it cached already.
+After key negotiation is over the file transfer process starts.
+If you want to cancel the file transfer session, or if John wants to
+reject the file transfer request, giving the command: <samp class="highlight">
+/FILE CLOSE</samp> will close the session.
+<br /> <br />
+
+<a name="f3_120"></a>
+<samp class="highlight">Q: How can I get other users public keys?</samp><br />
+A: You can get a user's public key using the GETKEY command. This command
+will fetch the user's public key from the server where the user has connected
+to. The server has verified that the user posesses the corresponding private
+key, however, you will be prompted to verify and accept the public key.
+All client public keys are saved in your local key directory in
+~/.silc/clientkeys/. You can also receive clients public keys during
+key negotiation and file transfers. The GETKEY command can be used to fetch
+a server's public key as well. Those keys are saved in ~/.silc/serverkeys/
+directory.
+<br /> <br />
+
+<a name="f3_130"></a>
+<samp class="highlight">Q: How can I see the fingerprint of my public key?</samp><br />
+A: You can check out your own fingerprint by giving just WHOIS command without
+any arguments. Additionally you can also dump the contents of the key file
+using the silc program and giving -S option to it. Your own public key is
+always saved in ~/.silc/public_key.pub file. To dump your key run silc as:
+<samp class="highlight">silc -S .silc/public_key.pub</samp>. The same way
+you can dump the contents of any public key inside ~/.silc/clientkeys/ and
+~/.silc/serverkeys/ directories. The WHOIS command will also show other
+users public key fingerprints.
+<br /> <br />
+
+<a name="f3_140"></a>
+<samp class="highlight">Q: I gave WHOIS to a nick, and it returned multiple replies, why?</samp><br />
+A: This will happen if there are several same nicknames in the network at
+the same time. As you may already know nicknames are not unique in SILC
+network. This means there can be multiple same nicknames. This also means
+that you can always have the nickname you want. If WHOIS returns multiple
+replies, you can distinguish the users by their realname, username,
+hostname and ultimately by the fingerprint of their public key, which the
+WHOIS will also show. You will also notice an additional nickname inside a
+parenthesis. It may show for example: <samp class="highlight">nickname: John
+ (John@otaku)</samp>. The real nickname is `John', but since there are
+many John's in the network you can access this one using `John@otaku'.
+So, if you were to send private message to this particular John you can do
+it by giving command: <samp class="highlight">/MSG John@otaku hello</samp>.
+This will send `hello' message to the John@otaku.
+<br /> <br />
+
+<a name="f3_150"></a>
+<samp class="highlight">Q: Is there a command to see all linked servers?</samp><br />
+A: No there is not. For longer answer see also <a href="#f2_70"
+class="normal">this FAQ</a>.
+<br /> <br />
+
+<a name="f3_160"></a>
+<samp class="highlight">Q: How do I list the users of a channel?</samp><br />
+A: The command to list all users on a particular channel is USERS. It is
+also aliased to WHO command in Irssi SILC Client. To see the users of the
+current channel give the command: <samp class="highlight">/USERS *</samp>.
+You can replace the `*' with the channel name of your choosing. If the
+channel is private or secret channel, and you have not joined the channel,
+you cannot list the users of that channel.
+<br /> <br />
+
+<a name="f3_170"></a>
+<samp class="highlight">Q: What is the difference between OPER and SILCOPER commands?</samp><br />
+A: The OPER command is used to gain server operator privileges on normal
+SILC server, while SILCOPER is used to gain router operator (also known as
+SILC operator) privileges on router server. You cannot use SILCOPER command
+on normal SILC server, it works only on router server.
<br /> <br />
+
<a name="f4_0"></a><br />
<b>4. Server Questions</b><br /> <br />
<br /> <br />
<a name="f4_20"></a>
-<samp class="highlight">Q: Can I run own SILC server?</samp><br />
+<samp class="highlight">Q: Can I run my own SILC server?</samp><br />
A: Yes of course. Download the SILC server package, compile and install
it. Be sure to check out the installation instructions and the README
file. You also should decide whether you want to run SILC server or SILC
<br /> <br />
<a name="f4_60"></a>
-<samp class="highlight">Q: Why SILC server runs on privileged port 706?</samp>
-<br />
+<samp class="highlight">Q: Why SILC server runs on privileged port 706?</samp><br />
A: Ports 706/tcp and 706/udp have been assigned for the SILC protocol by
-IANA. Server on the network listening above privileged ports (>1023)
-SHOULD NOT be trusted as it could have been set up by untrusted party.
-The server normally drops root privileges after startup and then run as
-user previously defined in silcd.conf.
+<a href="http://www.iana.org" class="normal">IANA</a>. Server on the network
+listening above privileged ports (>1023) SHOULD NOT be trusted as it could
+have been set up by untrusted party. The server normally drops root privileges
+after startup and then run as user previously defined in silcd.conf.
<br /> <br />
+<a name="f4_70"></a>
+<samp class="highlight">Q: I see [Unknown] in the log file, what does it mean?</samp><br />
+A: You can see in the log file for example: <samp class="highlight">
+[Info] Closing connection 192.168.78.139:3214 [Unknown]</samp>. The [Unknown]
+means that the connection was not authenticated yet, and it is not known
+whether the connection was a client, server or router. There will appear
+[Client], [Server] or [Router] if the connection is authenticated at that
+point.
+<br /> <br />
+
+
<a name="f5_0"></a><br />
<b>5. Toolkit Questions</b><br /> <br />
<a name="f5_50"></a>
<samp class="highlight">Q: Does the Toolkit package include any sample code?</samp><br />
A: Yes, naturally. It includes sample codes for two different SILC Client
-implementations, and SILC Server. Win32 samples are included in the
-win32/ directory, for simple client.
+implementations, and SILC Server. The silcer/ directory includes a simple
+GUI client based on GTK--, and Win32 samples are included in the win32/
+directory, for simple client.
<br /> <br />
-
projects / silc.git / commitdiff