Added SILC Thread Queue API
[silc.git] / public_html / html / cryptofaq.php
index 11c4f7f2528d97a52097acc3e302e8e7c1f8435a..c33f421341b802eeebc1c75665a01dca0756070b 100644 (file)
 1.7 What other algorithms SILC support?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_80" class="normal">
 1.8 What encryption modes SILC support?</a><br />
+&nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_85" class="normal">
+1.9 Is CBC mode going to be replaced in SILC?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_90" class="normal">
-1.9 What hash functions SILC support?</a><br />
+1.10 What hash functions SILC support?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_100" class="normal">
-1.10 What public key algorithms SILC support?</a><br />
+1.11 What public key algorithms SILC support?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_110" class="normal">
-1.11 Does SILC support PGP keys?</a><br />
+1.12 Does SILC support PGP keys?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_120" class="normal">
-1.12 Does SILC support SSH keys?</a><br />
+1.13 Does SILC support SSH keys?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_130" class="normal">
-1.13 Does SILC support X.509 certificates?</a><br />
+1.14 Does SILC support X.509 certificates?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_140" class="normal">
-1.14 So SILC can be used with other keys too instead of just SILC public 
+1.15 So SILC can be used with other keys too instead of just SILC public 
    keys?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_140" class="normal">
-1.15 How the MAC is computed in SILC?</a><br />
+1.16 How the MAC is computed in SILC?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_160" class="normal">
-1.16 Why SILC does not use PGP to encrypt messages?</a><br />
+1.17 Why SILC does not use PGP to encrypt messages?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_170" class="normal">
-1.17 Why SILC does not use TLS/SSL to encrypt messages?</a><br />
+1.18 Why SILC does not use TLS/SSL to encrypt messages?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_180" class="normal">
-1.18 Why SILC does not use SSH tunneling or IPSEC to encrypt messages?</a><br />
+1.19 Why SILC does not use SSH tunneling or IPSEC to encrypt messages?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_190" class="normal">
-1.19 How is the transport in SILC protected then?</a><br />
+1.20 How is the transport in SILC protected then?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_200" class="normal">
-1.20 Do I understand you correctly that TLS/SSL + PGP would be same as
+1.21 Do I understand you correctly that TLS/SSL + PGP would be same as
    SILCs own protection now?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_210" class="normal">
-1.21 Are you also saying that a chat protocol using TLS/SSL alone is not 
+1.22 Are you also saying that a chat protocol using TLS/SSL alone is not 
    actually sufficient (like IRC+SSL)?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_220" class="normal">
-1.22 Are you also saying that a chat protocol using PGP alone is not
+1.23 Are you also saying that a chat protocol using PGP alone is not
    actually sufficient (like ICQ+PGP)?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_230" class="normal">
-1.23 So chat protocol always needs both secured transport and secured 
+1.24 So chat protocol always needs both secured transport and secured 
    messages, right?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_240" class="normal">
-1.24 What is the purpose of the SILC key exchange (SKE) protocol?</a><br />
+1.25 What is the purpose of the SILC key exchange (SKE) protocol?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_250" class="normal">
-1.25 How does SKE protocol protect against man-in-the-middle attacks which can be used to attack Diffie-Hellman?</a><br />
+1.26 How does SKE protocol protect against man-in-the-middle attacks which can be used to attack Diffie-Hellman?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_260" class="normal">
-1.26 Would have it been possible to use some other key exchange protocol
+1.27 Would have it been possible to use some other key exchange protocol
    in SILC instead of developing SKE?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_270" class="normal">
-1.27 Should I verify the public key of the server when I connect to it?</a><br />
+1.28 Should I verify the public key of the server when I connect to it?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_280" class="normal">
-1.28 Should I verify all other public keys in SILC?</a><br />
+1.29 Should I verify all other public keys in SILC?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_290" class="normal">
-1.29 Why SILC does not used OpenSSL crypto library instead of its own?</a><br />
+1.30 Why SILC does not used OpenSSL crypto library instead of its own?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_300" class="normal">
-1.30 Is it possible to digitally sign messages in SILC?</a><br />
+1.31 Is it possible to digitally sign messages in SILC?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_310" class="normal">
-1.31 I am a Harry Hacker, and I want to crack your protocol.  What would be
+1.32 I am a Harry Hacker, and I want to crack your protocol.  What would be
    the best way to attack SILC protocol?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_320" class="normal">
-1.32 What could happen if a server in SILC network would become compromised?</a><br />
+1.33 What could happen if a server in SILC network would become compromised?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_330" class="normal">
-1.33 What could happen if a router would become compromised?</a><br />
+1.34 What could happen if a router would become compromised?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_340" class="normal">
-1.34 Is my channel messages protected on compromised server or not?</a><br />
+1.35 Is my channel messages protected on compromised server or not?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_350" class="normal">
-1.35 Is my private messages protected on compromised server or not?</a><br />
+1.36 Is my private messages protected on compromised server or not?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_360" class="normal">
-1.36 Should I then always use private keys for all messages?</a><br />
+1.37 Should I then always use private keys for all messages?</a><br />
 &nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_370" class="normal">
