From 2cb7c1fd2e636a5215af51890ada816614b5b83b Mon Sep 17 00:00:00 2001 From: Lubomir Sedlacik Date: Tue, 6 Nov 2001 23:21:11 +0000 Subject: [PATCH] initial commit of new webpage --- public_html/html/about.php | 92 ++++ public_html/html/contribute.php | 21 + public_html/html/copying.php | 300 +++++++++++ public_html/html/counter.php | 32 ++ public_html/html/cvs.php | 188 +++++++ public_html/html/docs.php | 135 +++++ public_html/html/download.php | 111 +++++ public_html/html/faq.php | 385 ++++++++++++++ public_html/html/features.php | 90 ++++ public_html/html/history.php | 32 ++ public_html/html/install.php | 17 + public_html/html/lists.php | 53 ++ public_html/html/mirrors.php | 42 ++ public_html/html/news.php | 71 +++ public_html/html/todo.php | 17 + public_html/html/whitepaper.php | 857 ++++++++++++++++++++++++++++++++ 16 files changed, 2443 insertions(+) create mode 100644 public_html/html/about.php create mode 100644 public_html/html/contribute.php create mode 100644 public_html/html/copying.php create mode 100644 public_html/html/counter.php create mode 100644 public_html/html/cvs.php create mode 100644 public_html/html/docs.php create mode 100644 public_html/html/download.php create mode 100644 public_html/html/faq.php create mode 100644 public_html/html/features.php create mode 100644 public_html/html/history.php create mode 100644 public_html/html/install.php create mode 100644 public_html/html/lists.php create mode 100644 public_html/html/mirrors.php create mode 100644 public_html/html/news.php create mode 100644 public_html/html/todo.php create mode 100644 public_html/html/whitepaper.php diff --git a/public_html/html/about.php b/public_html/html/about.php new file mode 100644 index 00000000..ba6becc8 --- /dev/null +++ b/public_html/html/about.php @@ -0,0 +1,92 @@ + 
+About SILC +
 
+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. +
 
+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. +
 
+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. +
 
+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. +
 
+ +Distribution +
 
+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. +
 
+- 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 Irssi project). +
 
+- 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. +
 
+- 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. +
 
+ +Licensing +
 
+SILC is an Open Source (or Free Software) project and it has been released +under the GNU General Public License. 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. +
 
+Specification of SILC protocol is available for anyone to look at. There +exist four Internet Drafts that have been submitted to the IETF. See documentation page for more information. +
 
+ +Contact +
 
+Feedback and comments are welcome. Bug reports should be sent to the +development mailing list. +
 
+Development mailing list address: + +silc-devel@lists.sourceforge.net diff --git a/public_html/html/contribute.php b/public_html/html/contribute.php new file mode 100644 index 00000000..6a576dff --- /dev/null +++ b/public_html/html/contribute.php @@ -0,0 +1,21 @@ + 
+Contributing +
 
+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 TODO list. +
 
+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 +documentation page. +
 
+Who wants to send code to the project should read the CodingStyle +documentation. New code must comply with the coding style conventions +described in that document. +
 
+There is anonymous CVS acccess for those who want to participate the +development process. See the CVS page. diff --git a/public_html/html/copying.php b/public_html/html/copying.php new file mode 100644 index 00000000..46c942f5 --- /dev/null +++ b/public_html/html/copying.php @@ -0,0 +1,300 @@ + 
+GNU GENERAL PUBLIC LICENSE
+Version 2, June 1991 +
 
+Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+59 Temple Place - Suite 330, Boston, MA 02111-1307, USA +
 
+Everyone is permitted to copy and distribute verbatim copies
+of this license document, but changing it is not allowed. +
 
+Preamble +
 
+ 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. +
 
+ 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. +
 
+ 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. +
 
+ 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. +
 
+ 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. +
 
+ 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. +
 
+ 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. +
 
+ The precise terms and conditions for copying, distribution and +modification follow. +
 
+TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION +
 
+0. + 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". +
 
+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. +
 
+1. + 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. +
 
+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. +
 
+2. + 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: +
 
+a) + You must cause the modified files to carry prominent notices + stating that you changed the files and the date of any change. +
 
