updates.

diff --git a/doc/draft-riikonen-silc-spec-03.nroff b/doc/draft-riikonen-silc-spec-03.nroff
index d372e2cabd8d818f478e451356d42fa79d5466b0..d641b8bf1d1fb159180bb86a67c4b55833884f11 100644 (file)
--- a/doc/draft-riikonen-silc-spec-03.nroff
+++ b/doc/draft-riikonen-silc-spec-03.nroff
@@ -1953,9 +1953,9 @@ other external means for distributing the keys.  This applies for all
 messages, private messages and channel messages.  It is important to note
 that SILC, like any other security protocol is not full proof system and
 cannot secure from insecure environment; the SILC servers and routers could
-very well be hacked.  However, to provide acceptable level of security and
-usability for end user the protocol uses many times session keys or other
-keys generated by the servers to secure the messages.  If this is
+very well be compromised.  However, to provide acceptable level of security
+and usability for end user the protocol uses many times session keys or
+other keys generated by the servers to secure the messages.  If this is
 unacceptable for the client or end user, the private keys negotiatied 
 outside the SILC Network should always be used.  In the end it is always
 implementor's choice whether to negotiate private keys by default or

diff --git a/doc/whitepaper/silc_protocol.html b/doc/whitepaper/silc_protocol.html
index 0cdd8b26c0e92e59b22f7a885cd3d0462c5b0f69..18c79e267ee8551978c32eab98c40222bc92af62 100644 (file)
--- a/doc/whitepaper/silc_protocol.html
+++ b/doc/whitepaper/silc_protocol.html
@@ -128,9 +128,9 @@ deciding what way of sending private message suites for them.
 <p>
 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 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.
+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.
 <p>
 
 <img src="silc_priv1.JPG" alt="Basic Private Message Delivery" align="center" border"0">
@@ -147,8 +147,8 @@ 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 consider to be
-untrusted.
+can be decrypted by the servers and routers that the clients may consider
+to be untrusted.
 <p>
 
 If the clients on the other hand trust the servers and routers in their 
@@ -159,12 +159,13 @@ 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.
 
+
 <p><br>
 <h2>Private Message Delivery With Private Message Key</h2>
 <p>
 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
+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
@@ -198,7 +199,7 @@ 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
-may set up the SKE server running in their host and ask the other client
+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
@@ -212,6 +213,7 @@ starting the conversation.  However, using the SKE protocol is the
 recommended way to negotiate the private message key since it can be
 automized and does not cause any extra tasks for end user.
 
+
 <p><br>
 <h2>Private Message Delivery With Public Key Encryption</h2>
 <p>