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