+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. +
 
+c) + 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.) +
 
+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. +
 
+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. +
 
+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. +
 
+3. + 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: +
 
+a) + 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, +
 
+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, +
 
+c) + 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.) +
 
+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. +
 
+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. +
 
+4. + 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. +
 
+5. + 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. +
 
+6. + 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. +
 
+7. + 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. +
 
+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. +
 
+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. +
 
+This section is intended to make thoroughly clear what is believed to +be a consequence of the rest of this License. +
 
+8. + 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. +
 
+9. + 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. +
 
+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. +
 
+10. + 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. +
 
+NO WARRANTY +
 
+11. + 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. +
 
+12. + 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. +
 
+END OF TERMS AND CONDITIONS diff --git a/public_html/html/counter.php b/public_html/html/counter.php new file mode 100644 index 00000000..e85d4001 --- /dev/null +++ b/public_html/html/counter.php @@ -0,0 +1,32 @@ + diff --git a/public_html/html/cvs.php b/public_html/html/cvs.php new file mode 100644 index 00000000..d56955a1 --- /dev/null +++ b/public_html/html/cvs.php @@ -0,0 +1,188 @@ + 
+Anonymous CVS access +
 
+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. +
 
+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. + +
 
+ +Browsing the Source Tree +
 
+If you want to browse the source tree using web browser before checking +out the tree with CVS use following link: +
 
+Web Access to CVS repository + +
 
+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. + +
 
+ +Howto Checkout The Source Tree +
 
+The repository can be checked out by using anonymous pserver with CVS. +
 
+For those who are using sh/ksh/bash/zsh the check out is done as follows: +
 
+ +export CVSROOT=:pserver: +
 
+cvs login
+cvs co silc
+cvs logout
+ + +
 
+For those who are using csh/tcsh the check out is done as follows: +
 
+ +setenv CVSROOT :pserver: +
 
+cvs login
+cvs co silc
+cvs logout
+ +
 
+If you don't want to set $CVSROOT environment variable you can set the +path to the cvs as command line option: +
 
+ +cvs -d:pserver: login +
+cvs -d:pserver: co silc +
+cvs -d:pserver: logout + +
 
+Whatever method you will decide to use, after you have done cvs login you will +be prompted for password: +
 
+CVS password: silc +
 
+Type the password "silc" and press <ENTER> +
 
+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. + +
 
+ +What SILC Source Tree Includes +
 
+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. +
 
+Following directories currently exist in SILC source tree. +
 
+ +doc/ +
 
+  Includes all the SILC documentation. Few parts of the documentation
+  are generated when distribution is generated. The automatically
+  generated files should never be commited to CVS.
+
 
+includes/ +
 
+  Includes SILC include files. +
 
+lib/ +
 
+  Includes SILC libraries. There are maybe libraries in the CVS which
+  are not inclduded in public distribution.
+
 
+public_html/ +
 
+  Includes the official SILC web pages and everything related to them.
+  This directory will never appear in public distribution.
+
 
+silc/ +
 
+  Includes SILC client. There can be some extra files that will
+  never appear in public distribution, such as configuration files.
+
 
+silcd/ +
 
+  Includes SILC server. There can be some extra files that will
+  never appear in public distribution, such as configuration files.
+ + +
 
+ +Howto Compile SILC Source Tree +
 
+After checkout from CVS the SILC source tree needs to be prepared for +configuration and compilation. To compile the source tree, type: +
 
+ +./prepare
+./configure --enable-debug
+make
 
+note: on non-GNU/Linux operating systems GNU make (gmake) is prefered + +
 
+ +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). +
 
+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: +
 
+ +./silc -d -f configfile 2>log
+./silcd -d -f configfile 2>log + + +
 
+ +How to clean SILC Source Tree +
 
+To entirely clear the source tree to the state after it was checked out +from CVS, type: +
 
+ +./prepare-clean + +
 
+ +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. + +
 
+ +Makefiles and configuration files +
 
+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. +
 
+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 diff --git a/public_html/html/docs.php b/public_html/html/docs.php new file mode 100644 index 00000000..2ee32176 --- /dev/null +++ b/public_html/html/docs.php @@ -0,0 +1,135 @@ + 
+SILC Documentation +
 
