--- /dev/null
+ <br />
+<b><big>About SILC</big></b>
+<br /> <br />
+SILC (Secure Internet Live Conferencing) is a protocol which provides
+secure conferencing services on the Internet over insecure channel. SILC
+superficially resembles IRC, although they are very different internally.
+They both provide conferencing services and have almost the same set of
+commands. Other than that, they are nothing alike. The SILC is secure and
+the network model is entirely different compared to IRC.
+<br /> <br />
+SILC provides security services that any other conferencing protocol does
+not offer today. The most popular conferencing service, IRC, is entirely
+insecure. If you need secure place to talk to some person or to group of
+people over the Internet, IRC or any other conferencing service, for that
+matter, cannot be used. Anyone can see the messages and their contents in
+the IRC network. And the most worse case, some is able to change the
+contents of the messages. Also, all the authentication data, such as,
+passwords are sent plaintext in IRC.
+<br /> <br />
+SILC is much more than just about `encrypting the traffic'. That is easy
+enough to do with IRC and SSL hybrids, but even then the entire network
+cannot be secured, only part of it. SILC provides security services, such
+as sending private messages entirely secure; no one can see the message
+except you and the real receiver of the message. SILC also provides same
+functionality for channels; no one except those clients joined to the
+channel may see the messages destined to the channel. Communication
+between client and server is also secured with session keys and all
+commands, authentication data (such as passwords etc.) and other traffic
+is entirely secured. The entire network, and all parts of it, is secured.
+We are not aware of any other conferencing protocol providing same
+features at the present time.
+<br /> <br />
+SILC has secure key exchange protocol that is used to create the session
+keys for each connection. SILC also provides strong authentication based
+on either passwords or public key authentication. All authentication data
+is always encrypted in the SILC network. Each connection has their own
+session keys, all channels have channel specific keys, and all private
+messages can be secured with private message specific keys.
+<br /> <br />
+
+<b>Distribution</b>
+<br /> <br />
+The SILC is distributed currently in three different packages. The SILC
+Client package, the SILC Server package and the SILC Toolkit package. Each
+package has its intended audience.
+<br /> <br />
+- SILC Client package is intended for end users who are looking for a good
+and full featured SILC client. The SILC Client package currently includes
+Irssi-SILC client that supports all SILC features, themes and much more.
+It is curses based but has a possibility of adding various other frontends
+to it. The Irssi-SILC client's user interface is based on the Irssi client
+(see <a href="http://irssi.org/" class="normal">Irssi project</a>).
+<br /> <br />
+- SILC Server package is intended for system administrators who would like
+to run their own SILC server or SILC router. The package includes the
+actual server but not the client. If you are running a server and would
+like to connect it to the silc.silcnet.org router you can contact us.
+<br /> <br />
+- SILC Toolkit package is intended for developers and programmers who
+would like to create their own SILC based applications or help in the
+development of the SILC protocol. The actual development of the SILC is
+done in the Toolkit and all the other packages are based on the Toolkit
+releases. The Toolkit includes SILC Protocol Core library, SILC Crypto
+library, SILC Key Exchange (SKE) library, SILC Math library, SILC Modules
+(SIM) library, SILC Utility library, SILC Client library and few other
+libraries. It also includes the Irssi-SILC Client, another client as an
+example how to program with the Toolkit and the SILC Server.
+<br /> <br />
+
+<b>Licensing</b>
+<br /> <br />
+SILC is an Open Source (or Free Software) project and it has been released
+under the <a href="?page=copying" class="normal">GNU General Public License</a>. The SILC is free to use and everyone
+is allowed to freely redistribute and change the SILC under the terms of the
+GNU GPL. While there is no guarantee for the product, SILC is made as secure
+as possible. The fact that the software and the protocol is open for public
+analysis is a good thing for end user.
+<br /> <br />
+Specification of SILC protocol is available for anyone to look at. There
+exist four Internet Drafts that have been submitted to the <a
+href="http://www.ietf.org/" class="normal">IETF</a>. See <a
+href="?page=docs" class="normal">documentation page</a> for more information.
+<br /> <br />
+
+<b>Contact</b>
+<br /> <br />
+Feedback and comments are welcome. Bug reports should be sent to the
+development mailing list.
+<br /> <br />
+Development mailing list address:
+<a href="mailto:silc-devel@lists.sourceforge.net" class="normal">
+silc-devel@lists.sourceforge.net</a>
--- /dev/null
+ <br />
+<b><big>Contributing</big></b>
+<br /> <br />
+Developers are needed in SILC project. Everyone who has the time and
+ability is welcome to join the project. We need C coders and technical
+writers (to write documentation). Feel free to start narrowing down the <a href="?page=todo" class="normal">TODO</a> list.
+<br /> <br />
+Interested people are also welcome to give new ideas to the SILC protocol
+that is still in its draft phase. You should probably go and read the SILC
+protocol specification Internet Drafts to get the idea about what SILC
+actually is. The current software version might not give the whole picture
+of the SILC. The Internet Drafts are available in
+<a href="?page=docs" class="normal">documentation page.</a>
+<br /> <br />
+Who wants to send code to the project should read the <a
+href="docs/CodingStyle" class="normal">CodingStyle</a>
+documentation. New code must comply with the coding style conventions
+described in that document.
+<br /> <br />
+There is anonymous CVS acccess for those who want to participate the
+development process. See the <a href="?page=cvs" class="normal">CVS page.</a>
--- /dev/null
+ <br />
+<b><big>GNU GENERAL PUBLIC LICENSE<br />
+Version 2, June 1991</big></b>
+<br /> <br />
+Copyright (C) 1989, 1991 Free Software Foundation, Inc.<br />
+59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
+<br /> <br />
+Everyone is permitted to copy and distribute verbatim copies<br />
+of this license document, but changing it is not allowed.
+<br /> <br />
+<b>Preamble</b>
+<br /> <br />
+ The licenses for most software are designed to take away your
+freedom to share and change it. By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software--to make sure the software is free for all its users. This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it. (Some other Free Software Foundation software is covered by
+the GNU Library General Public License instead.) You can apply it to
+your programs, too.
+<br /> <br />
+ When we speak of free software, we are referring to freedom, not
+price. Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+<br /> <br />
+ To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+<br /> <br />
+ For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have. You must make sure that they, too, receive or can get the
+source code. And you must show them these terms so they know their
+rights.
+<br /> <br />
+ We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+<br /> <br />
+ Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software. If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+<br /> <br />
+ Finally, any free program is threatened constantly by software
+patents. We wish to avoid the danger that redistributors of a free
+program will individually obtain patent licenses, in effect making the
+program proprietary. To prevent this, we have made it clear that any
+patent must be licensed for everyone's free use or not licensed at all.
+<br /> <br />
+ The precise terms and conditions for copying, distribution and
+modification follow.
+<br /> <br />
+<b>TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION</b>
+<br /> <br />
+<b>0.</b>
+ This License applies to any program or other work which contains
+a notice placed by the copyright holder saying it may be distributed
+under the terms of this General Public License. The "Program", below,
+refers to any such program or work, and a "work based on the Program"
+means either the Program or any derivative work under copyright law:
+that is to say, a work containing the Program or a portion of it,
+either verbatim or with modifications and/or translated into another
+language. (Hereinafter, translation is included without limitation in
+the term "modification".) Each licensee is addressed as "you".
+<br /> <br />
+Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope. The act of
+running the Program is not restricted, and the output from the Program
+is covered only if its contents constitute a work based on the
+Program (independent of having been made by running the Program).
+Whether that is true depends on what the Program does.
+<br /> <br />
+<b>1.</b>
+ You may copy and distribute verbatim copies of the Program's
+source code as you receive it, in any medium, provided that you
+conspicuously and appropriately publish on each copy an appropriate
+copyright notice and disclaimer of warranty; keep intact all the
+notices that refer to this License and to the absence of any warranty;
+and give any other recipients of the Program a copy of this License
+along with the Program.
+<br /> <br />
+You may charge a fee for the physical act of transferring a copy, and
+you may at your option offer warranty protection in exchange for a fee.
+<br /> <br />
+<b>2.</b>
+ You may modify your copy or copies of the Program or any portion
+of it, thus forming a work based on the Program, and copy and
+distribute such modifications or work under the terms of Section 1
+above, provided that you also meet all of these conditions:
+<br /> <br />
+<b>a)</b>
+ You must cause the modified files to carry prominent notices
+ stating that you changed the files and the date of any change.
+<br /> <br />
+<b>b)</b>
+ You must cause any work that you distribute or publish, that in
+ whole or in part contains or is derived from the Program or any
+ part thereof, to be licensed as a whole at no charge to all third
+ parties under the terms of this License.
+<br /> <br />
+<b>c)</b>
+ If the modified program normally reads commands interactively
+ when run, you must cause it, when started running for such
+ interactive use in the most ordinary way, to print or display an
+ announcement including an appropriate copyright notice and a
+ notice that there is no warranty (or else, saying that you provide
+ a warranty) and that users may redistribute the program under
+ these conditions, and telling the user how to view a copy of this
+ License. (Exception: if the Program itself is interactive but
+ does not normally print such an announcement, your work based on
+ the Program is not required to print an announcement.)
+<br /> <br />
+These requirements apply to the modified work as a whole. If
+identifiable sections of that work are not derived from the Program,
+and can be reasonably considered independent and separate works in
+themselves, then this License, and its terms, do not apply to those
+sections when you distribute them as separate works. But when you
+distribute the same sections as part of a whole which is a work based
+on the Program, the distribution of the whole must be on the terms of
+this License, whose permissions for other licensees extend to the
+entire whole, and thus to each and every part regardless of who wrote it.
+<br /> <br />
+Thus, it is not the intent of this section to claim rights or contest
+your rights to work written entirely by you; rather, the intent is to
+exercise the right to control the distribution of derivative or
+collective works based on the Program.
+<br /> <br />
+In addition, mere aggregation of another work not based on the Program
+with the Program (or with a work based on the Program) on a volume of
+a storage or distribution medium does not bring the other work under
+the scope of this License.
+<br /> <br />
+<b>3.</b>
+ You may copy and distribute the Program (or a work based on it,
+under Section 2) in object code or executable form under the terms of
+Sections 1 and 2 above provided that you also do one of the following:
+<br /> <br />
+<b>a)</b>
+ Accompany it with the complete corresponding machine-readable
+ source code, which must be distributed under the terms of Sections
+ 1 and 2 above on a medium customarily used for software interchange; or,
+<br /> <br />
+<b>b)</b>
+ Accompany it with a written offer, valid for at least three
+ years, to give any third party, for a charge no more than your
+ cost of physically performing source distribution, a complete
+ machine-readable copy of the corresponding source code, to be
+ distributed under the terms of Sections 1 and 2 above on a medium
+ customarily used for software interchange; or,
+<br /> <br />
+<b>c)</b>
+ Accompany it with the information you received as to the offer
+ to distribute corresponding source code. (This alternative is
+ allowed only for noncommercial distribution and only if you
+ received the program in object code or executable form with such
+ an offer, in accord with Subsection b above.)
+<br /> <br />
+The source code for a work means the preferred form of the work for
+making modifications to it. For an executable work, complete source
+code means all the source code for all modules it contains, plus any
+associated interface definition files, plus the scripts used to
+control compilation and installation of the executable. However, as a
+special exception, the source code distributed need not include
+anything that is normally distributed (in either source or binary
+form) with the major components (compiler, kernel, and so on) of the
+operating system on which the executable runs, unless that component
+itself accompanies the executable.
+<br /> <br />
+If distribution of executable or object code is made by offering
+access to copy from a designated place, then offering equivalent
+access to copy the source code from the same place counts as
+distribution of the source code, even though third parties are not
+compelled to copy the source along with the object code.
+<br /> <br />
+<b>4.</b>
+ You may not copy, modify, sublicense, or distribute the Program
+except as expressly provided under this License. Any attempt
+otherwise to copy, modify, sublicense or distribute the Program is
+void, and will automatically terminate your rights under this License.
+However, parties who have received copies, or rights, from you under
+this License will not have their licenses terminated so long as such
+parties remain in full compliance.
+<br /> <br />
+<b>5.</b>
+ You are not required to accept this License, since you have not
+signed it. However, nothing else grants you permission to modify or
+distribute the Program or its derivative works. These actions are
+prohibited by law if you do not accept this License. Therefore, by
+modifying or distributing the Program (or any work based on the
+Program), you indicate your acceptance of this License to do so, and
+all its terms and conditions for copying, distributing or modifying
+the Program or works based on it.
+<br /> <br />
+<b>6.</b>
+ Each time you redistribute the Program (or any work based on the
+Program), the recipient automatically receives a license from the
+original licensor to copy, distribute or modify the Program subject to
+these terms and conditions. You may not impose any further
+restrictions on the recipients' exercise of the rights granted herein.
+You are not responsible for enforcing compliance by third parties to
+this License.
+<br /> <br />
+<b>7.</b>
+ If, as a consequence of a court judgment or allegation of patent
+infringement or for any other reason (not limited to patent issues),
+conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License. If you cannot
+distribute so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you
+may not distribute the Program at all. For example, if a patent
+license would not permit royalty-free redistribution of the Program by
+all those who receive copies directly or indirectly through you, then
+the only way you could satisfy both it and this License would be to
+refrain entirely from distribution of the Program.
+<br /> <br />
+If any portion of this section is held invalid or unenforceable under
+any particular circumstance, the balance of the section is intended to
+apply and the section as a whole is intended to apply in other
+circumstances.
+<br /> <br />
+It is not the purpose of this section to induce you to infringe any
+patents or other property right claims or to contest validity of any
+such claims; this section has the sole purpose of protecting the
+integrity of the free software distribution system, which is
+implemented by public license practices. Many people have made
+generous contributions to the wide range of software distributed
+through that system in reliance on consistent application of that
+system; it is up to the author/donor to decide if he or she is willing
+to distribute software through any other system and a licensee cannot
+impose that choice.
+<br /> <br />
+This section is intended to make thoroughly clear what is believed to
+be a consequence of the rest of this License.
+<br /> <br />
+<b>8.</b>
+ If the distribution and/or use of the Program is restricted in
+certain countries either by patents or by copyrighted interfaces, the
+original copyright holder who places the Program under this License
+may add an explicit geographical distribution limitation excluding
+those countries, so that distribution is permitted only in or among
+countries not thus excluded. In such case, this License incorporates
+the limitation as if written in the body of this License.
+<br /> <br />
+<b>9.</b>
+ The Free Software Foundation may publish revised and/or new versions
+of the General Public License from time to time. Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+<br /> <br />
+Each version is given a distinguishing version number. If the Program
+specifies a version number of this License which applies to it and "any
+later version", you have the option of following the terms and conditions
+either of that version or of any later version published by the Free
+Software Foundation. If the Program does not specify a version number of
+this License, you may choose any version ever published by the Free Software
+Foundation.
+<br /> <br />
+<b>10.</b>
+ If you wish to incorporate parts of the Program into other free
+programs whose distribution conditions are different, write to the author
+to ask for permission. For software which is copyrighted by the Free
+Software Foundation, write to the Free Software Foundation; we sometimes
+make exceptions for this. Our decision will be guided by the two goals
+of preserving the free status of all derivatives of our free software and
+of promoting the sharing and reuse of software generally.
+<br /> <br />
+<b>NO WARRANTY</b>
+<br /> <br />
+<b>11.</b>
+ BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
+FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
+OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
+PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
+OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
+TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
+PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
+REPAIR OR CORRECTION.
+<br /> <br />
+<b>12.</b>
+ IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
+REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
+INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
+OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
+TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
+YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
+PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+<br /> <br />
+<b>END OF TERMS AND CONDITIONS</b>
--- /dev/null
+<?php
+
+function Hits() {
+
+// $datafile has to be writable by http server user uid
+// else hits count will not be increased, only printed out
+
+ $datafile = "COUNTER";
+
+ if (Is_Writable($datafile)) {
+ $fp = FOpen($datafile, "r+");
+ $writable = "true";
+ }
+ else
+ if (Is_Readable($datafile)) $fp = FOpen($datafile,"r");
+ else return;
+
+ $hits = FGets($fp,255) + 1;
+ if(!$hits) $hits = 1;
+
+ if($writable) {
+ Rewind($fp);
+ FPuts($fp, $hits);
+ }
+
+ FClose($fp);
+ echo $hits." hits";
+}
+
+Hits();
+
+?>
--- /dev/null
+ <br />
+<b><big>Anonymous CVS access</big></b>
+<br /> <br />
+Anonymous CVS access is now available to SILC CVS repository. The
+repository includes everything related to SILC project; source codes,
+documentation and even these web pages. The CVS access is of course public
+but it is intended for developers. After you have checked out the SILC
+source tree you should read README.CVS file from the source tree or rest
+of this web page.
+<br /> <br />
+Also note that this is the closest to real time development you can get
+thus you cannot expect that the source tree would work or even compile.
+While it is our intention that the trunk would always at least compile
+there might be situations when it will not.
+
+<br /> <br />
+
+<b>Browsing the Source Tree</b>
+<br /> <br />
+If you want to browse the source tree using web browser before checking
+out the tree with CVS use following link:
+<br /> <br />
+<a href="http://cvs.silcnet.org/" class="normal">Web Access to CVS repository
+</a>
+<br /> <br />
+Note that this is not real-time access to the CVS repository. It is
+updated once a day. If you want real-time access then checkout the CVS
+repository.
+
+<br /> <br />
+
+<b>Howto Checkout The Source Tree</b>
+<br /> <br />
+The repository can be checked out by using anonymous pserver with CVS.
+<br /> <br />
+For those who are using sh/ksh/bash/zsh the check out is done as follows:
+<br /> <br />
+<tt class="blue">
+export CVSROOT=:pserver:<?php printf("%s@%s:%s", $CVS_User, $CVS_Site, $CVS_Root); ?>
+<br /> <br />
+cvs login<br />
+cvs co silc<br />
+cvs logout<br />
+</tt>
+
+<br /> <br />
+For those who are using csh/tcsh the check out is done as follows:
+<br /> <br />
+<tt class="blue">
+setenv CVSROOT :pserver:<?php printf("%s@%s:%s", $CVS_User, $CVS_Site, $CVS_Root); ?>
+<br /> <br />
+cvs login<br />
+cvs co silc<br />
+cvs logout<br />
+</tt>
+<br /> <br />
+If you don't want to set $CVSROOT environment variable you can set the
+path to the cvs as command line option:
+<br /> <br />
+<tt class="blue">
+cvs -d:pserver:<?php printf("%s@%s:%s", $CVS_User, $CVS_Site, $CVS_Root); ?> login
+<br />
+cvs -d:pserver:<?php printf("%s@%s:%s", $CVS_User, $CVS_Site, $CVS_Root); ?> co silc
+<br />
+cvs -d:pserver:<?php printf("%s@%s:%s", $CVS_User, $CVS_Site, $CVS_Root); ?> logout
+</tt>
+<br /> <br />
+Whatever method you will decide to use, after you have done cvs login you will
+be prompted for password:
+<br /> <br />
+<b>CVS password: </b>silc
+<br /> <br />
+Type the password "silc" and press <ENTER>
+<br /> <br />
+The actual SILC source tree is checked out using the cvs co silc command,
+described above. This command will fetch the source tree and save it into
+directory named silc. SILC CVS repository currently does not have any
+branches thus this will check out the trunk. The size of the trunk is
+currently about 13 MB but will grow in the future.
+
+<br /> <br />
+
+<b>What SILC Source Tree Includes</b>
+<br /> <br />
+SILC Source tree includes a lot more stuff that appears in public
+distribution. The source tree includes, for example, internal scripts,
+configuration files, SILC webpages etc. These never appear on a public
+distribution.
+<br /> <br />
+Following directories currently exist in SILC source tree.
+<br /> <br />
+<tt class="blue">
+doc/
+<br /> <br />
+ Includes all the SILC documentation. Few parts of the documentation<br />
+ are generated when distribution is generated. The automatically<br />
+ generated files should never be commited to CVS.<br />
+<br /> <br />
+includes/
+<br /> <br />
+ Includes SILC include files.
+<br /> <br />
+lib/
+<br /> <br />
+ Includes SILC libraries. There are maybe libraries in the CVS which<br />
+ are not inclduded in public distribution.<br />
+<br /> <br />
+public_html/
+<br /> <br />
+ Includes the official SILC web pages and everything related to them.<br />
+ This directory will never appear in public distribution.<br />
+<br /> <br />
+silc/
+<br /> <br />
+ Includes SILC client. There can be some extra files that will<br />
+ never appear in public distribution, such as configuration files.<br />
+<br /> <br />
+silcd/
+<br /> <br />
+ Includes SILC server. There can be some extra files that will<br />
+ never appear in public distribution, such as configuration files.<br />
+</tt>
+
+<br /> <br />
+
+<b>Howto Compile SILC Source Tree</b>
+<br /> <br />
+After checkout from CVS the SILC source tree needs to be prepared for
+configuration and compilation. To compile the source tree, type:
+<br /> <br />
+<tt class="blue">
+./prepare<br />
+./configure --enable-debug<br />
+make<br /> <br />
+note: on non-GNU/Linux operating systems GNU make (gmake) is prefered
+</tt>
+<br /> <br />
+
+The ./prepare script is included in the source tree and it will never
+appears in public distribution. The script prepares the source tree
+by creating configuration scripts and Makefiles. The prepare must be
+run every time you made any changes to configuration scripts (however,
+making changes to Makefile.am's does not require running ./prepare).
+<br /> <br />
+As a developer you should read the ./configure script's help by typing
+./configure --help and study all of its different options. Also you
+should configure the script with --enable-debug option as it compiles
+SILC with -g (debugging) option and it enables the SILC_LOG_DEBUG*
+scripts. Warning is due here: The debugging produced by both cilent
+and server is very huge, thus it is common to test the programs as
+follows:
+<br /> <br />
+<tt class="blue">
+./silc -d -f configfile 2>log<br />
+./silcd -d -f configfile 2>log
+</tt>
+
+<br /> <br />
+
+<b>How to clean SILC Source Tree</b>
+<br /> <br />
+To entirely clear the source tree to the state after it was checked out
+from CVS, type:
+<br /> <br />
+<tt class="blue">
+./prepare-clean
+</tt>
+<br /> <br />
+
+This calls `make distclean' plus removes automatically generated files
+by hand. It also removes *.log files. However, it will not remove any
+other files you might have created.
+
+<br /> <br />
+
+<b>Makefiles and configuration files</b>
+<br /> <br />
+Developers should never directly write a Makefile. All Makefiles are
+always automatically generated by ./prepare and later by ./configure
+scripts. Instead, developers have to write Makefile.am files. There
+are plenty of examples what they should look like. If you changed
+Makefile.am during development you do not need to run ./prepare, just
+run normal make.
+<br /> <br />
+Configuration files are the files that ./prepare automatically generates
+and which will be included into public distribution. ./prepare creates
+for example the ./configure script that is not commited to the CVS.
+`configure.in' is the file that developers have to edit to change ./configure
--- /dev/null
+ <br />
+<b><big>SILC Documentation</big></b>
+<br /> <br />
+
+README file from packages: <a href="docs/README" class="normal">README</a>
+<br />
+Coding Style in SILC source tree: <a href="docs/CodingStyle" class="normal">CodingStyle</a>
+<br /> <br />
+Software manual: <i>Coming later</i>
+
+<br /> <br /> <br />
+
+<b>Installation Instructions</b>
+<br /> <br />
+General installation instructions are available in all SILC distributions
+in the INSTALL file.
+<br /> <br />
+<a href="?page=install" class="normal">Installation instructions</a>
+
+<br /> <br /> <br />
+
+<b><big>Technical Documentation</big></b>
+<br /> <br />
+
+<b>SILC Toolkit Reference Manual</b>
+<br /> <br />
+SILC Toolkit Reference Manual includes documentation for the SILC Toolkit
+package. It includes interface references to all interfaces found in
+various SILC libraries. The reference manual is automatically generated
+from the source code. Note that this version is preliminary and does not
+include references to all interfaces.
+<br /> <br />
+<a href="docs/toolkit/" class="normal">HTML version</a>,
+<a href="docs/toolkit.html.tar.gz" class="normal">html.tar.gz</a>
+
+<br /> <br /> <br />
+
+<b><big>SILC Protocol Documentation</big></b>
+<br /> <br />
+
+<b>SILC Protocol White Paper</b>
+<br /> <br />
+SILC Protocol White Paper gives short but deep enough introduction to the
+SILC Protocol. Note that this is for those who would like to know how the
+protocol works. For more detailed description of the protocol we suggest
+reading the protocol specifications.
+<br /> <br />
+
+<a href="?page=whitepaper" class="normal">HTML version</a>,
+<a href="docs/silc_protocol.pdf.gz" class="normal">gzipped PDF</a>,
+<a href="docs/silc_protocol.ps.gz" class="normal">gzipped PostScript</a>
+
+<br /> <br /> <br />
+
+<b>SILC Protocol Internet Drafts</b>
+<br /> <br />
+SILC Protocol is documented and four Internet Drafts exist. These
+Internet Drafts are also available from
+<a href="http://www.ietf.org/" class="normal">IETF</a>.
+<br /> <br />
+<b>NOTE Mon Nov 5 18:53:56 EET 2001:</b> New versions of the protocol
+specifications are almost ready for submission to the IETF. You can
+preview the upcoming versions <a href="docs/drafts/">here</a>.
+<br /> <br />
+
+<b>Secure Internet Live Conferencing (SILC), Protocol Specification</b>
+<br /> <br />
+Abstract
+<br /> <br />
+ This memo describes a Secure Internet Live Conferencing (SILC)
+ protocol which provides secure conferencing services over insecure
+ network channel. SILC is IRC [IRC] like protocol, however, it is
+ not equivalent to IRC and does not support IRC. Strong cryptographic
+ methods are used to protect SILC packets inside the SILC network.
+ Three other Internet Drafts relates very closely to this memo;
+ SILC Packet Protocol [SILC2], SILC Key Exchange and Authentication
+ Protocols [SILC3] and SILC Commands [SILC4].
+<br /> <br />
+<a href="docs/draft-riikonen-silc-spec-03.txt" class="normal">
+draft-riikonen-silc-spec-03.txt</a>
+<br /> <br /> <br />
+
+<b>SILC Packet Protocol</b>
+<br /> <br />
+Abstract
+<br /> <br />
+ This memo describes a Packet Protocol used in the Secure Internet Live
+ Conferencing (SILC) protocol, specified in the Secure Internet Live
+ Conferencing, Protocol Specification Internet Draft [SILC1]. This
+ protocol describes the packet types and packet payloads which defines
+ the contents of the packets. It provides secure binary packet protocol
+ that assures that the content of the packets is secured and authenticated.
+<br /> <br />
+<a href="docs/draft-riikonen-silc-pp-03.txt" class="normal">
+draft-riikonen-silc-pp-03.txt</a>
+<br /> <br /> <br />
+
+<b>SILC Key Exchange and Authentication Protocols</b>
+<br /> <br />
+Abstract
+<br /> <br />
+ This memo describes two protocols used in the Secure Internet Live
+ Conferencing (SILC) protocol, specified in the Secure Internet Live
+ Conferencing, Protocol Specification internet-draft [SILC1]. The
+ SILC Key Exchange (SKE) protocol provides secure key exchange between
+ two parties resulting into shared secret key material. The protocol
+ is based on Diffie-Hellman key exchange algorithm and its functionality
+ is derived from several key exchange protocols. SKE uses best parts
+ of the SSH2 Key Exchange protocol, Station-To-Station (STS) protocol
+ and the OAKLEY Key Determination protocol [OAKLEY].
+<br /> <br />
+ The SILC Connection Authentication protocol provides user level
+ authentication used when creating connections in SILC network. The
+ protocol is transparent to the authentication data which means that it
+ can be used to authenticate the user with, for example, passphrase
+ (pre-shared-secret) or public key (and certificate).
+<br /> <br />
+<a href="docs/draft-riikonen-silc-ke-auth-03.txt" class="normal">
+draft-riikonen-silc-ke-auth-03.txt</a>
+<br /> <br /> <br />
+
+<b>SILC Commands</b>
+<br /> <br />
+Abstract
+<br /> <br />
+ This memo describes the commands used in the Secure Internet Live
+ Conferencing (SILC) protocol, specified in the Secure Internet Live
+ Conferencing, Protocol Specification Internet Draft [SILC1]. The
+ SILC Commands are very important part of the SILC protocol. Usually
+ the commands are used by SILC clients to manage the SILC session, but
+ also SILC servers may use the commands. This memo specifies detailed
+ command messages and command reply messages.
+<br /> <br />
+<a href="docs/draft-riikonen-silc-commands-01.txt" class="normal">
+draft-riikonen-silc-commands-01.txt</a>
--- /dev/null
+ <br />
+<b><big>Download SILC</big></b>
+<br /> <br />
+The SILC is distributed in three different packages; the SILC Client, the
+SILC Server and the SILC Toolkit. The SILC Client is intended for end
+users, the SILC Server for system administrators and the SILC Toolkit for
+developers.
+<br /> <br />
+Use a <a href="?page=mirrors" class="normal">mirror</a> near you for downloads.
+<br /> <br />
+
+<b>SILC Client <?php echo $Latest_Client; ?></b>
+<br /> <br />
+The SILC Client package is inteded for end users who need only the SILC
+client. The package includes the new Irssi-SILC client.
+<br /> <br />
+Sources HTTP:
+<a href="download/silc-client-<?php echo $Latest_Client; ?>.tar.gz" class="normal">
+tar.gz</a> (<?php echo
+div(FileSize("download/silc-client-".$Latest_Client.".tar.gz"),1024); ?> kB),
+<a href="download/silc-client-<?php echo $Latest_Client; ?>.tar.bz2" class="normal">
+tar.bz2</a> (<?php echo
+div(FileSize("download/silc-client-".$Latest_Client.".tar.bz2"),1024); ?> kB)
+<br />
+
+Sources FTP: <a href="ftp://<?php echo $FTP_Site.$FTP_Root ?>/"
+class="normal">tar.gz and tar.bz2</a>
+<br />
+
+Binaries HTTP:
+<a href="download/silc-client-<?php echo $Latest_RPM_Client; ?>.i386.rpm"
+class="normal">RPM</a> (<?php echo
+div(FileSize("download/silc-client-".$Latest_RPM_Client.".i386.rpm"),1024);
+?> kB)
+, <a href="download/silc-<?php echo $Latest_Windows_Client; ?>.exe.zip"
+class="normal">Cygwin</a> (<?php
+echo div(FileSize("download/silc-".$Latest_Windows_Client.".exe.zip"),1024); ?> kB)
+, <a href="download/SILCclie-<?php echo $Latest_Solaris_Client; ?>-sol8-sparc-local.gz"
+class="normal">Solaris 8/SPARC</a> (<?php
+echo div(FileSize("download/SILCclie-".$Latest_Solaris_Client."-sol8-sparc-local.gz"),1024); ?> kB)
+
+<br />
+
+Binaries FTP: <a href="ftp://<?php echo $FTP_Site.$FTP_Root ?>/rpm/"
+class="normal">RPM</a>, <a href="ftp://<?php echo $FTP_Site.$FTP_Root ?>/solaris/"
+class="normal">Solaris 8/SPARC</a>
+<br /> <br />
+
+
+<b>SILC Server <?php echo $Latest_Server; ?></b>
+<br /> <br />
+The SILC Server package is intended for system administrators who wants to
+setup their own SILC server or router. The package includes only the
+server and not the client. People who is running SILC servers and are
+interested to get the server linked to the new router on silc.silcnet.org
+contact <a href="mailto:priikone at silcnet.org" class="normal">me</a> now.
+<br /> <br />
+Sources HTTP:
+<a href="download/silc-server-<?php echo $Latest_Server; ?>.tar.gz" class="normal">
+tar.gz</a> (<?php echo
+div(FileSize("download/silc-server-".$Latest_Server.".tar.gz"),1024); ?> kB),
+<a href="download/silc-server-<?php echo $Latest_Server; ?>.tar.bz2" class="normal">
+tar.bz2</a> (<?php echo
+div(FileSize("download/silc-server-".$Latest_Server.".tar.bz2"),1024); ?> kB)
+<br />
+Sources FTP: <a href="ftp://<?php echo $FTP_Site.$FTP_Root ?>/" class="normal">tar.gz and tar.bz2</a>
+<br /> <br />
+
+<b>SILC Toolkit <?php echo $Latest_Toolkit; ?></b>
+<br /> <br />
+The SILC Toolkit package is intended for developers and programmers who
+would like to create their own SILC applications or help in the
+development of the SILC protocol. The Win32 binary package available
+includes the entire Toolkit with sources and compiled DLLs.
+<br /> <br />
+Sources HTTP:
+<a href="download/silc-toolkit-<?php echo $Latest_Toolkit; ?>.tar.gz" class="normal">
+tar.gz</a> (<?php echo
+div(FileSize("download/silc-toolkit-".$Latest_Toolkit.".tar.gz"),1024); ?> kB),
+<a href="download/silc-toolkit-<?php echo $Latest_Toolkit; ?>.tar.bz2" class="normal">
+tar.bz2</a> (<?php echo
+div(FileSize("download/silc-toolkit-".$Latest_Toolkit.".tar.bz2"),1024); ?> kB)
+<br />
+Sources FTP: <a href="ftp://<?php echo $FTP_Site.$FTP_Root ?>/" class="normal">tar.gz and tar.bz2</a>
+<br />
+Binaries HTTP:<a href="download/silc-toolkit-<?php echo $Latest_Toolkit_Win32 ?>.zip" class="normal">
+Win32</a> (<?php echo
+div(FileSize("download/silc-toolkit-".$Latest_Toolkit_Win32.".zip"),1024); ?> kB)
+<br /> <br />
+
+<b>CVS Snapshots</b>
+<br /> <br />
+Daily CVS snapshots are available. These are generated 22:00 GMT every
+night. Read the <a href="?page=cvs" class="normal">CVS page</a> for more
+information.
+<br /> <br />
+HTTP: <a href="download/silc.tar.gz" class="normal">CVS Snapshot</a>
+<br /> <br />
+<b>Portability</b>
+<br /> <br />
+The SILC has been reported to work on, at least:
+<br /> <br />
+ - <a href="http://www.linux.org/" class="normal">GNU/Linux</a><br />
+ - <a href="http://www.freebsd.org/" class="normal">FreeBSD</a><br />
+ - <a href="http://www.netbsd.org/" class="normal">NetBSD</a><br />
+ - <a href="http://www.openbsd.org/" class="normal">OpenBSD</a><br />
+ - <a href="http://www.hp.com/products1/unix/operating/" class="normal">HP-UX</a><br />
+ - <a href="http://www.sun.com/software/solaris/" class="normal">Solaris</a><br />
+ - <a href="http://www.sgi.com/developers/technology/irix.html" class="normal">IRIX</a><br />
+ - <a href="http://www.microsoft.com/windows/" class="normal">Windows</a><br />
+ - <a href="http://sources.redhat.com/cygwin/" class="normal">Cygwin</a> & <a href="http://www.mingw.org/" class="normal">MinGW</a>
--- /dev/null
+ <br />
+<b><big>Frequently Asked Questions</big></b>
+<br /> <br />
+<a href="#f1_0" class="normal">1. General Questions</a><br />
+ <a href="#f1_10" class="normal">1.1 What is SILC?</a><br />
+ <a href="#f1_20" class="normal">1.2 When was SILC Project started?</a><br />
+ <a href="#f1_30" class="normal">1.3 Why SILC in the first place?</a><br />
+ <a href="#f1_40" class="normal">1.4 What license covers the SILC release?</a><br />
+ <a href="#f1_50" class="normal">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_60" class="normal">1.7 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>
+<br /> <br />
+<a href="#f2_0" class="normal">2. Protocol Questions</a><br />
+ <a href="#f2_10" class="normal">2.1 What is the status of SILC protocol in the IETF?</a><br />
+ <a href="#f2_20" class="normal">2.2 How much the SILC protocol is based on IRC?</a><br />
+ <a href="#f2_30" class="normal">2.3 Why use SILC? Why not IRC with SSL?</a><br />
+ <a href="#f2_40" class="normal">2.4 Can I talk from SILC network to IRC network?</a><br />
+ <a href="#f2_45" class="normal">2.5 Does SILC support file transfer?</a><br />
+ <a href="#f2_47" class="normal">2.6 I am behind a firewall, can I use SILC?</a><br />
+ <a href="#f2_50" class="normal">2.7 How secure SILC really is?</a><br />
+ <a href="#f2_60" class="normal">2.8 Does SILC support instant messaging?</a><br />
+ <a href="#f2_70" class="normal">2.9 Why SILC does not have LINKS command like in IRC?</a><br />
+ <a href="#f2_80" class="normal">2.10 Why SILC does not have STATS command like in IRC?</a><br />
+ <a href="#f2_90" class="normal">2.11 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>
+<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 />
+ <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">4.4 Why server says permission denied to write to a log file?</a><br />
+ <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 /> <br />
+<a href="#f5_0" class="normal">5. Toolkit Questions</a><br />
+ <a href="#f5_10" class="normal">5.1 What is SILC Toolkit?</a><br />
+ <a href="#f5_20" class="normal">5.2 Is the SILC Toolkit Reference Manual Available?</a><br />
+ <a href="#f5_30" class="normal">5.3 How do I compile the Toolkit on Unix</a><br />
+ <a href="#f5_40" class="normal">5.4 How do I compile the Toolkit on Win32</a><br />
+<br /> <br />
+
+<a name="f1_0"></a>
+<b>1. General Questions</b><br /> <br />
+
+<a name="f1_10"></a>
+<samp class="blue">Q: What is SILC?</samp><br />
+A: SILC (Secure Internet Live Conferencing) is a protocol which provides
+secure conferencing services in the Internet over insecure channel. SILC
+is IRC like 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.
+<br /> <br />
+Biggest differences are that SILC is secure what IRC is not in any way.
+The network model is also entirely different compared to IRC.
+<br /> <br />
+
+<a name="f1_20"></a>
+<samp class="blue">Q: When was SILC Project started?</samp><br />
+A: The SILC development started in 1996 and early 1997. But, for various
+reasons it suspended many times until it finally got some wind under its
+wings in 1999. First public release was in summer 2000.
+<br /> <br />
+
+<a name="f1_30"></a>
+<samp class="blue">Q: Why SILC in the first place?</samp><br />
+A: Simply for fun, nothing more. And actually for need back in the days
+when it was started. When SILC was first developed there really did not
+exist anything like this. SILC has been very interesting and educational
+project.
+<br /> <br />
+
+<a name="f1_40"></a>
+<samp class="blue">Q: What license covers the SILC release?</samp><br />
+A: The SILC software developed here at silcnet.org, the SILC Client, the
+SILC Server and the SILC Toolkit are covered by the GNU General Public
+License.
+<br /> <br />
+
+<a name="f1_50"></a>
+<samp class="blue">Q: Why SILC? Why not IRC3?</samp><br />
+A: Question that is justified no doubt of that. SILC was not started to
+become a replacement for IRC. SILC was something that didn't exist in 1996
+or even today except that SILC is now released. However, I did check out
+the IRC3 project in 1997 when I started coding and planning the SILC protocol.
+<br /> <br />
+But, IRC3 is problematic. Why? Because it still doesn't exist. The
+project is almost at the same spot where it was in 1997 when I checked it
+out. And it was old project back then as well. That's the problem of IRC3
+project. The same almost happened to SILC as well as I wasn't making real
+progress over the years. I talked to the original author of IRC, Jarkko
+Oikarinen, in 1997 and he directed me to the IRC3 project, although he
+said that IRC3 is a lot of talking and not that much of anything else. I
+am not trying to put down the IRC3 project but its problem is that no one
+in the project is able to make a decision what is the best way to go about
+making the IRC3 and I wasn't going to be part of that. The fact is that
+if I would've gone to IRC3 project, nor IRC3 or SILC would exist today. I
+think IRC3 could be something really great if they just would get their
+act together and start coding the thing.
+<br /> <br />
+
+<a name="f1_55"></a>
+<samp class="blue">Q: What platforms SILC supports?</samp><br />
+A: The SILC Client is available on various Unix systems and is reported to
+work under cygwin on Windows. The SILC Server also works on various Unix
+systems. However, the server has not been tested under cygwin as far as we
+know. The SILC Toolkit is distributed for all platforms, Unix, Cygwin
+and native Windows.
+<br /> <br />
+
+<a name="f1_60"></a>
+<samp class="blue">Q: Where can I find more information?</samp><br />
+A: For more technical information we suggest reading the SILC Protocol
+specifications. You might also want to take a look at the <a
+href="?page=docs" class="normal">documentation </a> page on the web page.
+<br /> <br />
+
+<a name="f1_70"></a>
+<samp class="blue">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
+SILC development mailing list.
+<br /> <br />
+
+<a name="f2_0"></a><br />
+<b>2. Protocol Questions</b><br /> <br />
+
+<a name="f2_10"></a>
+<samp class="blue">Q: What is the status of SILC protocol in the IETF?</samp><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.
+<br /> <br />
+
+<a name="f2_20"></a>
+<samp class="blue">Q: How much SILC Protocol is based on IRC?</samp><br />
+A: SILC is not based on IRC. The 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 toppology is
+different (hopefully 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 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.
+<br /> <br />
+
+<a name="f2_30"></a>
+<samp class="blue">Q: Why use SILC? Why not IRC with SSL?</samp><br />
+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.
+<br /> <br />
+
+<a name="f2_40"></a>
+<samp class="blue">Q: Can I talk from SILC network to IRC network?</samp><br />
+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 two networks would
+technically be possible but from security point of view strongly not
+recommended. We have no plans for developing such a gateway.
+<br /> <br />
+
+<a name="f2_45"></a>
+<samp class="blue">Q: Does SILC support file transfer?</samp><br />
+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.
+<br /> <br />
+
+<a name="f2_47"></a>
+<samp class="blue">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
+SOCKS support which will proxy your SILC session through the firewall.
+<br /> <br />
+
+<a name="f2_50"></a>
+<samp class="blue">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.
+<br /> <br />
+But to give you some parameters of security SILC uses the most secure
+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)
+and Diffie-Hellman algorithms. Key lengths for ciphers are initially set
+to 256. For public key algorithms the starting key length is 1024 bits.
+<br /> <br />
+But the best answer for this question is that SILC is as secure as its
+weakest link. SILC is open and the protocol is open and in public thus
+open for security analysis.
+<br /> <br />
+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
+packets are ineffective (because of encryption and integrity checks).<br />
+ - 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.
+<br /> <br />
+
+<a name="f2_60"></a>
+<samp class="blue">Q: Does SILC support instant messaing?</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.
+<br /> <br />
+
+<a name="f2_70"></a>
+<samp class="blue">Q: Why SILC does not have LINKS command like in
+IRC?</samp><br />
+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.
+<br /> <br />
+
+<a name="f2_80"></a>
+<samp class="blue">Q: Why SILC does not have STATS command like in
+IRC?</samp><br />
+A: This too was considered as information that the protocol should not
+address. We feel that server implementations will need to implement some
+sort of adminstrative plugin, or module which provides various means of
+accessing statistical and other information in the server. And, we do
+consider this implementation issue, not protocol design issue.
+<br /> <br />
+
+<a name="f2_90"></a>
+<samp class="blue">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.
+<br /> <br />
+
+
+<a name="f3_0"></a><br />
+<b>3. Client Questions</b><br /> <br />
+
+<a name="f3_10"></a>
+<samp class="blue">Q: Where can I find SILC clients?</samp><br />
+A: The SILC client is available for free download from the silcnet.org web
+page. Some people have also mentioned words Java and Perl when talking
+about SILC clients. Nothing has appeared yet, though.
+<br /> <br />
+
+<a name="f3_20"></a>
+<samp class="blue">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.
+<br /> <br />
+
+<a name="f4_0"></a><br />
+<b>4. Server Questions</b><br /> <br />
+
+<a name="f4_10"></a>
+<samp class="blue">Q: Where can I find SILC servers?</samp><br />
+A: The SILC server is available for free download from the silcnet.org
+web page. We are not aware of any other SILC server implementations, so far.
+<br /> <br />
+
+<a name="f4_20"></a>
+<samp class="blue">Q: Can I run 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
+router.
+<br /> <br />
+
+<a name="f4_30"></a>
+<samp class="blue">Q: What is the difference between SILC
+server and SILC router?</samp><br />
+A: The topology of the SILC network includes SILC routers and the SILC
+servers (and SILC clients of course). Normal SILC server does not have
+direct connections with other SILC servers. They connect directly to the
+SILC router. SILC Routers may have several server connections and they
+may connect to several SILC routers. The SILC routers are the servers in
+the network that know everything about everything. The SILC servers know
+only local information and query global information from the router when
+necessary.
+<br /> <br />
+If you are running SILC server you want to run it as router only if you
+want to have server connections in it and are prepared to accept server
+connections. You also need to get the router connected to some other
+router to be able to join the SILC network. You may run the server as
+normal SILC server if you do not want to accept other server connections
+or cannot run it as router.
+<br /> <br />
+
+<a name="f4_40"></a>
+<samp class="blue">Q: Why server says permission denied to write to a
+log file?</samp><br />
+A: The owner of the log files must be same user that the server is run
+under, by default it is user `nobody'. Just change the permissions and
+try again.
+<br /> <br />
+
+<a name="f4_50"></a>
+<samp class="blue">Q: When I connect to my server it says "server does
+not support one of your proposed ciphers", what is wrong?</samp><br />
+A: Most likely the ciphers and others has not been compiled as SIMs
+(modules) and they are configured as modules in the silcd.conf. If they
+are not compiled as modules remove the module paths from the ciphers and
+hash functions from the silcd.conf, so that the server use the builtin
+ciphers. Then try connecting to the server again. It is also possible
+that the client IS proposing some ciphers that your server does not support.
+<br /> <br />
+
+
+<a name="f5_0"></a><br />
+<b>5. Toolkit Questions</b><br /> <br />
+
+<a name="f5_10"></a>
+<samp class="blue">Q: What is SILC Toolkit?</samp><br />
+A: SILC Toolkit is a package intended for software developers who would
+like to develope their own SILC based applications or help in the
+development of the SILC. The Toolkit includes SILC Protocol Core library,
+SILC Crypto library, SILC Key Exchange (SKE) library, SILC Math
+library, SILC Modules (SIM) library, SILC Utility library, SILC Client
+library and few other libraries.
+<br /> <br />
+
+<a name="f5_20"></a>
+<samp class="blue">Q: Is the SILC Toolkit Reference Manual Available?</samp><br />
+A: Yes, partially completed reference manual is available in the Toolkit
+releases as HTML package and they are available from the silcnet.org
+website as well at the <a href="?page=docs" class="normal">documentation </a> page.
+<br /> <br />
+
+<a name="f5_30"></a>
+<samp class="blue">Q: How do I compile the Toolkit on Unix?</samp><br />
+A: You should read the INSTALL file from the package and follow its
+instructions. The compilation on Unix is as simple as compiling any other
+SILC package. Give, `./configure' command and then `make' command.
+<br /> <br />
+
+<a name="f5_40"></a>
+<samp class="blue">Q: How do I compile the Toolkit on Win32?</samp><br />
+A: We have prepared instructions to compile the Toolkit on Win32 in the
+Toolkit package. Please, read the README.WIN32 file from the package for
+detailed instructions how to compile the Toolkit for Cygwin, MinGW and
+native Win32 systems. We have also prepared ready MSVC++ Workspace files
+in the win32/ directory in the package that will compile automatically
+the Toolkit.
+<br /> <br />
--- /dev/null
+ <br />
+<b><big>Features</big></b>
+<br /> <br />
+- Normal conferencing services such as private messages, channels,
+channel messages, etc. All traffic is secured and authenticated.
+
+<br /> <br />
+- No unique nicknames. There can be 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. The maximum length of the nickname
+is 128 characters. The maximum length of the channel name is 256 characters.
+
+<br /> <br />
+- Channels can have channel operators and a channel founder which is the
+client who created the channel. Channel founder privileges supersedes the
+channel operator privileges. Also, channel founder privileges may be
+regained even if the founder leaves the channel. The requirement for this
+is that the client is connected to the same server it was originally
+connected. The channel founder cannot be removed (kicked) from the
+channel using force.
+
+<br /> <br />
+- Channel messages are protected by channel key, generated by the server.
+The key is re-generated once in an hour. It is possible to set a private
+key for the channel so that even the servers does not know the key.
+Actually, it is possible to set several private keys so that only
+specific users on the channel may decrypt some specific messages. Adding
+the private key significantly increases the security as nobody else but
+the users on the channel know the key.
+
+<br /> <br />
+- Private messages are protected using session keys, generated when
+connecting to the server. This means that the private messages are
+decrypted and re-encrypted enroute to the true receiver of the message.
+However, it is possible to set a private key between two clients and
+protect the private messages with that key. In this case no server
+enroute can decrypt the message since they don't have the key. The SILC
+protocol provides an automatic key negotiation between two clients using
+the SKE protocol. This makes it very easy to negotiate a shared secret
+key with another client in the network.
+
+<br /> <br />
+- All the other traffic, like commands between client and the server are
+protected using the session keys. Session keys are re-generated once in
+an hour. The re-key may be done with or without the PFS (Perfect Forward
+Secrecy).
+
+<br /> <br />
+- Secure key exchange and authentication protocol. SILC Key Exchange
+(SKE) protocol provides key material used in the SILC sessions in secure
+manner. The protocol is immune for example to man-in-the-middle attacks
+and is based on the Diffie-Hellman key exchange algorithm. 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.
+
+<br /> <br />
+- Supports secure file transferring between clients in the network. SILC
+use the SFTP as the main file transfer protocol.
+
+<br /> <br />
+- All traffic is encrypted and authenticated using the best cryptographic
+algorithms out there. Cipher keys are, by default, 256 bits in length and
+public keys, by default, 1024 bits in length.
+
+<br /> <br />
+- Supports the following ciphers: AES(Rijndael), Twofish, Blowfish, Mars,
+Cast-256, RC5 and RC6. Supports the following hash functions: MD5 and
+SHA1. Supports the following HMACs: hmac-sha1-96, hmac-md5-96,
+hmac-sha1 and hmac-md5. Supports the PKCS #1 (RSA) for public key
+cryptography.
+
+<br /> <br />
+- Supports data compression with GZIP to improve performance.
+
+<br /> <br />
+- Supports SOCKS4 and SOCKS5 firewall traversal protocols.
+
+<br /> <br />
+- 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.
+
+<br /> <br />
+- SILC client can be installed and used without root privileges.
+
+<br /> <br />
+- SILC client can be configured by system wide configuration files but
+with user specific configuration files as well.
--- /dev/null
+ <br />
+<b><big>History</big></b>
+<br /> <br />
+SILC was released in the summer 2000 to the public, but the idea and the
+protocol itself is quite old. The SILC was designed by Pekka Riikonen in
+the year 1996 and first lines of codes were written in the early 1997. The
+SILC has been rewritten three times since its very first version in 1997.
+The first version included SILC client, very preliminary SILC server, RSA
+implementation and 3DES implementation. The server actually was not
+usable but the client looked pretty much the same as the first client
+released in the summer 2000. The first version had also random number
+generator which were based on the SSH's random number generator. The
+current RNG is based on the first RNG but has been rewritten twice since
+the first version.
+<br /> <br />
+The development of SILC was suspended in 1997 when Pekka got busy at
+school and in work. The pause laster several months. The development
+resumed in 1998 when Juha Räsänen and Pekka implemented the ElGamal
+algorithm. However, for the same reasons as previously the development
+stopped again, and was resumed again later in 1998 by doing rewrite of
+ther SILC in C++. This was obviously a mistake but at that time it seemed
+like a good idea. Again, in the winter 1999 the development suspended when
+Pekka got busy writing his thesis and was forced to stop the development.
+<br /> <br />
+Later, in 1999, it was decided that this time SILC will be rewritten from
+scratch in the right way. C++ was obviously a bad choice so plain C
+language was selected again. The protocol itself faced some rework by
+redesigning some core parts of the protocol. The protocol was also fully
+documented and the protocol specifications were submitted to the IETF.
+The result of this development effort is the release now in public. Since
+the release in the summer 2000 several other people have contributed to
+the project as well. And, the development continues.
--- /dev/null
+ <br />
+<tt class="black">
+<?php
+
+if (Is_Readable("docs/INSTALL")) {
+ $fp = FOpen("docs/INSTALL", "r");
+
+ while($line = FGets($fp, 255)) {
+ $newline = Ereg_Replace("^[ ]{2,4}"," ",$line);
+ $line = Ereg_Replace("^([\t]|[ ][\t])"," ",$newline);
+ printf("%s", nl2br($line));
+ }
+
+ FClose($fp);
+ }
+?>
+</tt>
--- /dev/null
+ <br />
+<b><big>Public SILC Mailing Lists</big></b>
+<br /> <br />
+There is currently one mailing list available. The mailing list is the
+main SILC development mailing list. It is currently quite low volume so
+you can safely subscribe on to it. To send email to the list the email
+must be destined to: <a href="mailto:silc-devel at
+lists.sourceforge.net" class="normal">silc-devel@lists.sourceforge.net</a> address.
+<br /> <br />
+To see prior postings to the list, browse the <a href="http://www.geocrawler.com/redir-sf.php3?list=silc-devel" class="normal">silc-devel archives</a>.
+<br /> <br />
+
+<b>Subscribing to silc-devel</b>
+<br /> <br />
+To subscribe to silc-devel mailing list send email to the following
+address:
+<br />
+<a href="mailto:silc-devel-request@lists.sourceforge.net" class="normal">
+silc-devel-request@lists.sourceforge.net</a>, and add the following
+line to the body of the email.
+<br /> <br />
+subscribe yourpassword
+<br /> <br />
+You must set a password that you can use to modify your settings. It must
+also be provided if you will unsubscribe from the list. The email address
+you are using to send the email will be added to the mailing list. You
+will receive a confirmation email to which you must reply in order to
+complete the subscribing process.
+<br /> <br />
+You can also use the following link to do the subscribing if you want:
+<br />
+<a href="http://lists.sourceforge.net/lists/listinfo/silc-devel" class="normal">
+subscribe to silc-devel</a>
+<br /> <br />
+
+<b>Unsubscribing from silc-devel</b>
+<br /> <br />
+To unsubcribe from the silc-devel mailing list send email to the following
+address:
+<br />
+<a href="mailto:silc-devel-request@lists.sourceforge.net" class="normal">
+silc-devel-request@lists.sourceforge.net</a>, and add the following
+line to the body of the email.
+<br /> <br />
+unsubscribe yourpassword [address]
+<br /> <br />
+You must give the password you set in the subscribing process. If you are
+unsubscribing from different address you must give the email address too.
+<br /> <br />
+You can also use the following link to do the unsubscribing if you want:
+<br />
+<a href="http://lists.sourceforge.net/lists/listinfo/silc-devel" class="normal">
+unsubscribe from silc-devel</a>
--- /dev/null
+ <br />
+<b><big>Mirrors</big></b>
+<br /> <br />
+Mirrors synchronize once a day. Currently available mirrors:
+<br /> <br />
+
+<a href="http://silcnet.org/" class="normal">Slovakia</a> (main site)
+<br />
+ - <a href="http://www.silcnet.org/" class="normal">www site</a>, <a href="ftp://ftp.silcnet.org/pub/silc/" class="normal">ftp archive</a>, <a href="http://ftp.silcnet.org/" class="normal">ftp archive over http</a>, <a href="?page=cvs" class="normal">anonymous cvs</a>, and <a href="http://cvs.silcnet.org/" class="normal">cvs web</a><br />
+ - 10Mbps connection, NEXTRA <br />
+ - provided by <a href="mailto:salo at silcnet.org" class="normal">Lubomir Sedlacik (salo)</a>
+<br /> <br />
+
+<a href="http://au.silcnet.org/" class="normal">Australia</a>
+<br />
+ - <a href="http://www.au.silcnet.org" class="normal">www site</a>, <a href="ftp://ftp.au.silcnet.org/pub/silcnet/" class="normal">ftp archive</a> and <a href="http://www.planetmirror.com/pub/silcnet/" class="normal">ftp archive over http</a><br />
+ - 155Mbps connection, SCCN <br />
+ - provided by <a href="mailto:jason at planetmirror.com" class="normal">Jason Andrade</a>, <a href="http://planetmirror.com" class="normal">Planet Mirror</a>
+<br /> <br />
+
+Australia 2
+<br />
+ - <a href="ftp://ftp.wiretapped.net/pub/security/network-security/silc/" class="normal">ftp</a> and <a href="http://the.wiretapped.net/security/network-security/silc/" class="normal">ftp archive over http</a><br />
+ - 10Mbps, Connect<br />
+ - provided by <a href="http://www.wiretapped.net" class="normal">Wiretapped</a>
+<br /> <br />
+
+Netherlands
+<br />
+ - <a href="http://munitions.vipul.net/software/mirrors/silc/" class="normal">ftp archive over http</a><br />
+ - 100Mbps, XS4ALL<br />
+ - provided by <a href="mailto:mail at vipul.net" class="normal">Vipul Ved Prakash</a>, <a href="http://munitions.vipul.net" class="normal">Munitions</a>
+<br /> <br />
+
+<a href="http://no.silcnet.org/" class="normal">Norway</a>
+<br />
+ - <a href="http://www.no.silcnet.org" class="normal">www site</a> and <a href="ftp://ftp.no.silcnet.org/pub/silc/" class="normal">ftp archive</a><br />
+ - 34Mbps connection <br />
+ - provided by <a href="mailto:debolaz at debolaz.com" class="normal">Anders Nor Berle (Debolaz)</a>
+<br /> <br />
+
+If you want to provide mirror of SILC webpage, FTP archive or CVS tree feel free to contact <a href="mailto: salo at silcnet.org" class="normal">me</a> for detailed instructions.
--- /dev/null
+ <br />
+<b><big>SILC Client <?php echo $Latest_Client; ?> Is Now Available!</big></b>
+<br /><small class="blue"><?php echo $Date_Client ?></small>
+<br /> <br />
+The new version <?php echo $Latest_Client; ?> of SILC Client is available!
+Read the README and INSTALL files after downloading for instructions how
+to compile and use SILC. Report bugs to the
+<a href="?page=lists" class="normal">SILC development mailing list</a>.
+<br /> <br />
+Download: <a href="?page=download" class="normal">SILC Client <?php echo
+$Latest_Client; ?> Version</a>
+<br />
+Changes: <a href="txt/changes-client.txt" class="normal">SILC Client <?php echo $Latest_Client; ?>
+Changes</a>
+
+<br /> <br /> <br />
+
+<b><big>SILC Server <?php echo $Latest_Server; ?> Is Now Available!</big></b>
+<br /><small class="blue"><?php echo $Date_Server ?></small>
+<br /> <br />
+The new version <?php echo $Latest_Server; ?> of SILC Server is available!
+Read the README and INSTALL files after downloading for instructions how
+to compile and use SILC. Report bugs to the
+<a href="?page=lists" class="normal">SILC development mailing list</a>.
+<br /> <br />
+People who is running SILC servers and are interested to get the server
+linked to the new router on silc.silcnet.org contact
+<a href="mailto:priikone at silcnet.org" class="normal">me</a> now.
+<br /> <br />
+Download: <a href="?page=download" class="normal">SILC Server <?php echo
+$Latest_Server; ?> Version</a>
+<br />
+Changes: <a href="txt/changes-server.txt" class="normal">SILC Server <?php echo $Latest_Server; ?>
+Changes</a>
+
+<br /> <br /> <br />
+
+<b><big>SILC Toolkit <?php echo $Latest_Toolkit; ?> Is Now Available!</big></b>
+<br /><small class="blue"><?php echo $Date_Toolkit ?></small>
+<br /> <br />
+The new version <?php echo $Latest_Toolkit; ?> of SILC Toolkit is available! This
+package is intended for developers and programmers who would like to
+create their own SILC applications or help in the development of SILC
+protocol.
+<br /> <br />
+Download: <a href="?page=download" class="normal">SILC Toolkit <?php echo
+$Latest_Toolkit; ?> Version</a>
+<br />
+Changes: <a href="txt/changes.txt" class="normal">SILC Toolkit <?php echo $Latest_Toolkit; ?>
+Changes</a>
+
+<br /> <br /> <br />
+
+<b><big>Try out SILC server at silc.silcnet.org</big></b>
+<br /> <br />
+You are free to connect to various SILC servers in the SILC Network. The
+network is still quite small but is growing all the time. To connect
+give command <i>/server silc.silcnet.org</i>. You might also want to try
+out one of the following servers:
+<br /> <br />
+
+- <samp class="blue">silc.silcnet.org (router)</samp> (Slovakia)<br />
+- <samp class="blue">silc.ytti.fi</samp> (Finland)<br />
+- <samp class="blue">silc.peelo.com</samp> (Finland)<br />
+- <samp class="blue">silc.debolaz.com</samp> (Norway)<br />
+- <samp class="blue">silc.highertechnology.com</samp> (USA)<br />
+- <samp class="blue">silc.silcnet.org on port 707</samp>
+
+<br /> <br />
+There may be some action on channel #silc (unless everybody is sleeping)
+so you might want to give command <i>/join #silc</i>.
--- /dev/null
+ <br />
+<tt class="black">
+<?php
+
+if (Is_Readable("txt/todo.txt")) {
+ $fp = FOpen("txt/todo.txt", "r");
+
+ while($line = FGets($fp, 255)) {
+ $newline = Ereg_Replace("^[ ]{2,4}"," ",$line);
+ $line = Ereg_Replace("^([\t]|[ ][\t])"," ",$newline);
+ printf("%s", nl2br($line));
+ }
+
+ FClose($fp);
+ }
+?>
+</tt>
--- /dev/null
+ <br />
+<b><big>SILC Protocol White Paper</big>
+<br />
+Version 1.0 / 03 Aug 2001
+
+<br /> <br />
+Introduction</b><br /> <br />
+
+Chat protocols are very popular on the Internet. They have actually
+been very popular since the very first chat protocols appeared on the net.
+The Internet Relay Chat (IRC) was one of the first chat protocols, and quickly
+gained the status of being the most popular chat on the net. Today, IRC
+has several competitors from various other so called Instant Messaging (IM)
+protocols, such as ICQ. However, all of these different chat protocols
+have something in common; they are all insecure.
+<br /> <br />
+
+The security is important feature in applications and protocols in
+contemporary network environment. The older chat protocols, however have
+failed to meet the growing security requirements on the Internet.
+It is not anymore enough to just provide services, like for example
+chat services. Now, they need to be secure services.
+<br /> <br />
+
+The Secure Internet Live Conferencing (SILC) protocol is a new generation
+chat protocol which provides full featured conferencing services, just
+like any other contemporary chat protocol provides. In addition, it
+provides security by encrypting and authenticating the messages in
+the network. The security has been the primary goal of the SILC protocol
+and the protocol has been designed from the day one security in mind.
+All packets and messages travelling in the SILC Network are always
+encrypted and authenticated. The network topology is also different
+from for example IRC network. The SILC network topology attempts to be
+more powerful and scalable than the IRC network. The basic purpose
+of the SILC protocol is to provide secure conferencing services.
+<br /> <br />
+
+The SILC Protocol have been developed as Open Source project. The
+protocol specifications are freely available and they have been submitted to
+the IETF. The very first implementations of the protocol are also already
+available.
+
+<br /> <br />
+<b>About This White Paper</b><br /> <br />
+
+The purpose of this white paper is to give short but deep enough introduction
+to the SILC Protocol. The document describes the purpose of the protocol
+and how the protocol works in practice. This document is intended for all
+audience. This document should be easy to understand for non-technical
+person and still be detailed enough for technically oriented person. See
+the section <a href="#terms" class="normal">Terms and Abbreviations</a> for terms used
+in this document.
+
+<br /> <br />
+(c) Copyright 2001 Pekka Riikonen
+(<a href="mailto:priikone at silcnet.org" class="normal">priikone at silcnet.org</a>)
+<br /> <br />
+This document is free document; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2 of the License, or
+(at your option) any later version. This document is distributed in
+the hope that it will be useful, but WITHOUT ANY WARRANTY; without even
+the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+See the GNU General Public License for more details.
+
+
+<br /> <br />
+<b>SILC Protocol</b><br /> <br />
+
+The Secure Internet Live Conferencing (SILC) protocol provides secure
+conferencing services over insecure network channel. The SILC is IRC
+like protocol, however it does not support IRC. Strong cryptographic
+methods are used to protect SILC packets inside the SILC network. SILC
+provides all the common conferencing services like channels, channel
+messages, private messages, nicknames and various commands. Difference
+to other chat protocol is in the design of the protocol. The SILC
+protocol has been designed from the day one security in mind and it
+shows in the protocol design.
+<br /> <br />
+
+Generally it is assumed that the SILC Network is trusted. This means
+that clients can fully trust the servers and routers in the SILC Network.
+In real life this is not always possible. In the Internet it is possible
+that some server or router would get compromised by a malicious
+cracker. However, if the SILC Network is closed network, for example
+inside a orgranization the assumption generally is true. The SILC
+protocol is secure even if the end users consider the network
+untrusted, and provides several ways to still have secure conversation
+on the SILC Network.
+<br /> <br />
+
+The packets in the SILC network are always encrypted. It is not possible
+to send unencrypted messages in SILC. This assures that end user cannot
+even accidently send unencrypted messages while thinking that it is
+encrypted. This is the problem of most other chat protocols that provide
+so called plugin encryption. They are not secure by default but try
+to provide security by applying external security protocol such as PGP
+or SSL. In these cases the security is achieved usually by encrypting the
+data while key management and other security issues may be left out, leaving
+the implementation vulnerable to various security problems. The other
+problem is also that the external protocols tend to leave the network
+only partly secured; usually only two points in the network are secured
+with for example SSL. While SSL does provide provable security it is not
+enough to provide security for a chat network as a whole.
+<br /> <br />
+
+The network topology is also different to various other chat protocol,
+like for example IRC. IRC has tree style network where SILC has so
+called cellular network. A cell consists of a router, servers and clients.
+The cell can also have backup routers in case the private router becomes
+unresponsive.
+
+<br /> <br />
+<img src="img/silc_network.png" alt="( SILC Network - IMAGE )" />
+<br /> <br />
+
+The diagram above illustrates a portion of the SILC network. It shows
+two cells that both has several servers, and backup routers and several
+clients. Clients can connect to server and routers if they want to.
+The following sections will describe the entities of the SILC Network
+in greater detail.
+
+<br /> <br />
+<b>Clients</b><br /> <br />
+
+A client is a piece of software connecting to SILC server. The software
+is usually run by the end user, a real person that is. The purpose of the
+clients is to provide the end user an interface to the SILC services.
+They are used to actually engage the conversations on the SILC Network,
+and they can be used to execute various SILC commands.
+<br /> <br />
+
+The clients are distinquished from other clients by unique Client ID.
+There cannot be multiple same Client IDs in the SILC Network at the same time.
+The end user, however does not use Client IDs. The end users usually selects
+a perferred nickname they want to use, and identifies themself with that
+nickname to other users on the network. The nicknames are not unique in
+the SILC Network. There can be multiple same nicknames at the same time
+on the network. The maximum length for the nickname is 128 characters.
+<br /> <br />
+
+Most of the other chat protocols have unique nicknames. This is where SILC
+differs from most of the other chat protocols. The purpose of this
+feature is to make IRC style nickname wars obsolete, as no one owns their
+nickname; there can always be somene else with the same nickname.
+<br /> <br />
+
+When client connects to the server the SILC Key Exchange (SKE) protocol and
+SILC Connection Authentication protocol are executed. The result of the
+SKE protocol is the session key that the client and server use to secure
+their communication. All commands, for example, that the client sends
+to the server are secured with the session key. The session key expires
+periodically and the rekey process can be executed with or without the
+Perfect Forward Secrecy (PFS). The connection authentication protocol is
+used to authenticate the client to the server. The server may allow the
+client to connect without authentication, or it may require a passphrase or
+public key based authentication.
+
+
+<br /> <br />
+<b>Servers</b><br /> <br />
+
+Servers forms the basis for the SILC Network, by providing a point to which
+clients may connect. There are two kinds of servers in SILC; normal servers
+and router servers. The next section describes the function of router
+server.
+<br /> <br />
+
+Normal servers connect to router server. Normal servers cannot directly
+connect to other normal servers. Messages that are destined outside the
+local server are always sent to the router for further routing.
+The clients usually connect to the normal server, however, clients may
+connect to router servers as well. The SILC Network diagram above
+illustrates how normal servers connects to the router server.
+<br /> <br />
+
+The servers are distinquished by other servers in the network by unique
+Server ID. There cannot be multiple same Server IDs in the SILC Network
+at the same time. The servers keep track of local information. It knows
+all locally connected clients and it knows all channels that its clients
+have joined. However, it does not know any global information. It
+usually does not keep track of global clients, however, it may cache
+that information if it was queried. The reason for this is that the
+server does not need to keep global information up to date and thus
+makes the server faster (and in the end the entire network faster).
+They can always query the information from the router.
+<br /> <br />
+
+When server connects to its router the SILC Key Exchange (SKE) protocol
+and the SILC Connection Authentication protocol are executed, just like
+when client connects to server. The SKE results in to the session key
+that is used to secure the communication between the server and the
+router. The connection authentication protocol is used to authenticate
+the server to the router. The authentication is always based in either
+passphrase or public key.
+
+
+<br /> <br />
+<b>Routers</b><br /> <br />
+
+The router servers are servers that actually handles the message routing
+in the network. They are, however also normal servers and they do accept
+client connections. Each of the router in the network is called a cell.
+A cell can have only one active router and it may have several servers
+and several clients. The cell, however may have backup routers that can
+take over the tasks of the primary router if it becomes unresponsive.
+The switch to the backup router should be transparent and only local
+connections to the primary router are lost. Other connections in the
+cell are intact, and clients and servers merely experience some lag in
+the network connection during the switch to the backup router.
+<br /> <br />
+
+The normal server knows only local information. Router server on the
+other hand knows local information and global information. It considers
+the cell as local and outside cells as global. It knows all the clients
+connected to the network, all created channels, and all routers and servers
+in the network. The server may query the global information if it is needed.
+For example, when client sends WHOIS command, the server may query the
+information from the router. If the router does not know all the details
+that the WHOIS command requires it can query the information from a router
+or a server which knows all the details. It may then cache that information.
+<br /> <br />
+
+The primary purpose of the router server is to route the messages to
+local servers and local clients, and messages that are destined to outside
+the cell are routed to the primary route or some other secondary
+route if it is a faster route. The routers in the network forms a ring.
+Each router has a primary route to other router in the network. Finally
+the ring is closed by the last router using the first router in the
+network as its primary route.
+
+<br /> <br />
+<img src="img/silc_routers.png" alt="( SILC Routers - IMAGE )" />
+<br /> <br />
+
+The diagram above illustrates how the routers forms a ring in the network.
+A router may have several secondary routes which it may use when it
+routes the packets.
+<br /> <br />
+
+When routers connect to its primary router the SKE and the SILC Connection
+Authentication protocols are executed just like when normal server connects
+to its router. The session key is used to secure the communication between
+the routers. All the secondary routes also have their own session keys.
+
+
+<br /> <br />
+<b>SILC Packet Protocol</b><br /> <br />
+
+The basis of SILC protocol relies in the SILC packets and they are with
+out a doubt the most important part of the protocol. The SILC Packet
+protocol is a binary packet protocol. The protocol provides secure
+binary packets and assures that the contents of the packets are secured
+and authenticated.
+<br /> <br />
+
+Packets are used in the SILC protocol all the time to send for example
+channel messages, private messages, commands and other information. All
+packets in SILC network are always encrypted and their integrity is
+assured by computed Message Authentication Codes (MAC). The protocol
+defines several packet types and packet payloads. Each packet type
+usually has a specific packet payload that actually defines the contents
+of the packet. Hence, the actual data in the packet is the packet payload
+defined in the protocol.
+
+<br /> <br />
+<img src="img/silc_packet.png" alt="( Typical SILC Packet - IMAGE )" />
+<br /> <br />
+
+As the diagram above illustrates the SILC packet is constructed from the
+SILC Packet Header that is included in all SILC packets, data area that
+includes the packet payloads, and MAC area which assures the integrity of the
+packet. Entire SILC packet is always encrypted, except for the MAC area
+which is never encrypted. The encryption process and the key used,
+however depends on the packet payload. Some of the payloads are encrypted
+with the session key and some are encrypted with other keys, for example
+with channel message keys. The SILC Packet Header is always encrypted with
+the session key. The MAC is computed from the SILC Packet Header and the
+data area before encrypting the packet.
+
+
+<br /> <br />
+<b>SILC Key Exchange Protocol</b><br /> <br />
+
+SILC Key Exchange Protocol (SKE) is used to exchange shared secret
+between connecting entities. The result of this protocol is a key material
+used to secure the communication channel. This protocol is executed when,
+for example client connects to server. It is also executed when server
+connects to router. And, there is no reason why it could not be executed
+between two clients too, if two clients would need to create secret key.
+The purpose of the SKE protocol is to create session keys to be used
+in current SILC session. The SKE is based on the Diffie-Hellman key
+exchange algorithm, and is immune to man-in-the-middle attack.
+<br /> <br />
+
+This is the first protocol that is executed when creating connection to,
+for example SILC server. All the other protocols are always executed
+after this protocol. This way all the other protocols are secured since
+the SKE creates the session key that is used to secure all subsequent
+packets. The session keys created in the SKE are valid only for some
+period of time (usually an hour) or at most until the session ends.
+The rekey process can be executed with or without the Perfect Forward
+Secrecy (PFS).
+<br /> <br />
+
+The security properties that are used in the SILC session are also
+negotiated during the SKE. The protocol has initiator and responder.
+The initator is the one who starts the SKE negotiation and responder is
+the one who receives the SKE negotiation. When the protocol is started
+initiator sends a list of security properties that it supports. The
+responder then selects the security properties it supports and sends
+its reply to the initiator. The security properties includes ciphers,
+hash functions, public key algorithms, HMAC functions and other
+security properties. The responder can always choose the properties
+it supports.
+<br /> <br />
+
+After the security properties are selected the protocol continues
+by performing the Diffie-Hellman key exchange algorithm. At the same
+time the intiator and responder also sends their public keys or
+certificates to each other. The responder also computes a signature
+that the initiator will verify. It is also possible to perform a
+mutual authentication where both of the parties computes a signature
+which are verified by each other independently. If any of the phases
+of the protocol are to fail the connection is closed immeadiately.
+<br /> <br />
+
+The public key or certificate that is received during the SKE protocol
+must be verified. If it is not verified it would be possible to
+execute a man-in-the-middle attack against the SKE protocol. If
+certificates are used they can be verified by a third party Certification
+Authority (CA). Verifying a public key requires either confirming
+a fingerprint of the public key over phone or email, or the server
+can for example publish the fingerprint (and the public key) on some
+website. In real life systems accepting the public key without
+verification, however is often desired. In many security protocols,
+such as in SSH2, the public key is accepted without verification
+in the first time when the connection is created. The public key is
+then cached on local hard disk. When connecting next time to the
+server the public key on local cache is verified against the public
+key server sent. In real life this works most of the time. However,
+if client (or server) cannot trust this, it must find some other way
+to verify the received public key or certificate.
+
+
+<br /> <br />
+<b>SILC Connection Authentication Protocol</b><br /> <br />
+
+Purpose of SILC Connection Authentication protocol is to authenticate the
+connecting party with server or router. This protocol is executed when
+for example client connects to server. It is also executed when server
+connects to router. Its other purpose is to provide information for the
+server about which type of connection it is. The type of the connection
+defines whether it is client, server or router. If it is client then
+the server will create a new Client ID for the client. If it is server
+then it will except the server to send its Server ID. Server IDs are
+created by the servers and routers itself.
+<br /> <br />
+
+Since the SILC Connection Authentication protocol is always executed after
+the SKE protocol, session keys has been established already. This means
+that all packets sent in the connection authentication protocol are encrypted
+and authenticated.
+<br /> <br />
+
+The authentication may be based either in passphrase or public key
+encryption. It is also possible to not require authentication at all.
+If the authentication is based to passphrase the passphrase is sent
+to the server. As the packet sent by, for example client, is entirely
+encrypted it is safe to send the passphrase inside the packet.
+<br /> <br />
+
+If the authentication is based to public key then, for example the client,
+signs data with its private key and sends it to the server. The server
+then verifies this signature by using the client's public key. The
+packet is also encrypted in the case of public key authentication.
+<br /> <br />
+
+If the authentication is to fail the connection to the server or router
+will be refused. If it is successful the connection is granted. After
+this the client is ready to communicate in the SILC Network.
+
+
+<br /> <br />
+<b>Channels</b><br /> <br />
+
+A channel is a named group of one or more clients which will all receive
+messages addressed to that channel. The channel is created when first
+client joins to it, and the channel ceases to exist when the last client
+leaves it. When channel exists, any client can reference it using the
+name of the channel. Channel is a place where group of people can engage
+conversation.
+<br /> <br />
+
+Channel names are unique in the SILC Network. There cannot be multiple
+same channels in the network at the same time. However, channel has also
+a Channel ID which is actually used to reference the channel in the
+SILC Network. The maximum length for the channel name is 256 characters.
+<br /> <br />
+
+Channels can have operators that can administrate the channel and operate
+all of its modes. There are two types of operators on the channel:
+channel founder and channel operator.
+<br /> <br />
+
+The channel founder is the client which created the channel. Channel
+founder is channel operator with some more privileges. Channel founder
+can operate all of the channel's modes. Furthermore, channel founder
+privileges cannot be removed by any other operator on channel and channel
+founder cannot be removed from the channel by force. It is also possible
+for the channel founder to regain its privileges at later time, even if
+they have left the channel.
+<br /> <br />
+
+Channel operator is operator that can operate most of the channel's
+modes and administrate the channel. However, it cannot operate all
+modes which are strictly reserved for channel founder. Channel operator
+is, however able to adminstrate the channel, set some modes on the
+channel, remove a badly behaving client from the channel, and promote
+other clients to become channel operator.
+
+
+<br /> <br />
+<b>Channel Message Delivery</b><br /> <br />
+
+All clients that have joined the channel can send messages to the channel.
+All channel messages are secured and authenticated by channel key. The
+channel key is generated by the server when the channel is created,
+a client joins the channel, or a client leaves the channel. The channel
+key is also regenerated periodically. The reason for the regeneration
+of channel key everytime someone joins or leaves the channel is that
+it prevents new clients joining the channel, and old clients leaving the
+channel, to encrypt or decrypt old or new messages. They can encrypt
+and decrypt channel messages only when they have joined on the channel.
+<br /> <br />
+
+Channel keys are cell specific in the SILC Network. Each cell that
+have clients joined on a particular channel have also own key for the
+channel. That key is not shared by other cells in the network. Inside
+the cell the channel key is known by the router and all servers that
+have clients on the channel and all clients that have joined the channel.
+
+<br /> <br />
+<img src="img/silc_channel.png" alt="( Channel Message Delivery - IMAGE )" />
+<br /> <br />
+
+The diagram above illustrates typical delivery of channel messages inside
+a cell and between two cells. Both of the cells have their own channel
+key. Both cells knows all clients joined on the channel. When message
+is sent to the channel by an client, it is encrypted with the current
+channel key in that cell. The servers and the router in the local cell
+then routes the message to all local clients who have joined the channel.
+If the channel has clients that belong to other cell in the network the
+router will route the channel message to that cell. When channel
+messages are sent between routers they are first decrypted with the
+current channel key, and then re-encrypted with the session key shared
+between the two routers. The router who receives the channel message
+then decrypts it with the session and re-encrypts it with the
+current channel key in that cell. It then distributes the channel message
+to all clients on the channel. The clients who have joined the channel
+always knows the current channel key and can decrypt all channel messages
+they receive. Note that normal servers in the SILC network never decrypt
+the channel messages even though the have the key. There is no reason
+for servers to decrypt the message. The router decrypts the message
+only when sending it between two routers.
+<br /> <br />
+
+This method of channel message delivery is the default way to send
+channel messages in the SILC Network. However, this is not perfect
+solution on all circumstances. If the clients joined on a particular
+channel cannot trust, or do not want to trust the servers and routers
+in the SILC Network they can consider the fact, that servers and routers
+knows the channel key is actually a breach of security.
+<br /> <br />
+
+If the clients on the other hand can trust their servers and routers
+in the SILC Network this is the recommended way of sending channel
+messages. This method is the simplest method for end user since it
+does not require any special settings before engaging the conversation
+on the channel. The client merely joins the channel, receives the
+channel key from the server and can start the conversation on the
+channel.
+<br /> <br />
+
+In addition of encrypting channel messages it also possible to digitally
+sign all sent channel messages. The receiver could then verify the
+signature of each of the message using the sender's public key.
+
+
+<br /> <br />
+<b>Channel Message Delivery With Channel Private Key</b><br /> <br />
+
+If the clients cannot trust the servers and routers in the SILC Network
+they should not use the default way of sending the channel messages.
+Instead, they should use channel private keys to encrypt and decrypt
+the channel messages. Channel private keys are keys that are known
+only by the clients who have joined the channel. Sservers and
+routers do not know the key and cannot decrypt the messages. When
+message is sent between two routers they are merely re-encrypted with
+the session key but not decrypted since the router do not have the
+key to do that.
+<br /> <br />
+
+The clients who have joined the channel must first agree on the channel
+private key they are going to use. The key may generally be anything.
+It may be a passphrase or a random string, or the key may negotiated
+using some key exchange protocol which provides negotiating the
+key for multiple clients at the same time.
+<br /> <br />
+
+As the channel private key is actually entirely local setting in the
+client, it is possible to set several channel private keys for one
+channel. It is possible to have multiple channel private keys that
+are not known by all channel members. When encrypting messages with
+one channel private key only the clients who have that key can decrypt
+the message. The other key could be shared for example by all clients
+on the channel and thus all clients can decrypt messages encrypted with
+that key. In this way it is actually possible to have a private group
+conversation inside the channel while having global conversation at the
+same time.
+
+
+<br /> <br />
+<b>Private Messages</b><br /> <br />
+
+Private messages are messages that are sent from one client to another
+through the SILC Network. They are private because they are not sent to
+anyone else except to the true receiver of the message. Private messages
+can be used to engage private conversation with another client if channels
+are not desired.
+<br /> <br />
+
+As all messages in SILC the private message are also encrypted and
+authenticated. There are several ways to secure private messages. By
+default private messages are encrypted using the session keys established
+in the SKE protocol. It is also possible to negotiate a private message
+key between the two clients and encrypt the messages with that key. It
+is even possible to encrypt the messages with public key cryptosystem,
+if desired. The next sections will describe all these private message
+delivery methods.
+
+<br /> <br />
+The SILC protocol provides these three methods of delivering private messages
+because none of the methods alone can satisfy the security requirements
+of all people. The end user should decide the acceptable level of risk,
+the required level of security and other security and usability aspects when
+deciding what way of sending private message suites for them.
+<br /> <br />
+
+In addition of encrypting private messages it also possible to digitally
+sign all sent private messages. The receiver could then verify the
+signature of each of the message using the sender's public key.
+
+
+<br /> <br />
+<b>Private Message Delivery With Session Keys</b><br /> <br />
+
+Sending private messages are by default secured with session keys established
+in the SKE protocol. This means that the private message is always encrypted
+with the session key of the next receiver of the message enroute to the
+receiving client. This also means that the message is decrypted and
+re-encrypted everytime it is sent further to the receiving client.
+
+<br /> <br />
+<img src="img/silc_priv1.png" alt="( Basic Private Message Delivery - IMAGE )" />
+<br /> <br />
+
+As the diagram above shows the private messages sent by Client A to the
+Client B travels through the SILC Network and is always decrypted and
+re-encrypted with the session key of the next receiver. The Client B then
+finally decrypts the private messages that is encrypted with the session
+key shared between the Client B and the Server Y.
+<br /> <br />
+
+This way of securing private messages is not perfect and cannot be used
+in all circumstances. If the clients having the conversation cannot trust
+the servers and routers in the SILC Network they should not send private
+messages that are secured in this manner. Messages secured in this manner
+can be decrypted by the servers and routers that the clients may consider
+to be untrusted.
+<br /> <br />
+
+If the clients on the other hand trust the servers and routers in their
+SILC Network, or they do not care that servers can decrypt their messages,
+sending private messages in this way is very simple from client's point
+of view. For servers and routers this of course means that they need
+to decrypt and re-encrypt each private message. Since this way of securing
+private message cannot be used at all times the SILC protocol provides
+other ways of securing private messages.
+
+
+<br /> <br />
+<b>Private Message Delivery With Private Message Key</b><br /> <br />
+
+Private messages can be secured with private message key as well. This
+key is known only by the sender of the message and the receiver of the
+message. This way no one else except the sender and the receiver can encrypt
+and decrypt the private messages. The message is encrypted by the sender
+with the private message key and all the servers and routers pass the message
+through enroute to the receiver. They cannot decrypt the message since
+they do not have the key. When sending private messages in this way it
+does not matter whether the clients trust or do not trust the servers and
+routers in the SILC network.
+
+<br /> <br />
+<img src="img/silc_priv2.png" alt="( Private Messages with Private Message Key - IMAGE )" />
+<br /> <br />
+
+As the diagram above shows the Client A encrypts the message with private
+message key and sends the message to the SILC Network. All servers and
+routers merely pass the message through since they cannot decrypt it.
+The Client B then receives the message and decrypts it with the private
+message key.
+<br /> <br />
+
+Sending private messages in this manner is always secure since the key is
+shared only by the sender and the receiver. The problem of this method
+is that the sender and the receiver must somehow agree about the key
+they are going to use. The private message key can generally be anything.
+It can be a passphrase that only the sender and the receiver knows. They
+could have been agreed to use some word or phrase as the key sometime
+earlier before they started the conversation. Or the key maybe from some
+random string from a code book that only the sender and the receiver poses.
+Or it can be a key that is negotiated using some key exchange protocol.
+<br /> <br />
+
+The problem however is fundamental. How to agree to use some key when
+you cannot reach the other person over secure channel? The SILC protocol
+solves this problem by providing a possiblity to negotiate the key
+between two clients using the SKE protocol. One or both of the clients
+can set up the SKE server running in their host and ask the other client
+to connect to it. In this case the SKE is executed outside the SILC
+Network. As a result of the SKE protocol the clients have now shared
+secret that they can use as private message key. The key is known only
+by the two clients that executed the SKE protocol. They can then use
+that key to secure all subsequent private messages.
+<br /> <br />
+
+Using this method of private messages delivery is recommended if the
+clients cannot trust the servers and routers in the SILC Network. The
+drawback is the extra phase of setting the private message key before
+starting the conversation. However, using the SKE protocol is the
+recommended way to negotiate the private message key since it can be
+automatized and does not cause any extra tasks for end user.
+
+
+<br /> <br />
+<b>Private Message Delivery With Public Key Encryption</b><br /> <br />
+
+If the clients cannot trust the servers and routers in the SILC Network
+they can use the private message key. As described in the previous section
+it is easy to set up with the SKE protocol. However, sometimes the two
+clients do not want to use any passphrases as private message key or
+negotiate the key with SKE, or perhaps they are unable to negotiate the
+key because of some other external problem. The SILC protocol provides
+yet another way of securing the private messages. This way does not
+require setting or negotiating private message key. And, in this method
+also it does not matter whether the clients trust or do not trust the
+servers and routers in the SILC Network. The method is public key
+encryption. The clients can encrypt the private messages with the
+receiver's public key and send the message to the network. The servers
+and routers cannot decrypt the messages since they do not have the
+receiver's private key. The receiver on the other hand has the private
+key which it uses to decrypt the message.
+
+<br /> <br />
+<img src="img/silc_priv3.png" alt="( Private Messges with Public Key Cryptosystem - IMAGE )" />
+<br /> <br />
+
+As the diagram above shows the Client A has the Client B's public key.
+It will encrypt the message with that key and sends the message to the
+SILC Network. All servers and routers pass the message through since
+they cannot decrypt it. The Client B then uses its private key to
+decrypt the message. The Client B has also the Client A's public key
+that it can use to encrypt messages that it will send to Client A.
+<br /> <br />
+
+Even this method of private message delivery is not perfect. The drawbacks
+of this method is that the public key encryption process, as being
+asymmetric cryptosystem, is much slower than encryption process with
+symmetric cryptosystems. This is not probably problem with short messages
+but may be inconvenient with long messages. The other drawback is that the
+sender must first assure that the public key it is using in the encryption
+is actually the receiver's public key. This is a absolute requirement
+in this method. If the sender cannot authenticate the receiver's public
+key this method of private message delivery should not be used. In SILC
+protocol clients can fetch other clients public keys from servers.
+However, the servers may not have authenticated the fetched public key so
+that should not be fully trusted. Use of certificates can solve the
+problem. The receiver's certificate could be authenticated by a third
+party Certification Authority (CA).
+
+<br /> <br />
+Usually verifying the public key is not a problem since the receiver
+can provide the public key on some website, or verify the fingerprint of
+the key over email, or phone call. The clients can also fetch the
+public keys from SILC servers if they trust that the keys are authentic.
+If both of the clients trust that the public keys are authentic using this
+method of private message delivery is very simple and recommended.
+
+
+<br /> <br />
+<b>Conclusion</b><br /> <br />
+
+The Secure Internet Live Conferencing (SILC) protocol is a new generation
+chat protocol that provides all the common conferencing services with
+strong support for security. It has wide range of security properties
+that should meet the highest levels of security requirements, while not
+forgetting easy of use. The network topology offers new architectural
+solution with better scalability over traditional chat protocols.
+
+
+<br /> <br />
+<b>Further Information</b><br /> <br />
+
+More detailed information about the SILC protocol is available in the
+SILC protocol specification documents. There exists currently four
+Internet Drafts that defines the protocol in great detail. The Internet
+Drafts are available from the following sources but also from the
+<a href="http://www.ietf.org/" class="normal">IETF website</a>.
+<br /> <br />
+
+- <a href="docs/draft-riikonen-silc-spec-03.txt" class="normal">
+Secure Internet Live Conferencing (SILC), Protocol Specification</a>
+<br />
+- <a href="docs/draft-riikonen-silc-pp-03.txt" class="normal">
+SILC Packet Protocol</a>
+<br />
+- <a href="docs/draft-riikonen-silc-ke-auth-03.txt" class="normal">
+SILC Key Exchange and Authentication Protocols</a>
+<br />
+- <a href="docs/draft-riikonen-silc-commands-01.txt" class="normal">
+SILC Commands</a>
+<br /> <br />
+
+For comprehensive introduction to cryptography refer to the
+<a href="http://www.ssh.com/tech/crypto/" class="normal">Cryptography A-2-Z document</a>.
+
+<br /> <br />
+<a name="terms"></a>
+<b>Terms and Abbreviations</b><br /> <br />
+
+- Asymmetric cryptosystem
+<br /> <br />
+Asymmetric cryptosystem provides public encryption. It has two keys,
+one public key and one private key (also called as secret key). The public
+key is publicly available allowing anyone to encrypt messages with the
+public key. Only the posessor of the private key can decrypt those messages.
+Difference to symmetric cryptosystem is that symmetric cryptosystem use only
+one key, and the key is usually used to both encryption and decryption. The
+asymmetric cryptosystem is also called as public key encryption, public key
+cryptosystem or public key algorithm. SILC supports RSA and DSS asymmetric
+cryptosystems.
+<br /> <br />
+
+- Authentication
+<br /> <br />
+The verification of the identity of a person, host or process in order
+to gain access to a service or prove identity. In data communications
+it also means verifying the origin of a message.
+<br /> <br />
+
+- Certificate
+<br /> <br />
+Certificate is a digital document which can be used to verify the
+identity of a person or host. In SILC, certificates can be used to prove
+identity of clients, servers and routers. Basically certificate is a public
+key with subject name. SILC supports X.509, OpenPGP and SPKI certificates.
+Supported public keys are SILC style public key and SSH2 style public
+key.
+<br /> <br />
+
+- Certification Authority (CA)
+<br /> <br />
+A third party entity that can verify identity of a person or host. CA
+is usually external company that provides certificates and their
+verification services.
+<br /> <br />
+
+- Diffie-Hellman key exchange
+<br /> <br />
+First public key algorithm ever invented. It is used to generate a secret
+key between two or more parties. It gets its security from the difficulty
+of calculating discrete logarithms.
+<br /> <br />
+
+- Encryption
+<br /> <br />
+A mechanism (usually mathematical) to transfer plaintext (or cleartext)
+to ciphertext to provide confidentiality. A process to transfer
+the ciphertext back to plaintext is called decryption.
+<br /> <br />
+
+- Integrity
+<br /> <br />
+The verification of data to detect any modifications. If data is
+modified enroute from the sender to the receiver, the modification will
+be detected.
+<br /> <br />
+
+- HMAC
+<br /> <br />
+Hash Message Authentication Code. Also called as keyed hash function.
+It is a secret key authentication algorithm which proves that the message
+is not modified and that the HMAC was computed by the sender of the
+message.
+<br /> <br />
+
+- Key management
+<br /> <br />
+Key management is a set of processes and mechanisms which support key
+exchange and maintainance of current keying relationships between parties,
+including replacing older keys with new keys as necessary, by executing
+rekey.
+<br /> <br />
+
+- Man-in-the-middle attack
+<br /> <br />
+An attack against two connecting entities where the attacker executes
+key exchange protocol with both of the parties indepently without
+their knowledge. Both of the connecting entities will end up having secret
+key with the attacker, and the attacker can encrypt and decrypt all the
+messages that goes between the two entities.
+<br /> <br />
+
+- Message Authentication Code (MAC)
+<br /> <br />
+MAC provides message integrity by computing the MAC using a secret
+key authentication algorithm (HMAC).
+<br /> <br />
+
+- Perfect Forward Secrecy (PFS)
+<br /> <br />
+A property of rekey (or key regeneration) which defines whether the
+new key is derived from the old key. If Perfect Forward Secrecy is
+selected the new key is never dependent of the old key which means
+that if the old key would get compromised at later time it will not
+compromise the new key. In SILC setting PFS in the SKE protocol means
+executing the SKE protocol again. If PFS is not selected the new key
+is always derived from the old key.
+<br /> <br />
+
+- Rekey
+<br /> <br />
+A key regeneration process where the old key has expired or is not
+secure anymore to use. In this case rekey is performed and new key
+is generated.
+<br /> <br />
+
+- Symmetric cryptosystem
+<br /> <br />
+Symmetric cryptosystem is one key cryptosystem where one key is used
+usually to both encryption and decryption process. The symmetric
+cryptosystems are usually significantly faster than asymmetric cryptosystems.
+DES, AES, Twofish and Blowfish are examples of symmetric cryptosystems.
+SILC supports all the common symmetric cryptosystems including AES.
+SILC does not support DES as it is insecure and 3DES as it is too slow.
projects / silc.git / commitdiff