updates.
[silc.git] / doc / whitepaper / silc_protocol.html
index 1549f7e7e68abd177b0ba897e56d8d325aaf3e31..4cf585f2016a2caa1bd0b3787830ff7511e2e0e5 100644 (file)
@@ -7,14 +7,14 @@
 <meta name="Author" content="Pekka Riikonen - SILC Project">
 <meta name="Description"
  content="SILC - Secure Internet Live Conferencing Protocol">
-<meta name="Created" content="Version 1.0 / 04 Aug 2001">
+<meta name="Created" content="Version 1.0 / 03 Aug 2001">
 </head>
 <body bgcolor="#ffffff">
 
 <font face="Helvetica">
 
 <font size="6"><b>SILC Protocol White Paper</b></font><br>
-<font size="2">Version 1.0 / 04 Aug 2001</font>
+<font size="2">Version 1.1 / 01 Jan 2002</font>
 
 <p>
 <h1>Introduction</h1>
@@ -62,11 +62,11 @@ and how the protocol works in practice.  This document is intended for all
 audience.  This document should be easy to understand for non-technical
 person and still be detailed enough for technically oriented person.  See
 the section <a href="#terms">Terms and Abbreviations</a> for terms used
-in this documents.
+in this document.
 <p>
 
 <p>
-(c) Copyright 2001 Pekka Riikonen 
+(c) Copyright 2001 - 2002 Pekka Riikonen 
 (<a href="mailto:priikone at silcnet.org">priikone at silcnet.org</a>)
 <p>
 This document is free document; you can redistribute it and/or modify
@@ -93,6 +93,32 @@ protocol has been designed from the day one security in mind and it
 shows in the protocol design.
 <p>
 
+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.
+<p>
+
+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.
+<p>
+
 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.
@@ -110,6 +136,7 @@ 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.
+<p>
 
 
 <p><br>
@@ -321,7 +348,7 @@ 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 when both of the parties computes a signature
+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.
 <p>
@@ -379,7 +406,7 @@ packet is also encrypted in the case of public key authentication.
 <p>
 
 If the authentication is to fail the connection to the server or router
-will be refused.  If it is succesful the connection is granted.  After
+will be refused.  If it is successful the connection is granted.  After
 this the client is ready to communicate in the SILC Network.
 
 
@@ -471,7 +498,7 @@ for servers to decrypt the message.  The router decrypts the message
 only when sending it between two routers.
 <p>
 
-This method of channel message delivery is the the default way to send
+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
@@ -489,7 +516,7 @@ channel.
 <p>
 
 In addition of encrypting channel messages it also possible to digitally
-sign all sent channel messages.  The receiver could the verify the
+sign all sent channel messages.  The receiver could then verify the
 signature of each of the message using the sender's public key.
 
 
@@ -501,7 +528,7 @@ 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.  All servers and
+only by the clients who have joined the channel.  Servers 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
@@ -555,7 +582,7 @@ deciding what way of sending private message suites for them.
 <p>
 
 In addition of encrypting private messages it also possible to digitally
-sign all sent private messages.  The receiver could the verify the
+sign all sent private messages.  The receiver could then verify the
 signature of each of the message using the sender's public key.
 
 
@@ -574,7 +601,7 @@ re-encrypted everytime it is sent further to the receiving client.
 </object>
 <p><br>
 
-As the above diagram shows the private messages sent by Client A to the
+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
@@ -617,7 +644,7 @@ routers in the SILC network.
 </object>
 <p><br>
 
-As the above diagram shows the Client A encrypts the message with private
+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
@@ -640,10 +667,11 @@ 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.  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 exexcuted the SKE protocol.  They
-can then use that key to secure all subsequent private messages.
+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.
 <p>
 
 Using this method of private messages delivery is recommended if the
@@ -679,7 +707,7 @@ key which it uses to decrypt the message.
 </object>
 <p><br>
 
-As the above diagram shows the Client A has the Client B's public key.
+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
@@ -712,7 +740,11 @@ method of private message delivery is very simple and recommended.
 
 
 <p><br>
-<h1>Conclusions</h1>
+<h1>Secure File Transfers</h1>
+
+
+<p><br>
+<h1>Conclusion</h1>
 
 The Secure Internet Live Conferencing (SILC) protocol is a new generation
 chat protocol that provides all the common conferencing services with
@@ -779,7 +811,7 @@ it also means verifying the origin of a message.
 - Certificate
 <p>
 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 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
@@ -797,7 +829,7 @@ verification services.
 <p>
 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 lograrithms.
+of calculating discrete logarithms.
 <p>
 
 - Encryption
@@ -822,6 +854,14 @@ is not modified and that the HMAC was computed by the sender of the
 message.
 <p>
 
+- Key management
+<p>
+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.
+<p>
+
 - Man-in-the-middle attack
 <p>
 An attack against two connecting entities where the attacker executes
@@ -839,7 +879,7 @@ key authentication algorithm (HMAC).
 
 - Perfect Forward Secrecy (PFS)
 <p>
-A property of rekey (or key re-generation) which defines whether the
+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
@@ -850,7 +890,7 @@ is always derived from the old key.
 
 - Rekey
 <p>
-A key re-generation process where the old key has expired or is not
+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.
 <p>