+ +README file from packages: README +
+Coding Style in SILC source tree: CodingStyle +
 
+Software manual: Coming later + +
 
 
+ +Installation Instructions +
 
+General installation instructions are available in all SILC distributions +in the INSTALL file. +
 
+Installation instructions + +
 
 
+ +Technical Documentation +
 
+ +SILC Toolkit Reference Manual +
 
+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. +
 
+HTML version, +html.tar.gz + +
 
 
+ +SILC Protocol Documentation +
 
+ +SILC Protocol White Paper +
 
+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. +
 
+ +HTML version, +gzipped PDF, +gzipped PostScript + +
 
 
+ +SILC Protocol Internet Drafts +
 
+SILC Protocol is documented and four Internet Drafts exist. These +Internet Drafts are also available from +IETF. +
 
+NOTE Mon Nov 5 18:53:56 EET 2001: New versions of the protocol +specifications are almost ready for submission to the IETF. You can +preview the upcoming versions here. +
 
+ +Secure Internet Live Conferencing (SILC), Protocol Specification +
 
+Abstract +
 
+ 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]. +
 
+ +draft-riikonen-silc-spec-03.txt +
 
 
+ +SILC Packet Protocol +
 
+Abstract +
 
+ 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. +
 
+ +draft-riikonen-silc-pp-03.txt +
 
 
+ +SILC Key Exchange and Authentication Protocols +
 
+Abstract +
 
+ 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]. +
 
+ 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). +
 
+ +draft-riikonen-silc-ke-auth-03.txt +
 
 
+ +SILC Commands +
 
+Abstract +
 
+ 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. +
 
+ +draft-riikonen-silc-commands-01.txt diff --git a/public_html/html/download.php b/public_html/html/download.php new file mode 100644 index 00000000..8bddde38 --- /dev/null +++ b/public_html/html/download.php @@ -0,0 +1,111 @@ + 
+Download SILC +
 
+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. +
 
+Use a mirror near you for downloads. +
 
+ +SILC Client +
 
+The SILC Client package is inteded for end users who need only the SILC +client. The package includes the new Irssi-SILC client. +
 
+Sources HTTP: + +tar.gz ( kB), + +tar.bz2 ( kB) +
+ +Sources FTP: tar.gz and tar.bz2 +
+ +Binaries HTTP: +RPM ( kB) +, Cygwin ( kB) +, Solaris 8/SPARC ( kB) + +
+ +Binaries FTP: RPM, Solaris 8/SPARC +
 
+ + +SILC Server +
 
+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 me now. +
 
+Sources HTTP: + +tar.gz ( kB), + +tar.bz2 ( kB) +
+Sources FTP: tar.gz and tar.bz2 +
 
+ +SILC Toolkit +
 
+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. +
 
+Sources HTTP: + +tar.gz ( kB), + +tar.bz2 ( kB) +
+Sources FTP: tar.gz and tar.bz2 +
+Binaries HTTP: +Win32 ( kB) +
 
+ +CVS Snapshots +
 
+Daily CVS snapshots are available. These are generated 22:00 GMT every +night. Read the CVS page for more +information. +
 
+HTTP: CVS Snapshot +
 
+Portability +
 
+The SILC has been reported to work on, at least: +
 
+ - GNU/Linux
+ - FreeBSD
+ - NetBSD
+ - OpenBSD
+ - HP-UX
+ - Solaris
+ - IRIX
+ - Windows
+ - Cygwin & MinGW diff --git a/public_html/html/faq.php b/public_html/html/faq.php new file mode 100644 index 00000000..61c215db --- /dev/null +++ b/public_html/html/faq.php @@ -0,0 +1,385 @@ + 
+Frequently Asked Questions +
 
+1. General Questions
+     1.1 What is SILC?
+     1.2 When was SILC Project started?
+     1.3 Why SILC in the first place?
+     1.4 What license covers the SILC release?
+     1.5 Why SILC? Why not IRC3?
+     1.6 What platforms SILC supports?
+     1.7 Where can I find more information?
+     1.8 I would like to help out, what can I do? +
 
