From 11dd6d052fb67eca256f7f2379fe88d16b81e962 Mon Sep 17 00:00:00 2001 From: Pekka Riikonen Date: Sun, 29 Jul 2001 20:54:46 +0000 Subject: [PATCH] updates. --- doc/draft-riikonen-silc-spec-03.nroff | 6 +++--- doc/whitepaper/silc_protocol.html | 16 +++++++++------- 2 files changed, 12 insertions(+), 10 deletions(-) diff --git a/doc/draft-riikonen-silc-spec-03.nroff b/doc/draft-riikonen-silc-spec-03.nroff index d372e2ca..d641b8bf 100644 --- 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 0cdd8b26..18c79e26 100644 --- 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.

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.

Basic Private Message Delivery @@ -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.

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. +


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 +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. +


Private Message Delivery With Public Key Encryption

-- 2.24.0