-1.37 How likely is it that some server would become compromised?</a><br />
+1.38 How likely is it that some server would become compromised?</a><br />
+&nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_380" class="normal">
+1.39 It is said SILC is designed security in mind from the day one. What does it mean?<a><br />
+&nbsp;&nbsp;&nbsp;&nbsp;<a href="#f1_390" class="normal">
+1.40 If someone joins/leaves the channel, how is assured that he cannot decrypt old/new channel messages?</a><br />
 
 <br />&nbsp;<br />
 
@@ -96,7 +102,8 @@ A: This FAQ answers questions regarding cryptography and security in SILC
    understand a bit more about cryptography and security.  When we make 
    claims or assumptions about security issues we always try to include 
    the reference to the answer which then can be used to learn more about 
-   the specific security issue.
+   the specific security issue.  Also, all claims about SILC's security
+   are made only when we can prove them.
 <br />&nbsp;<br />
 
 <a name="f1_20"></a>
@@ -154,6 +161,17 @@ A: The required mode is currently CBC.  Other modes are optional.
    NIST finalizes its selection process for these modes.
 <br />&nbsp;<br />
 
+<a name="f1_85"></a>
+<samp class="highlight">Q: Is CBC mode going to be replaced in SILC?</samp><br />
+A: Even if new encryption mode like CTR is introduced to SILC protocol the 
+CBC mode will not likely go away.  Recently new attacks has been 
+introduced to the traditional CBC (IV is the previous ciphertext block),
+so looking additional modes for the future is wise.  Another possiblity
+is to change the CBC to be so called randomized CBC (all IVs are random), 
+however most likely this will not be done in SILC.  Rather, new modes will
+be introduced instead.
+<br />&nbsp;<br />
+
 <a name="f1_90"></a>
 <samp class="highlight">Q: What hash functions SILC support?</samp><br />
 A: The required hash function is SHA-1, but also the MD5 is added to the
@@ -209,6 +227,20 @@ A: The MAC for SILC packet in the secure binary packet protocol is
    Also the channel message MAC is computed from plaintext when channel
    message is sent.
 <br />&nbsp;<br />
+   In recent times there has been research on the MAC computation orders
+   and under formal analysis the MAC computation order Encrypt-and-MAC
+   (MAC is computed from plaintext) has been found to be vulnerable to 
+   various attacks.  The IPSEC (ESP) is using so called Encrypt-then-MAC
+   (MAC is computed from ciphertext) order and it was found to be the
+   only order which resisted all attacks.  However, the attacks has been 
+   highly theoretical and no practical attacks exist as of today.  
+   Also, other security protocols using same MAC computation order as SILC 
+   are for example SSH and TLS/SSL (Encrypt-and-MAC order).  SILC will not
+   be changing the MAC computation order, instead in the future so called
+   "authenticated encryption" modes will be used which provides both
+   privacy and integrity which renders the probable MAC order problem 
+   void.
+<br />&nbsp;<br />
 
 <a name="f1_160"></a>
 <samp class="highlight">Q: Why SILC does not use PGP to encrypt messages?</samp><br />
@@ -568,3 +600,32 @@ A: Like said in last questions all these scenarios were hypothetical, and
    a whole lot of other stuff is compromised too, not just SILC server.
 <br />&nbsp;<br />
 
+<a name="f1_380"></a>
+<samp class="highlight">Q: It is said SILC is designed security in mind
+from the day one. What does it mean?</samp><br />
+A: It means that when SILC was designed it was designed as security
+protocol, not as conferencing protocol which has security features.  It
+means that security was the top priority and security issues was analyzed
+when adding new features to the protocol.  It also means, that SILC was
+designed from attacker's point of view.  Instead of just adding security
+measures to the protocol we first analyzed attacks against the protocol
+(and other protocols) and then designed the SILC to resist the attacks.
+The protocol of course easily gets very complex and then analyzing gets 
+harder and harder, new attacks are discovered that we didn't know about,
+and for this reason the analyzing is constant and ongoing process.
+<br />&nbsp;<br />
+
+<a name="f1_390"></a>
+<samp class="highlight">Q: If someone joins/leaves the channel, how is 
+assured that he cannot decrypt old/new channel messages?</samp><br />
+A: Channel key is always regenerated when someone joins or leaves the
+channel.  This assures that it is not possible to decrypt channel messages
+before you have joined the channel, you cannot decrypt old channel 
+messages after you have joined the channel since they were encrypted with 
+different key, and you cannot decrypt channel message after leaving the 
+channel since all new messages will be encrypted with differnet key.  In 
+short, you will know the channel key only when you are joined on the 
+channel, and this is the only time when channel messages can be sent or 
+received.
+<br />&nbsp;<br />
+