+2. Protocol Questions
+     2.1 What is the status of SILC protocol in the IETF?
+     2.2 How much the SILC protocol is based on IRC?
+     2.3 Why use SILC? Why not IRC with SSL?
+     2.4 Can I talk from SILC network to IRC network?
+     2.5 Does SILC support file transfer?
+     2.6 I am behind a firewall, can I use SILC?
+     2.7 How secure SILC really is?
+     2.8 Does SILC support instant messaging?
+     2.9 Why SILC does not have LINKS command like in IRC?
+     2.10 Why SILC does not have STATS command like in IRC?
+     2.11 I have suggestions to SILC Protocol, what can I do? +
 
+3. Client Questions
+     3.1 Where can I find SILC clients?
+     3.2 Can I use SILC with IRC client and vice versa? +
 
+4. Server Questions
+     4.1 Where can I find SILC servers?
+     4.2 Can I run own SILC server?
+     4.3 What is the difference between SILC server and SILC router?
+     4.4 Why server says permission denied to write to a log file?
+     4.5 When I connect to to my server, it says "server does not support one of your proposed cipher", what is wrong? +
 
+5. Toolkit Questions
+     5.1 What is SILC Toolkit?
+     5.2 Is the SILC Toolkit Reference Manual Available?
+     5.3 How do I compile the Toolkit on Unix
+     5.4 How do I compile the Toolkit on Win32
+
 
+ + +1. General Questions
 
+ + +Q: What is SILC?
+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. +
 
+Biggest differences are that SILC is secure what IRC is not in any way. +The network model is also entirely different compared to IRC. +
 
+ + +Q: When was SILC Project started?
+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. +
 
+ + +Q: Why SILC in the first place?
+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. +
 
+ + +Q: What license covers the SILC release?
+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. +
 
+ + +Q: Why SILC? Why not IRC3?
+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. +
 
+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. +
 
+ + +Q: What platforms SILC supports?
+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. +
 
+ + +Q: Where can I find more information?
+A: For more technical information we suggest reading the SILC Protocol +specifications. You might also want to take a look at the documentation page on the web page. +
 
+ + +Q: I would like to help out, what can I do?
+A: You might want to take a look at the Contributing page and the TODO list. You might also want to join the +SILC development mailing list. +
 
+ +
+2. Protocol Questions
 
+ + +Q: What is the status of SILC protocol in the IETF?
+A: The SILC protocol specifications has been submitted currently as +individual submissions. There does not currently exist a working group +for this sort of project. Our goal is to fully standardize the SILC and +thus submit it as RFC to the IETF at a +later time. +
 
+ + +Q: How much SILC Protocol is based on IRC?
+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. +
 
+ + +Q: Why use SILC? Why not IRC with SSL?
+A: Sure, that is possible, although, does that secure the entire IRC +network? And does that increase or decrease the lags and splits in the +IRC network? Does that provide user based security where some specific +private message are secured? Does that provide security where some +specific channel messages are secured? And I know, you can answer yes to +some of these questions. But, security is not just about applying +encryption to traffic and SILC is not just about `encrypting the +traffic`. You cannot make insecure protocol suddenly secure just by +encrypting the traffic. SILC is not meant to be IRC replacement. IRC is +good for some things, SILC is good for same and some other things. +
 
+ + +Q: Can I talk from SILC network to IRC network?
+A: Simple answer for this is No. The protocols are not compatible which +makes it impossible to directly talk from SILC network to IRC network or +vice versa. Developing a gateway between these two networks would +technically be possible but from security point of view strongly not +recommended. We have no plans for developing such a gateway. +
 
+ + +Q: Does SILC support file transfer?
+A: Yes. The SILC protocol support SFTP as mandatory file transfer +protocol. It provides simple client to client file transfer, but also +a possibility for file and directory manipulation. Even though the SFTP +is the file transfer protocol the support for file transferring has been +done so that practically any file transfer protocol may be used with SILC +protocol. +
 
+ + +Q: I am behind a firewall, can I use SILC?
+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. +
 
+ + +Q: How secure SILC really is?
+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. +
 
+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. +
 
+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. +
 
+To give a list of attacks that are ineffective against SILC: +
 
