2 <b><big>SILC Crypto FAQ</big></b>
5 <a href="#f1_10" class="normal">
6 1.1 What is this FAQ?</a><br />
7 <a href="#f1_20" class="normal">
8 1.2 I found incorrect information in the FAQ, who do I notify?</a><br />
9 <a href="#f1_30" class="normal">
10 1.3 Your FAQ does not answer my questions, where can I send my question?</a><br />
11 <a href="#f1_40" class="normal">
12 1.4 I have found a security problem in SILC protocol/implementation. Who
13 should I notify?</a><br />
14 <a href="#f1_50" class="normal">
15 1.5 Does SILC support AES?</a><br />
16 <a href="#f1_60" class="normal">
17 1.6 Does SILC support DES or 3DES?</a><br />
18 <a href="#f1_70" class="normal">
19 1.7 What other algorithms SILC support?</a><br />
20 <a href="#f1_80" class="normal">
21 1.8 What encryption modes SILC support?</a><br />
22 <a href="#f1_85" class="normal">
23 1.9 Is CBC mode going to be replaced in SILC?</a><br />
24 <a href="#f1_90" class="normal">
25 1.10 What hash functions SILC support?</a><br />
26 <a href="#f1_100" class="normal">
27 1.11 What public key algorithms SILC support?</a><br />
28 <a href="#f1_110" class="normal">
29 1.12 Does SILC support PGP keys?</a><br />
30 <a href="#f1_120" class="normal">
31 1.13 Does SILC support SSH keys?</a><br />
32 <a href="#f1_130" class="normal">
33 1.14 Does SILC support X.509 certificates?</a><br />
34 <a href="#f1_140" class="normal">
35 1.15 So SILC can be used with other keys too instead of just SILC public
37 <a href="#f1_140" class="normal">
38 1.16 How the MAC is computed in SILC?</a><br />
39 <a href="#f1_160" class="normal">
40 1.17 Why SILC does not use PGP to encrypt messages?</a><br />
41 <a href="#f1_170" class="normal">
42 1.18 Why SILC does not use TLS/SSL to encrypt messages?</a><br />
43 <a href="#f1_180" class="normal">
44 1.19 Why SILC does not use SSH tunneling or IPSEC to encrypt messages?</a><br />
45 <a href="#f1_190" class="normal">
46 1.20 How is the transport in SILC protected then?</a><br />
47 <a href="#f1_200" class="normal">
48 1.21 Do I understand you correctly that TLS/SSL + PGP would be same as
49 SILCs own protection now?</a><br />
50 <a href="#f1_210" class="normal">
51 1.22 Are you also saying that a chat protocol using TLS/SSL alone is not
52 actually sufficient (like IRC+SSL)?</a><br />
53 <a href="#f1_220" class="normal">
54 1.23 Are you also saying that a chat protocol using PGP alone is not
55 actually sufficient (like ICQ+PGP)?</a><br />
56 <a href="#f1_230" class="normal">
57 1.24 So chat protocol always needs both secured transport and secured
58 messages, right?</a><br />
59 <a href="#f1_240" class="normal">
60 1.25 What is the purpose of the SILC key exchange (SKE) protocol?</a><br />
61 <a href="#f1_250" class="normal">
62 1.26 How does SKE protocol protect against man-in-the-middle attacks which can be used to attack Diffie-Hellman?</a><br />
63 <a href="#f1_260" class="normal">
64 1.27 Would have it been possible to use some other key exchange protocol
65 in SILC instead of developing SKE?</a><br />
66 <a href="#f1_270" class="normal">
67 1.28 Should I verify the public key of the server when I connect to it?</a><br />
68 <a href="#f1_280" class="normal">
69 1.29 Should I verify all other public keys in SILC?</a><br />
70 <a href="#f1_290" class="normal">
71 1.30 Why SILC does not used OpenSSL crypto library instead of its own?</a><br />
72 <a href="#f1_300" class="normal">
73 1.31 Is it possible to digitally sign messages in SILC?</a><br />
74 <a href="#f1_310" class="normal">
75 1.32 I am a Harry Hacker, and I want to crack your protocol. What would be
76 the best way to attack SILC protocol?</a><br />
77 <a href="#f1_320" class="normal">
78 1.33 What could happen if a server in SILC network would become compromised?</a><br />
79 <a href="#f1_330" class="normal">
80 1.34 What could happen if a router would become compromised?</a><br />
81 <a href="#f1_340" class="normal">
82 1.35 Is my channel messages protected on compromised server or not?</a><br />
83 <a href="#f1_350" class="normal">
84 1.36 Is my private messages protected on compromised server or not?</a><br />
85 <a href="#f1_360" class="normal">
86 1.37 Should I then always use private keys for all messages?</a><br />
87 <a href="#f1_370" class="normal">
88 1.38 How likely is it that some server would become compromised?</a><br />
89 <a href="#f1_380" class="normal">
90 1.39 It is said SILC is designed security in mind from the day one. What does it mean?<a><br />
91 <a href="#f1_390" class="normal">
92 1.40 If someone joins/leaves the channel, how is assured that he cannot decrypt old/new channel messages?</a><br />
97 <samp class="highlight">Q: What is this FAQ?</samp><br />
98 A: This FAQ answers questions regarding cryptography and security in SILC
99 protocol and implementation. It attempts to answer the most
100 frequently asked questions that normal users ask. It also try
101 to be detailed enough to give precise answers for those who already
102 understand a bit more about cryptography and security. When we make
103 claims or assumptions about security issues we always try to include
104 the reference to the answer which then can be used to learn more about
105 the specific security issue. Also, all claims about SILC's security
106 are made only when we can prove them.
110 <samp class="highlight">Q: I found incorrect information in the FAQ, who do I notify?</samp><br />
111 A: If you think that some information is incorrect in this FAQ you may
112 send your comments to the
113 <a href="mailto:info@silcnet.org" class="normal">info@silcnet.org</a> email address.
117 <samp class="highlight">Q: Your FAQ does not answer my questions, where can I send my question?</samp><br />
118 A: If you have questions that you think should be part of this FAQ you
120 <a href="mailto:info@silcnet.org" class="normal">info@silcnet.org</a> email address.
124 <samp class="highlight">Q: I have found a security problem in SILC protocol/implementation. Who should I notify?</samp><br />
125 A: If you find a security problem either in the protocol or in the
126 implementation we would appreciate it if you let us know about it first
127 before doing anything else. You can send us email to
128 <a href="mailto:security@silcnet.org" class="normal">security@silcnet.org</a>
129 if you think you have found a security problem.
133 <samp class="highlight">Q: Does SILC support AES?</samp><br />
134 A: Yes, the AES with 256 bit encryption key is required in SILC protocol.
135 The required encryption mode with AES is CBC. SILC also supports other
136 algorithms but they are optional.
140 <samp class="highlight">Q: Does SILC support DES or 3DES?</samp><br />
141 A: Only the AES is required algorithm in SILC protocol. DES or 3DES has
142 not been added to the SILC specification. However, the SILC key
143 exchange protocol is very flexible and you can negotiate to use DES
144 or 3DES if you want, but officially SILC does not support DES or 3DES.
148 <samp class="highlight">Q: What other algorithms SILC support?</samp><br />
149 A: Like said, only the AES is required. The protocol specification also
150 lists optional algorithms like Twofish, CAST, RC6, etc., and you can
151 negotiate other algorithms as well during the SILC key exchange
156 <samp class="highlight">Q: What encryption modes SILC support?</samp><br />
157 A: The required mode is currently CBC. Other modes are optional.
158 However, there has been discussion on adding additional required mode,
159 for example CTR mode. In the future, SILC is also going to have
160 support for so called "authenticated encryption" modes as soon as
161 NIST finalizes its selection process for these modes.
165 <samp class="highlight">Q: Is CBC mode going to be replaced in SILC?</samp><br />
166 A: Even if new encryption mode like CTR is introduced to SILC protocol the
167 CBC mode will not likely go away. Recently new attacks has been
168 introduced to the traditional CBC (IV is the previous ciphertext block),
169 so looking additional modes for the future is wise. Another possiblity
170 is to change the CBC to be so called randomized CBC (all IVs are random),
171 however most likely this will not be done in SILC. Rather, new modes will
172 be introduced instead.
176 <samp class="highlight">Q: What hash functions SILC support?</samp><br />
177 A: The required hash function is SHA-1, but also the MD5 is added to the
178 specification as optional hash function. The SHA-1 is also the
179 required hash function when used as part of HMAC to provide integrity
180 protection for encrypted packets.
183 <a name="f1_100"></a>
184 <samp class="highlight">Q: What public key algorithms SILC support?</samp><br />
185 A: The required public key algorithm is RSA, but optional support is
186 for DSS. The RSA algorithm in SILC supports PKCS#1 standard. During
187 the key exchange protocol also Diffie-Hellman public key algorithm
188 is used to exchange keys. The Diffie-Hellman in SILC supports PKCS#3
189 standard. Adding support for other algorithms like El Gamal is
190 possible by negotiating them in SILC key exchange.
193 <a name="f1_110"></a>
194 <samp class="highlight">Q: Does SILC support PGP keys?</samp><br />
195 A: PGP keys, or as they are officially called OpenPGP certificates are
196 supported in SILC protocol. Current implementation however does not
197 yet have support for them.
200 <a name="f1_120"></a>
201 <samp class="highlight">Q: Does SILC support SSH keys?</samp><br />
202 A: SSH2 public keys are supported in SILC protocol. Current
203 implementation however does not yet have support for them.
206 <a name="f1_130"></a>
207 <samp class="highlight">Q: Does SILC support X.509 certificates?</samp><br />
208 A: Yes, X.509 certificates are supported in SILC protocol. Current
209 implementation however does not yet have support for them. After the
210 support is added then adding support also for CRLs and also perhaps
211 OCSP will be added to the implementation.
214 <a name="f1_140"></a>
215 <samp class="highlight">Q: So SILC can be used with other keys too instead of just SILC public keys?</samp><br />
216 A: Yes, that's the purpose of having support for other public keys and
217 certificates. The implementation most likely still wants to create
218 you a SILC key pair, but if you have for example PGP key pair that
219 would be the one you are using in SILC.
222 <a name="f1_150"></a>
223 <samp class="highlight">Q: How the MAC is computed in SILC?</samp><br />
224 A: The MAC for SILC packet in the secure binary packet protocol is
225 computed always before encryption from the plaintext, and the MAC
226 is appended at the end of the SILC packet, and is never encrypted.
227 Also the channel message MAC is computed from plaintext when channel
230 In recent times there has been research on the MAC computation orders
231 and under formal analysis the MAC computation order Encrypt-and-MAC
232 (MAC is computed from plaintext) has been found to be vulnerable to
233 various attacks. The IPSEC (ESP) is using so called Encrypt-then-MAC
234 (MAC is computed from ciphertext) order and it was found to be the
235 only order which resisted all attacks. However, the attacks has been
236 highly theoretical and no practical attacks exist as of today.
237 Also, other security protocols using same MAC computation order as SILC
238 are for example SSH and TLS/SSL (Encrypt-and-MAC order). SILC will not
239 be changing the MAC computation order, instead in the future so called
240 "authenticated encryption" modes will be used which provides both
241 privacy and integrity which renders the probable MAC order problem
245 <a name="f1_160"></a>
246 <samp class="highlight">Q: Why SILC does not use PGP to encrypt messages?</samp><br />
247 A: We know it is hard to understand why PGP is not used to encrypt
248 messages in SILC, but things in cryptography is never as simple as
249 they seem to be. PGP alone is not suitable to be used and does not
250 meet the security requirements in SILC, and therefore is not secure
251 enough to be used alone in SILC-like network
252 <a href="http://www.counterpane.com/chotext.html" class="normal">[1]</a>,
253 <a href="http://www.counterpane.com/pgp-attack.html" class="normal">[2]</a>.
256 However, PGP can be used with SILC. It is entirely possible to
257 use PGP to encrypt and/or sign messages in SILC, but as primary
258 protection PGP is not sufficient.
261 <a name="f1_170"></a>
262 <samp class="highlight">Q: Why SILC does not use TLS/SSL to encrypt messages?</samp><br />
263 A: The transport layer alone cannot provide security for individual
264 messages which are not point to point in nature. The TLS/SSL protects
265 only point to point traffic arbitrarily and using that to protect
266 for example private message which has no correlation to the actual
267 transport makes no sense. The messages need to be protected
268 with message specific keys, for example channel messages are protected
269 with channel keys. The transport in SILC is protected as well with
270 session keys (point to point), which would be analogous to using
271 TLS/SSL, but there is no specific reason to use TLS/SSL for that in
275 <a name="f1_180"></a>
276 <samp class="highlight">Q: Why SILC does not use SSH tunneling or IPSEC to encrypt messages?</samp><br />
277 A: For the same reasons as why it is not using TLS/SSL.
280 <a name="f1_190"></a>
281 <samp class="highlight">Q: How is the transport in SILC protected then?</samp><br />
282 A: The transport is protected with session keys negotiated during the
283 SILC key exchange protocol. SILC protocol defines secure binary packet
284 protocol, which provides encrypted and authenticated binary packets.
285 All data in SILC are sent using this secure binary packet protocol
286 and all packets are automatically encrypted. This is analogous of
287 using TLS/SSL to protect the socket layer, except that SILC defines
288 the binary packet protocol itself. Another example of protocol having
289 its own secure binary packet protocol is SSH, and it is analogous to
293 But note that protecting the transport is not sufficient enough to
294 protect individual messages. Transport is just arbitrary data point
295 to point, where as channel message for example is a message from one
296 sender to many recipients and requires different kind of protection.
297 Protecting transport is one thing, and protecting messages end to end
301 <a name="f1_200"></a>
302 <samp class="highlight">Q: Do I understand you correctly that TLS/SSL + PGP would be same as SILCs own protection now?</samp><br />
303 A: TLS/SSL + PGP + something else too, would be about same, but the end
304 result would be really ad hoc solution since these are separate,
305 external security protocols and not something designed to work
306 together. Also, at the time SILC was designed OpenPGP standard did
307 not exist so using it would have been out of question anyway. Your
308 favorite chat protocol does not suddenly become secure when you start
309 slapping different security protocols on top of it. It requires
310 thorough planning and designing to work in secure manner.
313 SILC has been designed the security in mind from the day one and
314 for this reason securing the transport and providing end to end
315 security for private messages, channel messages and other messages
316 is integrated. The end result would have not been as secure if
317 external protocols would have been just applied over insecure
318 chat protocol hoping for the best. Now they are integrated and
319 designed to work together, and there is no need to apply external
323 <a name="f1_210"></a>
324 <samp class="highlight">Q: Are you also saying that a chat protocol using TLS/SSL alone is not actually sufficient (like IRC+SSL)?</samp><br />
325 A: If it is used alone (no other protection), then basicly that's what I'm
326 saying, but of course things are not that simple. If the TLS/SSL is
327 used correctly, that is, all points in the chat network are protected
328 then it can provide security. But if even one point in the chat
329 network is not secured then the entire network can be considered
330 compromised. Also, if one server in the network is compromised then
331 entire network and all messages are compromised since messages are not
332 actually secure, only the transport. Ask yourself this: If you remove
333 the TLS/SSL, is your message secured or not? If you answer no, then
334 it doesn't provide sufficient security for chat networks. Also, note
335 that it does not provide message authentication, only packet data
336 authentication, and that is not the same thing (a packet is point to
337 point, a message is not).
340 <a name="f1_220"></a>
341 <samp class="highlight">Q: Are you also saying that a chat protocol using PGP alone is not actually sufficient (like ICQ+PGP)?</samp><br />
342 A: Here I assume protocols that just protect the message with PGP, then
343 yes, that's what I am saying. This is even more serious than
344 those using just TLS/SSL. Why? Because there is no packet protection
345 at all, only message protection. The message may be encrypted and
346 authenticated but the packet is not. This allows attacks like forgery
347 attacks, plaintext and ciphertext tampering, reply and out of order
348 delivery attacks, chosen ciphertext attacks, even adaptive chosen
350 <a href="http://www.counterpane.com/chotext.html" class="normal">[1]</a>,
351 <a href="http://www.counterpane.com/pgp-attack.html" class="normal">[2]</a>,
352 and many more. Some of these attacks may be rendered ineffective by
353 doing the implementation carefully but the protocol remains broken
357 <a name="f1_230"></a>
358 <samp class="highlight">Q: So chat protocol always needs both secured transport and secured messages, right?</samp><br />
359 A: Yes, you got it now! And SILC provides exactly that. Its transport
360 is secured with the secure binary packet protocol and it provides
361 message encryption and authentication.
364 <a name="f1_240"></a>
365 <samp class="highlight">Q: What is the purpose of the SILC key exchange (SKE) protocol?</samp><br />
366 A: The primary purpose of the SILC key exchange protocol is to create
367 session key for protecting the traffic between the client and the
368 server. It is executed always when client connects to the server.
369 It can also be used to create other key material for other sessions,
370 like file transfer session. The SKE use Diffie-Hellman for key
371 exchange algorithm, and supports digital signatures and mutual
372 authentication. The SKE is based on SSH2, STS and OAKLEY key exchange
373 protocols. The SKE is also used to negotiate the security properties
374 that are going to be used in the session. These properties are
375 the encryption algorithm, HMAC, public key algorithm, hash
376 algorithm, key lengths, encryption modes, etc.
379 <a name="f1_250"></a>
380 <samp class="highlight">Q: The SILC key exchange protocol is using Diffie-Hellman. How does it protect against man-in-the-middle attacks which can be used to attack Diffie-Hellman?</samp><br />
381 A: Diffie-Hellman is known to be vulnerable to man-in-the-middle attack
382 when it is used alone. For that reason it must not be used alone
383 ever. In SILC key exchange (SKE) protocol digital signatures are
384 used to prevent the man-in-the-middle attacks. Using digital
385 signatures with Diffie-Hellman is the common way to avoid these
386 problems, and in addition it provides peer authentication at the
387 same time. Other key exchange protocols which use Diffie-Hellman
388 with digital signatures too are IKE, SSH2, TLS/SSL, and many more.
391 Naturally, in the end the user and the application is responsible of
392 avoiding the man-in-the-middle attack; the public key of the remote
393 must be verified before trusting it. If this is not done, then
394 the digital signatures makes no difference. This is the case with
395 any key exchange protocol using digital signatures.
398 <a name="f1_260"></a>
399 <samp class="highlight">Q: Would have it been possible to use some other key exchange protocol in SILC instead of developing SKE?</samp><br />
400 A: At the time SILC was developed the answer was simply no, it would have
401 not been possible. The problem often is that security protocols tend
402 to develop their own key exchange protocols even though at least
403 theoretically it would be possible and wise to use protocol which
404 is proved secure. In practice this is never done. TLS/SSL has its
405 own key exchange, SSH has its own key exchange, and SILC has its
406 own key exchange. When the Internet Key Exchange (IKE) protocol was
407 being developed it was our hope that it would have become general
408 purpose key exchange protocol but the reality was that it was tightly
409 developed for IPSEC instead. The end result is that it would be
410 huge overkill to use IKE with any other protocol than IPSEC.
413 <a name="f1_270"></a>
414 <samp class="highlight">Q: Should I verify the public key of the server when I connect to it?</samp><br />
415 A: Definitely yes. Commonly in security protocols which does not use
416 certificates by default the public key is verified in the first time
417 it is received and then it is cached on local disk. In SILC the same
418 thing is done. When you connect the very first time to the server
419 you will be prompted to verify and accept the public key. This is the
420 time when you should (must) verify the public key. After accepting
421 the key it is saved locally and used later to do the verification
422 automatically. This is same as with SSH; you accept the SSH server
423 key the very first time and then cache it locally for later use.
426 The moral is this: you always must verify all public keys to be
427 certain that man-in-the-middle attack is not in progress. It is your
428 risk to take if you do not verify the key.
431 <a name="f1_280"></a>
432 <samp class="highlight">Q: Should I verify all other public keys in SILC?</samp><br />
433 A: Definitely yes. You can receive public keys when you negotiate for
434 example private message key with some other client, and you must
435 verify the key before accepting it. Reason are same as in previous
439 <a name="f1_290"></a>
440 <samp class="highlight">Q: Why SILC does not used OpenSSL crypto library instead of its own?</samp><br />
441 A: The OpenSSL crypto library as you know it now did not even exist
442 when the SILC crypto library was developed in 1997. The SSLeay
443 crypto library which was the predecessor of OpenSSL package did
444 exist but was not suitable for our use at the time.
447 Now that OpenSSL crypto library is popular, it still is not
448 sufficient enough for us. SILC specification requires AES algorithm
449 but OpenSSL crypto library as of this writing (Oct 2002) still does not
450 support it. This alone makes the OpenSSL crypto library impossible
454 Also, we feel that using different crypto libraries and using the one
455 we have developed over the years is good in the end for everybody. A
456 bug that would affect SILC may not then affect OpenSSL, and on the
457 other hand bug that would affect OpenSSL crypto library may not then
458 affect SILC. Diversity also in crypto libraries is a good thing.
461 Finally, in our opinion SILC crypto library is equally good or even
462 better than OpenSSL crypto library.
465 <a name="f1_300"></a>
466 <samp class="highlight">Q: Is it possible to digitally sign messages in SILC?</samp><br />
467 A: Yes, this is possible, however the detailed definition of how this is
468 done with different public keys/certificates has not yet been defined
469 as of this writing (Oct 2002). The next protocol version 1.2 will
470 define this and it will be added to the implementation immediately.
473 <a name="f1_310"></a>
474 <samp class="highlight">Q: I am a Harry Hacker, and I want to crack your protocol. What would be the best way to attack SILC protocol?</samp><br />
475 A: Hehe. There is no simple answer to this question. Designing a
476 security protocol is extremely difficult. It is actually more
477 difficult than, say, designing an encryption algorithm. Why? Because
478 security protocols tend to be so complex. And even when they are
479 not complex they are always more complex than just one cryptographic
480 primitive like encryption algorithm. Now, attacking cryptographic
481 algorithm to break the protocol is usually never the best way to
482 go about since the attacks against algorithms are usually just
483 theoretical and hard to mount. Attacking the protocol as a whole may
484 also be pretty difficult since the operations in the protocol are
485 usually protected by those cryptographic primitives. The best way of
486 attacking any security protocol is usually to attack the
487 implementation, since that's the number one source of problems in
491 However, I don't know whether you want to analyze the protocol
492 itself, in an attempt to try to find security holes or weaknesses in
493 the protocol, or whether you want to just break the protocol. If you
494 want to do the first, then the best way to go about is to learn all
495 the details about SILC protocol, how it works, how the implementation
496 is supposed to work, and what security measures are used in the
497 protocol. Then you start analyzing the protocol and trying to look
498 for obvious mistakes. Then you can try to apply some attacks you know
499 about to the protocol and see what would happen. If you want to
500 do the second then you probably need to get your hands dirty and
501 try to figure out ways to do it in practice by finding implementation
502 problems, design problems and applying attacks in practice to the
503 implementation you are using. Also, always think big. Protocols are
504 not used in a class jar, they are used by human beings in a real world
505 and you can break a protocol by not attacking the protocol at all, but
506 by attacking something from the side.
509 <a name="f1_320"></a>
510 <samp class="highlight">Q: What could happen if a server in SILC network would become compromised?</samp><br />
511 A: This is of course hypothetical but let's assume the entire server would
512 be in the hands of malicious attacker and he can control everything
513 that happens in the server. This would of course mean that the
514 attacker has compromised the entire machine, not just SILC server.
515 He also would have replaced the original SILC server with tampered
516 version which the attacker can control. It would not be nice
517 situation. First, all local connections to the server would be
518 compromised since the server knows the session keys for local
519 connections. Second, all channels that the server has locally joined
520 users would be compromised since the server knows those channel keys.
521 However, other invite-only, private or secret channels would not be
522 compromised since the attacker has no access to those channels. Also
523 channels that are using channel private keys would not be compromised.
524 Third, all data and messages protected with session keys would be
525 compromised. However, all messages protected with private keys, like
526 private message keys, and channel private keys would not be
527 compromised since the server does not know these keys.
530 So it would not be pretty sight, but it's same with any security
531 protocol like SSH. If SSH server is compromised then there's not
532 much you can do. In SILC however you can still do something; you
533 can decide to use private keys to protect all messages. Servers
534 do not know these keys so even if the server is compromised it would
535 be safe. It cannot decrypt those messages. So, in SILC there is
536 always the fallback to something else. This is important in security
537 protocols; how can you make the protocol secure even if it partially
538 fails? Answer is by having fallbacks that are available if something
539 fails. Fallback after the other. As long it fallbacks to something
540 that provides security it is better than nothing. Another problem
541 is of course that of how fast the protocol is able to recover from
542 these security failures. This is more complicated matter however,
543 but naturally the compromised server need to be removed from the
544 network as soon as possible. The protocol recovers then immediately.
547 <a name="f1_330"></a>
548 <samp class="highlight">Q: What could happen if a router would become compromised?</samp><br />
549 A: The situation would be similar to having compromised server except
550 that router knows all locally (in the router, ie. in the cell) created
551 channels, so all local channels that are not using channel private
552 keys would be compromised. However, channels that are created on other
553 routers, and if there are no local users on those channels in the
554 router, would not be compromised, since channel keys are cell specific.
557 <a name="f1_340"></a>
558 <samp class="highlight">Q: Is my channel messages protected on compromised server or not?</samp><br />
559 A: If you are using channel private key then always yes. If the
560 compromised server does not know about the channel then always yes.
561 If you are not using channel private key, and the server knows the
562 current channel key then no, if the server is compromised. But note
563 that if some server in the network is compromised it does not
564 automatically mean that your channel messages are compromised.
567 <a name="f1_350"></a>
568 <samp class="highlight">Q: Is my private messages protected on compromised server or not?</samp><br />
569 A: If you are using private message keys then always yes. If you are not
570 using then no, if the server is compromised and the private message
571 passes through the compromised server. Again, a compromised server
572 in network does not automatically mean that private message is
573 compromised. Also the structure of the network in SILC is designed
574 so that messages do not go to servers unless they really need to
575 do so (since there is no tree-like network structure, where messages
576 could pass through several servers).
579 <a name="f1_360"></a>
580 <samp class="highlight">Q: Should I then always use private keys for all messages?</samp><br />
581 A: If you think that the network or server you are using is not something
582 you can trust in any degree then yes. If the server is your company's
583 internal SILC server then I guess you may even trust it. It is your
584 decision and you decide what is the acceptable level of risk you are
585 willing to take, and what is your required level of security. For
586 private messages using private keys is trivial since you can
587 automatically negotiate the keys with SKE. Using channel private key
588 is however more complicated since all users in the channel need to
589 know the key in order to be able to talk on the channel. It may be
590 for example pre-shared key that all users on the channel know.
593 <a name="f1_370"></a>
594 <samp class="highlight">Q: How likely is it that some server would become compromised?</samp><br />
595 A: Like said in last questions all these scenarios were hypothetical, and
596 if the server is not compromised then there are no problems of the
597 kind just discussed. It is very hard to say how likely it is. It is
598 unlikely, but a possibility. Server administrators must keep the
599 machine protected in general too, since if the machine is compromised
600 a whole lot of other stuff is compromised too, not just SILC server.
603 <a name="f1_380"></a>
604 <samp class="highlight">Q: It is said SILC is designed security in mind
605 from the day one. What does it mean?</samp><br />
606 A: It means that when SILC was designed it was designed as security
607 protocol, not as conferencing protocol which has security features. It
608 means that security was the top priority and security issues was analyzed
609 when adding new features to the protocol. It also means, that SILC was
610 designed from attacker's point of view. Instead of just adding security
611 measures to the protocol we first analyzed attacks against the protocol
612 (and other protocols) and then designed the SILC to resist the attacks.
613 The protocol of course easily gets very complex and then analyzing gets
614 harder and harder, new attacks are discovered that we didn't know about,
615 and for this reason the analyzing is constant and ongoing process.
618 <a name="f1_390"></a>
619 <samp class="highlight">Q: If someone joins/leaves the channel, how is
620 assured that he cannot decrypt old/new channel messages?</samp><br />
621 A: Channel key is always regenerated when someone joins or leaves the
622 channel. This assures that it is not possible to decrypt channel messages
623 before you have joined the channel, you cannot decrypt old channel
624 messages after you have joined the channel since they were encrypted with
625 different key, and you cannot decrypt channel message after leaving the
626 channel since all new messages will be encrypted with differnet key. In
627 short, you will know the channel key only when you are joined on the
628 channel, and this is the only time when channel messages can be sent or
projects / silc.git / blob