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 />
93 <samp class="highlight">Q: What is this FAQ?</samp><br />
94 A: This FAQ answers questions regarding cryptography and security in SILC
95 protocol and implementation. It attempts to answer the most
96 frequently asked questions that normal users ask. It also try
97 to be detailed enough to give precise answers for those who already
98 understand a bit more about cryptography and security. When we make
99 claims or assumptions about security issues we always try to include
100 the reference to the answer which then can be used to learn more about
101 the specific security issue.
105 <samp class="highlight">Q: I found incorrect information in the FAQ, who do I notify?</samp><br />
106 A: If you think that some information is incorrect in this FAQ you may
107 send your comments to the
108 <a href="mailto:info@silcnet.org" class="normal">info@silcnet.org</a> email address.
112 <samp class="highlight">Q: Your FAQ does not answer my questions, where can I send my question?</samp><br />
113 A: If you have questions that you think should be part of this FAQ you
115 <a href="mailto:info@silcnet.org" class="normal">info@silcnet.org</a> email address.
119 <samp class="highlight">Q: I have found a security problem in SILC protocol/implementation. Who should I notify?</samp><br />
120 A: If you find a security problem either in the protocol or in the
121 implementation we would appreciate it if you let us know about it first
122 before doing anything else. You can send us email to
123 <a href="mailto:security@silcnet.org" class="normal">security@silcnet.org</a>
124 if you think you have found a security problem.
128 <samp class="highlight">Q: Does SILC support AES?</samp><br />
129 A: Yes, the AES with 256 bit encryption key is required in SILC protocol.
130 The required encryption mode with AES is CBC. SILC also supports other
131 algorithms but they are optional.
135 <samp class="highlight">Q: Does SILC support DES or 3DES?</samp><br />
136 A: Only the AES is required algorithm in SILC protocol. DES or 3DES has
137 not been added to the SILC specification. However, the SILC key
138 exchange protocol is very flexible and you can negotiate to use DES
139 or 3DES if you want, but officially SILC does not support DES or 3DES.
143 <samp class="highlight">Q: What other algorithms SILC support?</samp><br />
144 A: Like said, only the AES is required. The protocol specification also
145 lists optional algorithms like Twofish, CAST, RC6, etc., and you can
146 negotiate other algorithms as well during the SILC key exchange
151 <samp class="highlight">Q: What encryption modes SILC support?</samp><br />
152 A: The required mode is currently CBC. Other modes are optional.
153 However, there has been discussion on adding additional required mode,
154 for example CTR mode. In the future, SILC is also going to have
155 support for so called "authenticated encryption" modes as soon as
156 NIST finalizes its selection process for these modes.
160 <samp class="highlight">Q: Is CBC mode going to be replaced in SILC?</samp><br />
161 A: Even if new encryption mode like CTR is introduced to SILC protocol the
162 CBC mode will not likely go away. Recently new attacks has been
163 introduced to the traditional CBC (IV is the previous ciphertext block),
164 so looking additional modes for the future is wise. Another possiblity
165 is to change the CBC to be so called randomized CBC (all IVs are random),
166 however most likely this will not be done in SILC. Rather, new modes will
167 be introduced instead.
171 <samp class="highlight">Q: What hash functions SILC support?</samp><br />
172 A: The required hash function is SHA-1, but also the MD5 is added to the
173 specification as optional hash function. The SHA-1 is also the
174 required hash function when used as part of HMAC to provide integrity
175 protection for encrypted packets.
178 <a name="f1_100"></a>
179 <samp class="highlight">Q: What public key algorithms SILC support?</samp><br />
180 A: The required public key algorithm is RSA, but optional support is
181 for DSS. The RSA algorithm in SILC supports PKCS#1 standard. During
182 the key exchange protocol also Diffie-Hellman public key algorithm
183 is used to exchange keys. The Diffie-Hellman in SILC supports PKCS#3
184 standard. Adding support for other algorithms like El Gamal is
185 possible by negotiating them in SILC key exchange.
188 <a name="f1_110"></a>
189 <samp class="highlight">Q: Does SILC support PGP keys?</samp><br />
190 A: PGP keys, or as they are officially called OpenPGP certificates are
191 supported in SILC protocol. Current implementation however does not
192 yet have support for them.
195 <a name="f1_120"></a>
196 <samp class="highlight">Q: Does SILC support SSH keys?</samp><br />
197 A: SSH2 public keys are supported in SILC protocol. Current
198 implementation however does not yet have support for them.
201 <a name="f1_130"></a>
202 <samp class="highlight">Q: Does SILC support X.509 certificates?</samp><br />
203 A: Yes, X.509 certificates are supported in SILC protocol. Current
204 implementation however does not yet have support for them. After the
205 support is added then adding support also for CRLs and also perhaps
206 OCSP will be added to the implementation.
209 <a name="f1_140"></a>
210 <samp class="highlight">Q: So SILC can be used with other keys too instead of just SILC public keys?</samp><br />
211 A: Yes, that's the purpose of having support for other public keys and
212 certificates. The implementation most likely still wants to create
213 you a SILC key pair, but if you have for example PGP key pair that
214 would be the one you are using in SILC.
217 <a name="f1_150"></a>
218 <samp class="highlight">Q: How the MAC is computed in SILC?</samp><br />
219 A: The MAC for SILC packet in the secure binary packet protocol is
220 computed always before encryption from the plaintext, and the MAC
221 is appended at the end of the SILC packet, and is never encrypted.
222 Also the channel message MAC is computed from plaintext when channel
226 <a name="f1_160"></a>
227 <samp class="highlight">Q: Why SILC does not use PGP to encrypt messages?</samp><br />
228 A: We know it is hard to understand why PGP is not used to encrypt
229 messages in SILC, but things in cryptography is never as simple as
230 they seem to be. PGP alone is not suitable to be used and does not
231 meet the security requirements in SILC, and therefore is not secure
232 enough to be used alone in SILC-like network
233 <a href="http://www.counterpane.com/chotext.html" class="normal">[1]</a>,
234 <a href="http://www.counterpane.com/pgp-attack.html" class="normal">[2]</a>.
237 However, PGP can be used with SILC. It is entirely possible to
238 use PGP to encrypt and/or sign messages in SILC, but as primary
239 protection PGP is not sufficient.
242 <a name="f1_170"></a>
243 <samp class="highlight">Q: Why SILC does not use TLS/SSL to encrypt messages?</samp><br />
244 A: The transport layer alone cannot provide security for individual
245 messages which are not point to point in nature. The TLS/SSL protects
246 only point to point traffic arbitrarily and using that to protect
247 for example private message which has no correlation to the actual
248 transport makes no sense. The messages need to be protected
249 with message specific keys, for example channel messages are protected
250 with channel keys. The transport in SILC is protected as well with
251 session keys (point to point), which would be analogous to using
252 TLS/SSL, but there is no specific reason to use TLS/SSL for that in
256 <a name="f1_180"></a>
257 <samp class="highlight">Q: Why SILC does not use SSH tunneling or IPSEC to encrypt messages?</samp><br />
258 A: For the same reasons as why it is not using TLS/SSL.
261 <a name="f1_190"></a>
262 <samp class="highlight">Q: How is the transport in SILC protected then?</samp><br />
263 A: The transport is protected with session keys negotiated during the
264 SILC key exchange protocol. SILC protocol defines secure binary packet
265 protocol, which provides encrypted and authenticated binary packets.
266 All data in SILC are sent using this secure binary packet protocol
267 and all packets are automatically encrypted. This is analogous of
268 using TLS/SSL to protect the socket layer, except that SILC defines
269 the binary packet protocol itself. Another example of protocol having
270 its own secure binary packet protocol is SSH, and it is analogous to
274 But note that protecting the transport is not sufficient enough to
275 protect individual messages. Transport is just arbitrary data point
276 to point, where as channel message for example is a message from one
277 sender to many recipients and requires different kind of protection.
278 Protecting transport is one thing, and protecting messages end to end
282 <a name="f1_200"></a>
283 <samp class="highlight">Q: Do I understand you correctly that TLS/SSL + PGP would be same as SILCs own protection now?</samp><br />
284 A: TLS/SSL + PGP + something else too, would be about same, but the end
285 result would be really ad hoc solution since these are separate,
286 external security protocols and not something designed to work
287 together. Also, at the time SILC was designed OpenPGP standard did
288 not exist so using it would have been out of question anyway. Your
289 favorite chat protocol does not suddenly become secure when you start
290 slapping different security protocols on top of it. It requires
291 thorough planning and designing to work in secure manner.
294 SILC has been designed the security in mind from the day one and
295 for this reason securing the transport and providing end to end
296 security for private messages, channel messages and other messages
297 is integrated. The end result would have not been as secure if
298 external protocols would have been just applied over insecure
299 chat protocol hoping for the best. Now they are integrated and
300 designed to work together, and there is no need to apply external
304 <a name="f1_210"></a>
305 <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 />
306 A: If it is used alone (no other protection), then basicly that's what I'm
307 saying, but of course things are not that simple. If the TLS/SSL is
308 used correctly, that is, all points in the chat network are protected
309 then it can provide security. But if even one point in the chat
310 network is not secured then the entire network can be considered
311 compromised. Also, if one server in the network is compromised then
312 entire network and all messages are compromised since messages are not
313 actually secure, only the transport. Ask yourself this: If you remove
314 the TLS/SSL, is your message secured or not? If you answer no, then
315 it doesn't provide sufficient security for chat networks. Also, note
316 that it does not provide message authentication, only packet data
317 authentication, and that is not the same thing (a packet is point to
318 point, a message is not).
321 <a name="f1_220"></a>
322 <samp class="highlight">Q: Are you also saying that a chat protocol using PGP alone is not actually sufficient (like ICQ+PGP)?</samp><br />
323 A: Here I assume protocols that just protect the message with PGP, then
324 yes, that's what I am saying. This is even more serious than
325 those using just TLS/SSL. Why? Because there is no packet protection
326 at all, only message protection. The message may be encrypted and
327 authenticated but the packet is not. This allows attacks like forgery
328 attacks, plaintext and ciphertext tampering, reply and out of order
329 delivery attacks, chosen ciphertext attacks, even adaptive chosen
331 <a href="http://www.counterpane.com/chotext.html" class="normal">[1]</a>,
332 <a href="http://www.counterpane.com/pgp-attack.html" class="normal">[2]</a>,
333 and many more. Some of these attacks may be rendered ineffective by
334 doing the implementation carefully but the protocol remains broken
338 <a name="f1_230"></a>
339 <samp class="highlight">Q: So chat protocol always needs both secured transport and secured messages, right?</samp><br />
340 A: Yes, you got it now! And SILC provides exactly that. Its transport
341 is secured with the secure binary packet protocol and it provides
342 message encryption and authentication.
345 <a name="f1_240"></a>
346 <samp class="highlight">Q: What is the purpose of the SILC key exchange (SKE) protocol?</samp><br />
347 A: The primary purpose of the SILC key exchange protocol is to create
348 session key for protecting the traffic between the client and the
349 server. It is executed always when client connects to the server.
350 It can also be used to create other key material for other sessions,
351 like file transfer session. The SKE use Diffie-Hellman for key
352 exchange algorithm, and supports digital signatures and mutual
353 authentication. The SKE is based on SSH2, STS and OAKLEY key exchange
354 protocols. The SKE is also used to negotiate the security properties
355 that are going to be used in the session. These properties are
356 the encryption algorithm, HMAC, public key algorithm, hash
357 algorithm, key lengths, encryption modes, etc.
360 <a name="f1_250"></a>
361 <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 />
362 A: Diffie-Hellman is known to be vulnerable to man-in-the-middle attack
363 when it is used alone. For that reason it must not be used alone
364 ever. In SILC key exchange (SKE) protocol digital signatures are
365 used to prevent the man-in-the-middle attacks. Using digital
366 signatures with Diffie-Hellman is the common way to avoid these
367 problems, and in addition it provides peer authentication at the
368 same time. Other key exchange protocols which use Diffie-Hellman
369 with digital signatures too are IKE, SSH2, TLS/SSL, and many more.
372 Naturally, in the end the user and the application is responsible of
373 avoiding the man-in-the-middle attack; the public key of the remote
374 must be verified before trusting it. If this is not done, then
375 the digital signatures makes no difference. This is the case with
376 any key exchange protocol using digital signatures.
379 <a name="f1_260"></a>
380 <samp class="highlight">Q: Would have it been possible to use some other key exchange protocol in SILC instead of developing SKE?</samp><br />
381 A: At the time SILC was developed the answer was simply no, it would have
382 not been possible. The problem often is that security protocols tend
383 to develop their own key exchange protocols even though at least
384 theoretically it would be possible and wise to use protocol which
385 is proved secure. In practice this is never done. TLS/SSL has its
386 own key exchange, SSH has its own key exchange, and SILC has its
387 own key exchange. When the Internet Key Exchange (IKE) protocol was
388 being developed it was our hope that it would have become general
389 purpose key exchange protocol but the reality was that it was tightly
390 developed for IPSEC instead. The end result is that it would be
391 huge overkill to use IKE with any other protocol than IPSEC.
394 <a name="f1_270"></a>
395 <samp class="highlight">Q: Should I verify the public key of the server when I connect to it?</samp><br />
396 A: Definitely yes. Commonly in security protocols which does not use
397 certificates by default the public key is verified in the first time
398 it is received and then it is cached on local disk. In SILC the same
399 thing is done. When you connect the very first time to the server
400 you will be prompted to verify and accept the public key. This is the
401 time when you should (must) verify the public key. After accepting
402 the key it is saved locally and used later to do the verification
403 automatically. This is same as with SSH; you accept the SSH server
404 key the very first time and then cache it locally for later use.
407 The moral is this: you always must verify all public keys to be
408 certain that man-in-the-middle attack is not in progress. It is your
409 risk to take if you do not verify the key.
412 <a name="f1_280"></a>
413 <samp class="highlight">Q: Should I verify all other public keys in SILC?</samp><br />
414 A: Definitely yes. You can receive public keys when you negotiate for
415 example private message key with some other client, and you must
416 verify the key before accepting it. Reason are same as in previous
420 <a name="f1_290"></a>
421 <samp class="highlight">Q: Why SILC does not used OpenSSL crypto library instead of its own?</samp><br />
422 A: The OpenSSL crypto library as you know it now did not even exist
423 when the SILC crypto library was developed in 1997. The SSLeay
424 crypto library which was the predecessor of OpenSSL package did
425 exist but was not suitable for our use at the time.
428 Now that OpenSSL crypto library is popular, it still is not
429 sufficient enough for us. SILC specification requires AES algorithm
430 but OpenSSL crypto library as of this writing (Oct 2002) still does not
431 support it. This alone makes the OpenSSL crypto library impossible
435 Also, we feel that using different crypto libraries and using the one
436 we have developed over the years is good in the end for everybody. A
437 bug that would affect SILC may not then affect OpenSSL, and on the
438 other hand bug that would affect OpenSSL crypto library may not then
439 affect SILC. Diversity also in crypto libraries is a good thing.
442 Finally, in our opinion SILC crypto library is equally good or even
443 better than OpenSSL crypto library.
446 <a name="f1_300"></a>
447 <samp class="highlight">Q: Is it possible to digitally sign messages in SILC?</samp><br />
448 A: Yes, this is possible, however the detailed definition of how this is
449 done with different public keys/certificates has not yet been defined
450 as of this writing (Oct 2002). The next protocol version 1.2 will
451 define this and it will be added to the implementation immediately.
454 <a name="f1_310"></a>
455 <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 />
456 A: Hehe. There is no simple answer to this question. Designing a
457 security protocol is extremely difficult. It is actually more
458 difficult than, say, designing an encryption algorithm. Why? Because
459 security protocols tend to be so complex. And even when they are
460 not complex they are always more complex than just one cryptographic
461 primitive like encryption algorithm. Now, attacking cryptographic
462 algorithm to break the protocol is usually never the best way to
463 go about since the attacks against algorithms are usually just
464 theoretical and hard to mount. Attacking the protocol as a whole may
465 also be pretty difficult since the operations in the protocol are
466 usually protected by those cryptographic primitives. The best way of
467 attacking any security protocol is usually to attack the
468 implementation, since that's the number one source of problems in
472 However, I don't know whether you want to analyze the protocol
473 itself, in an attempt to try to find security holes or weaknesses in
474 the protocol, or whether you want to just break the protocol. If you
475 want to do the first, then the best way to go about is to learn all
476 the details about SILC protocol, how it works, how the implementation
477 is supposed to work, and what security measures are used in the
478 protocol. Then you start analyzing the protocol and trying to look
479 for obvious mistakes. Then you can try to apply some attacks you know
480 about to the protocol and see what would happen. If you want to
481 do the second then you probably need to get your hands dirty and
482 try to figure out ways to do it in practice by finding implementation
483 problems, design problems and applying attacks in practice to the
484 implementation you are using. Also, always think big. Protocols are
485 not used in a class jar, they are used by human beings in a real world
486 and you can break a protocol by not attacking the protocol at all, but
487 by attacking something from the side.
490 <a name="f1_320"></a>
491 <samp class="highlight">Q: What could happen if a server in SILC network would become compromised?</samp><br />
492 A: This is of course hypothetical but let's assume the entire server would
493 be in the hands of malicious attacker and he can control everything
494 that happens in the server. This would of course mean that the
495 attacker has compromised the entire machine, not just SILC server.
496 He also would have replaced the original SILC server with tampered
497 version which the attacker can control. It would not be nice
498 situation. First, all local connections to the server would be
499 compromised since the server knows the session keys for local
500 connections. Second, all channels that the server has locally joined
501 users would be compromised since the server knows those channel keys.
502 However, other invite-only, private or secret channels would not be
503 compromised since the attacker has no access to those channels. Also
504 channels that are using channel private keys would not be compromised.
505 Third, all data and messages protected with session keys would be
506 compromised. However, all messages protected with private keys, like
507 private message keys, and channel private keys would not be
508 compromised since the server does not know these keys.
511 So it would not be pretty sight, but it's same with any security
512 protocol like SSH. If SSH server is compromised then there's not
513 much you can do. In SILC however you can still do something; you
514 can decide to use private keys to protect all messages. Servers
515 do not know these keys so even if the server is compromised it would
516 be safe. It cannot decrypt those messages. So, in SILC there is
517 always the fallback to something else. This is important in security
518 protocols; how can you make the protocol secure even if it partially
519 fails? Answer is by having fallbacks that are available if something
520 fails. Fallback after the other. As long it fallbacks to something
521 that provides security it is better than nothing. Another problem
522 is of course that of how fast the protocol is able to recover from
523 these security failures. This is more complicated matter however,
524 but naturally the compromised server need to be removed from the
525 network as soon as possible. The protocol recovers then immediately.
528 <a name="f1_330"></a>
529 <samp class="highlight">Q: What could happen if a router would become compromised?</samp><br />
530 A: The situation would be similar to having compromised server except
531 that router knows all locally (in the router, ie. in the cell) created
532 channels, so all local channels that are not using channel private
533 keys would be compromised. However, channels that are created on other
534 routers, and if there are no local users on those channels in the
535 router, would not be compromised, since channel keys are cell specific.
538 <a name="f1_340"></a>
539 <samp class="highlight">Q: Is my channel messages protected on compromised server or not?</samp><br />
540 A: If you are using channel private key then always yes. If the
541 compromised server does not know about the channel then always yes.
542 If you are not using channel private key, and the server knows the
543 current channel key then no, if the server is compromised. But note
544 that if some server in the network is compromised it does not
545 automatically mean that your channel messages are compromised.
548 <a name="f1_350"></a>
549 <samp class="highlight">Q: Is my private messages protected on compromised server or not?</samp><br />
550 A: If you are using private message keys then always yes. If you are not
551 using then no, if the server is compromised and the private message
552 passes through the compromised server. Again, a compromised server
553 in network does not automatically mean that private message is
554 compromised. Also the structure of the network in SILC is designed
555 so that messages do not go to servers unless they really need to
556 do so (since there is no tree-like network structure, where messages
557 could pass through several servers).
560 <a name="f1_360"></a>
561 <samp class="highlight">Q: Should I then always use private keys for all messages?</samp><br />
562 A: If you think that the network or server you are using is not something
563 you can trust in any degree then yes. If the server is your company's
564 internal SILC server then I guess you may even trust it. It is your
565 decision and you decide what is the acceptable level of risk you are
566 willing to take, and what is your required level of security. For
567 private messages using private keys is trivial since you can
568 automatically negotiate the keys with SKE. Using channel private key
569 is however more complicated since all users in the channel need to
570 know the key in order to be able to talk on the channel. It may be
571 for example pre-shared key that all users on the channel know.
574 <a name="f1_370"></a>
575 <samp class="highlight">Q: How likely is it that some server would become compromised?</samp><br />
576 A: Like said in last questions all these scenarios were hypothetical, and
577 if the server is not compromised then there are no problems of the
578 kind just discussed. It is very hard to say how likely it is. It is
579 unlikely, but a possibility. Server administrators must keep the
580 machine protected in general too, since if the machine is compromised
581 a whole lot of other stuff is compromised too, not just SILC server.
projects / silc.git / blob