+- 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).
+ - IP spoofing is ineffective (because of encryption and trusted keys).
+ - Attacks that change the contents of the data or add extra data to the +packets are ineffective (because of encryption and integrity checks).
+ - Passive attacks (listenning network traffic) are ineffective (because +of encryption). Everything is encrypted including authentication data +such as passwords when they are needed.
+ - Any sort of cryptanalytic attacks are tried to make ineffective by +using the best cryptographic algorithms out there. +
 
+ + +Q: Does SILC support instant messaing?
+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. +
 
+ + +Q: Why SILC does not have LINKS command like in +IRC?
+A: It was felt that this information as an own command in SILC is not +necessary. Moreover, the topology of the network might be undisclosed +information even though the servers and routers in the network are still +open. We feel that the network topology information, if it is wanted to be +public, and the list of accessible servers can be made available in other +ways than providing command like LINKS, which shows the active server +links in IRC. +
 
+ + +Q: Why SILC does not have STATS command like in +IRC?
+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. +
 
+ + +Q: I have suggestions to SILC Protocol, +what can I do?
+A: All suggestions and improvements are of course welcome. You should read +the protocol specifications first to check out whether your idea is +covered by them already. The best place to make your idea public is the +SILC development mailing list. +
 
+ + +
+3. Client Questions
 
+ + +Q: Where can I find SILC clients?
+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. +
 
+ + +Q: Can I use SILC with IRC client and vice versa?
+A: Generally the answer would be no for both. However, there exist already +at least one IRC client that supports SILC, the Irssi client. 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. +
 
+ +
+4. Server Questions
 
+ + +Q: Where can I find SILC servers?
+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. +
 
+ + +Q: Can I run own SILC server?
+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. +
 
+ + +Q: What is the difference between SILC +server and SILC router?
+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. +
 
+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. +
 
+ + +Q: Why server says permission denied to write to a +log file?
+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. +
 
+ + +Q: When I connect to my server it says "server does +not support one of your proposed ciphers", what is wrong?
+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. +
 
+ + +
+5. Toolkit Questions
 
+ + +Q: What is SILC Toolkit?
+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. +
 
+ + +Q: Is the SILC Toolkit Reference Manual Available?
+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 documentation page. +
 
+ + +Q: How do I compile the Toolkit on Unix?
+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. +
 
+ + +Q: How do I compile the Toolkit on Win32?
+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. +
 
diff --git a/public_html/html/features.php b/public_html/html/features.php new file mode 100644 index 00000000..e09b6839 --- /dev/null +++ b/public_html/html/features.php @@ -0,0 +1,90 @@ + 
+Features +
 
+- Normal conferencing services such as private messages, channels, +channel messages, etc. All traffic is secured and authenticated. + +
 
+- 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. + +
 
+- 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. + +
 
+- 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. + +
 
+- 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. + +
 
+- 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). + +
 
+- 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. + +
 
+- Supports secure file transferring between clients in the network. SILC +use the SFTP as the main file transfer protocol. + +
 
+- 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. + +
 
+- 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. + +
 
+- Supports data compression with GZIP to improve performance. + +
 
+- Supports SOCKS4 and SOCKS5 firewall traversal protocols. + +
 
+- 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. + +
 
+- SILC client can be installed and used without root privileges. + +
 
+- SILC client can be configured by system wide configuration files but +with user specific configuration files as well. diff --git a/public_html/html/history.php b/public_html/html/history.php new file mode 100644 index 00000000..3a454ae0 --- /dev/null +++ b/public_html/html/history.php @@ -0,0 +1,32 @@ + 
+History +
 
+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. +
 
+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. +
 
+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. diff --git a/public_html/html/install.php b/public_html/html/install.php new file mode 100644 index 00000000..a193c276 --- /dev/null +++ b/public_html/html/install.php @@ -0,0 +1,17 @@ + 
+ + + diff --git a/public_html/html/lists.php b/public_html/html/lists.php new file mode 100644 index 00000000..e6b965cf --- /dev/null +++ b/public_html/html/lists.php @@ -0,0 +1,53 @@ + 
+Public SILC Mailing Lists +
 
+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: silc-devel@lists.sourceforge.net address. +
 
+To see prior postings to the list, browse the silc-devel archives. +
 
+ +Subscribing to silc-devel +
 
+To subscribe to silc-devel mailing list send email to the following +address: +
+ +silc-devel-request@lists.sourceforge.net, and add the following +line to the body of the email. +
 
+subscribe yourpassword +
 
+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. +
 
+You can also use the following link to do the subscribing if you want: +
+ +subscribe to silc-devel +
 
+ +Unsubscribing from silc-devel +
 
+To unsubcribe from the silc-devel mailing list send email to the following +address: +
+ +silc-devel-request@lists.sourceforge.net, and add the following +line to the body of the email. +
 
+unsubscribe yourpassword [address] +
 
+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. +
 
+You can also use the following link to do the unsubscribing if you want: +
+ +unsubscribe from silc-devel diff --git a/public_html/html/mirrors.php b/public_html/html/mirrors.php new file mode 100644 index 00000000..8c22719d --- /dev/null +++ b/public_html/html/mirrors.php @@ -0,0 +1,42 @@ + 
+Mirrors +
 
+Mirrors synchronize once a day. Currently available mirrors: +
 
+ +Slovakia (main site) +
+  - www site, ftp archive, ftp archive over http, anonymous cvs, and cvs web
+  - 10Mbps connection, NEXTRA
+  - provided by Lubomir Sedlacik (salo) +
 
+ +Australia +
+  - www site, ftp archive and ftp archive over http
+  - 155Mbps connection, SCCN
+  - provided by Jason Andrade, Planet Mirror +
 
+ +Australia 2 +
+  - ftp and ftp archive over http
+  - 10Mbps, Connect
+  - provided by Wiretapped +
 
+ +Netherlands +
+  - ftp archive over http
+  - 100Mbps, XS4ALL
+  - provided by Vipul Ved Prakash, Munitions +
 
+ +Norway +
+  - www site and ftp archive
+  - 34Mbps connection
+  - provided by Anders Nor Berle (Debolaz) +
 
+ +If you want to provide mirror of SILC webpage, FTP archive or CVS tree feel free to contact me for detailed instructions. diff --git a/public_html/html/news.php b/public_html/html/news.php new file mode 100644 index 00000000..aa15679f --- /dev/null +++ b/public_html/html/news.php @@ -0,0 +1,71 @@ + 
+SILC Client Is Now Available! +
+
 
+The new version 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 +SILC development mailing list. +
 
+Download: SILC Client Version +
+Changes: SILC Client +Changes + +
 
 
+ +SILC Server Is Now Available! +
+
 
+The new version 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 +SILC development mailing list. +
 
+People who is running SILC servers and are interested to get the server +linked to the new router on silc.silcnet.org contact +me now. +
 
+Download: SILC Server Version +
+Changes: SILC Server +Changes + +
 
 
+ +SILC Toolkit Is Now Available! +
+
 
+The new version 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. +
 
+Download: SILC Toolkit Version +
+Changes: SILC Toolkit +Changes + +
 
 
+ +Try out SILC server at silc.silcnet.org +
 
+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 /server silc.silcnet.org. You might also want to try +out one of the following servers: +
 
+ +- silc.silcnet.org (router) (Slovakia)
+- silc.ytti.fi (Finland)
+- silc.peelo.com (Finland)
+- silc.debolaz.com (Norway)
+- silc.highertechnology.com (USA)
+- silc.silcnet.org on port 707 + +
 
+There may be some action on channel #silc (unless everybody is sleeping) +so you might want to give command /join #silc. diff --git a/public_html/html/todo.php b/public_html/html/todo.php new file mode 100644 index 00000000..a0507630 --- /dev/null +++ b/public_html/html/todo.php @@ -0,0 +1,17 @@ + 
+ + + diff --git a/public_html/html/whitepaper.php b/public_html/html/whitepaper.php new file mode 100644 index 00000000..bb1ac3c4 --- /dev/null +++ b/public_html/html/whitepaper.php @@ -0,0 +1,857 @@ + 
+SILC Protocol White Paper +
+Version 1.0 / 03 Aug 2001 + +
 
+Introduction
 
+ +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. +
 
+ +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. +
 
+ +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. +
 
+ +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. + +
 
+About This White Paper
 
+ +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 Terms and Abbreviations for terms used +in this document. + +
 
+(c) Copyright 2001 Pekka Riikonen +(priikone at silcnet.org) +
 
+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. + + +
 
+SILC Protocol
 
+ +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. +
 
+ +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. +
 
+ +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. +
 
+ +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. + +
 
+( SILC Network - IMAGE ) +
 
+ +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. + +
 
+Clients
 
+ +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. +
 
+ +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. +
 
+ +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. +
 
+ +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. + + +
 
+Servers
 
+ +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. +
 
+ +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. +
 
+ +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. +
 
+ +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. + + +
 
+Routers
 
+ +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. +
 
+ +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. +
 
+ +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. + +
 
+( SILC Routers - IMAGE ) +
 
+ +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. +
 
+ +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. + + +
 
+SILC Packet Protocol
 
+ +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. +
 
+ +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. + +
 
+( Typical SILC Packet - IMAGE ) +
 
+ +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. + + +
 
+SILC Key Exchange Protocol
 
+ +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. +
 
+ +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). +
 
+ +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. +
 
+ +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. +
 
+ +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. + + +
 
+SILC Connection Authentication Protocol
 
+ +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. +
 
+ +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. +
 
+ +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. +
 
+ +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. +
 
+ +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. + + +
 
+Channels
 
+ +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. +
 
+ +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. +
 
+ +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. +
 
+ +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. +
 
+ +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. + + +
 
+Channel Message Delivery
 
+ +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. +
 
+ +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. + +
 
+( Channel Message Delivery - IMAGE ) +
 
+ +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. +
 
+ +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. +
 
+ +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. +
 
+ +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. + + +
 
+Channel Message Delivery With Channel Private Key
 
+ +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. +
 
+ +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. +
 
+ +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. + + +
 
+Private Messages
 
+ +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. +
 
+ +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. + +
 
+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. +
 
+ +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. + + +
 
+Private Message Delivery With Session Keys
 
+ +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. + +
 
+( Basic Private Message Delivery - IMAGE ) +
 
+ +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. +
 
+ +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. +
 
+ +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. + + +
 
+Private Message Delivery With Private Message Key
 
+ +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. + +
 
+( Private Messages with Private Message Key - IMAGE ) +
 
+ +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. +
 
+ +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. +
 
+ +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. +
 
+ +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. + + +
 
+Private Message Delivery With Public Key Encryption
 
+ +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. + +
 
+( Private Messges with Public Key Cryptosystem - IMAGE ) +
 
+ +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. +
 
+ +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). + +
 
+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. + + +
 
+Conclusion
 
+ +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. + + +
 
+Further Information
 
+ +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 +IETF website. +
 
+ +- +Secure Internet Live Conferencing (SILC), Protocol Specification +
+- +SILC Packet Protocol +
+- +SILC Key Exchange and Authentication Protocols +
+- +SILC Commands +
 
+ +For comprehensive introduction to cryptography refer to the +Cryptography A-2-Z document. + +
 
+ +Terms and Abbreviations
 
+ +- Asymmetric cryptosystem +
 
+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. +
 
+ +- Authentication +
 
+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. +
 
+ +- Certificate +
 
+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. +
 
+ +- Certification Authority (CA) +
 
+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. +
 
+ +- Diffie-Hellman key exchange +
 
+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. +
 
+ +- Encryption +
 
+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. +
 
+ +- Integrity +
 
+The verification of data to detect any modifications. If data is +modified enroute from the sender to the receiver, the modification will +be detected. +
 
+ +- HMAC +
 
+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. +
 
+ +- Key management +
 
+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. +
 
+ +- Man-in-the-middle attack +
 
+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. +
 
+ +- Message Authentication Code (MAC) +
 
+MAC provides message integrity by computing the MAC using a secret +key authentication algorithm (HMAC). +
 
+ +- Perfect Forward Secrecy (PFS) +
 
+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. +
 
+ +- Rekey +
 
+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. +
 
+ +- Symmetric cryptosystem +
 
+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. -- 2.24.0