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_90" class="normal">
23 1.9 What hash functions SILC support?</a><br />
24 <a href="#f1_100" class="normal">
25 1.10 What public key algorithms SILC support?</a><br />
26 <a href="#f1_110" class="normal">
27 1.11 Does SILC support PGP keys?</a><br />
28 <a href="#f1_120" class="normal">
29 1.12 Does SILC support SSH keys?</a><br />
30 <a href="#f1_130" class="normal">
31 1.13 Does SILC support X.509 certificates?</a><br />
32 <a href="#f1_140" class="normal">
33 1.14 So SILC can be used with other keys too instead of just SILC public
35 <a href="#f1_140" class="normal">
36 1.15 How the MAC is computed in SILC?</a><br />
37 <a href="#f1_160" class="normal">
38 1.16 Why SILC does not use PGP to encrypt messages?</a><br />
39 <a href="#f1_170" class="normal">
40 1.17 Why SILC does not use TLS/SSL to encrypt messages?</a><br />
41 <a href="#f1_180" class="normal">
42 1.18 Why SILC does not use SSH tunneling or IPSEC to encrypt messages?</a><br />
43 <a href="#f1_190" class="normal">
44 1.19 How is the transport in SILC protected then?</a><br />
45 <a href="#f1_200" class="normal">
46 1.20 Do I understand you correctly that TLS/SSL + PGP would be same as
47 SILCs own protection now?</a><br />
48 <a href="#f1_210" class="normal">
49 1.21 Are you also saying that a chat protocol using TLS/SSL alone is not
50 actually sufficient (like IRC+SSL)?</a><br />
51 <a href="#f1_220" class="normal">
52 1.22 Are you also saying that a chat protocol using PGP alone is not
53 actually sufficient (like ICQ+PGP)?</a><br />
54 <a href="#f1_230" class="normal">
55 1.23 So chat protocol always needs both secured transport and secured
56 messages, right?</a><br />
57 <a href="#f1_240" class="normal">
58 1.24 What is the purpose of the SILC key exchange (SKE) protocol?</a><br />
59 <a href="#f1_250" class="normal">
60 1.25 How does SKE protocol protect against man-in-the-middle attacks which can be used to attack Diffie-Hellman?</a><br />
61 <a href="#f1_260" class="normal">
62 1.26 Would have it been possible to use some other key exchange protocol
63 in SILC instead of developing SKE?</a><br />
64 <a href="#f1_270" class="normal">
65 1.27 Should I verify the public key of the server when I connect to it?</a><br />
66 <a href="#f1_280" class="normal">
67 1.28 Should I verify all other public keys in SILC?</a><br />
68 <a href="#f1_290" class="normal">
69 1.29 Why SILC does not used OpenSSL crypto library instead of its own?</a><br />
70 <a href="#f1_300" class="normal">
71 1.30 Is it possible to digitally sign messages in SILC?</a><br />
72 <a href="#f1_310" class="normal">
73 1.31 I am a Harry Hacker, and I want to crack your protocol. What would be
74 the best way to attack SILC protocol?</a><br />
75 <a href="#f1_320" class="normal">
76 1.32 What could happen if a server in SILC network would become compromised?</a><br />
77 <a href="#f1_330" class="normal">
78 1.33 What could happen if a router would become compromised?</a><br />
79 <a href="#f1_340" class="normal">
80 1.34 Is my channel messages protected on compromised server or not?</a><br />
81 <a href="#f1_350" class="normal">
82 1.35 Is my private messages protected on compromised server or not?</a><br />
83 <a href="#f1_360" class="normal">
84 1.36 Should I then always use private keys for all messages?</a><br />
85 <a href="#f1_370" class="normal">
86 1.37 How likely is it that some server would become compromised?</a><br />
91 <samp class="highlight">Q: What is this FAQ?</samp><br />
92 A: This FAQ answers questions regarding cryptography and security in SILC
93 protocol and implementation. It attempts to answer the most
94 frequently asked questions that normal users ask. It also try
95 to be detailed enough to give precise answers for those who already
96 understand a bit more about cryptography and security. When we make
97 claims or assumptions about security issues we always try to include
98 the reference to the answer which then can be used to learn more about
99 the specific security issue.
103 <samp class="highlight">Q: I found incorrect information in the FAQ, who do I notify?</samp><br />
104 A: If you think that some information is incorrect in this FAQ you may
105 send your comments to the
106 <a href="mailto:info@silcnet.org" class="normal">info@silcnet.org</a> email address.
110 <samp class="highlight">Q: Your FAQ does not answer my questions, where can I send my question?</samp><br />
111 A: If you have questions that you think should be part of this FAQ you
113 <a href="mailto:info@silcnet.org" class="normal">info@silcnet.org</a> email address.
117 <samp class="highlight">Q: I have found a security problem in SILC protocol/implementation. Who should I notify?</samp><br />
118 A: If you find a security problem either in the protocol or in the
119 implementation we would appreciate it if you let us know about it first
120 before doing anything else. You can send us email to
121 <a href="mailto:security@silcnet.org" class="normal">security@silcnet.org</a>
122 if you think you have found a security problem.
126 <samp class="highlight">Q: Does SILC support AES?</samp><br />
127 A: Yes, the AES with 256 bit encryption key is required in SILC protocol.
128 The required encryption mode with AES is CBC. SILC also supports other
129 algorithms but they are optional.
133 <samp class="highlight">Q: Does SILC support DES or 3DES?</samp><br />
134 A: Only the AES is required algorithm in SILC protocol. DES or 3DES has
135 not been added to the SILC specification. However, the SILC key
136 exchange protocol is very flexible and you can negotiate to use DES
137 or 3DES if you want, but officially SILC does not support DES or 3DES.
141 <samp class="highlight">Q: What other algorithms SILC support?</samp><br />
142 A: Like said, only the AES is required. The protocol specification also
143 lists optional algorithms like Twofish, CAST, RC6, etc., and you can
144 negotiate other algorithms as well during the SILC key exchange
149 <samp class="highlight">Q: What encryption modes SILC support?</samp><br />
150 A: The required mode is currently CBC. Other modes are optional.
151 However, there has been discussion on adding additional required mode,
152 for example CTR mode. In the future, SILC is also going to have
153 support for so called "authenticated encryption" modes as soon as
154 NIST finalizes its selection process for these modes.
158 <samp class="highlight">Q: What hash functions SILC support?</samp><br />
159 A: The required hash function is SHA-1, but also the MD5 is added to the
160 specification as optional hash function. The SHA-1 is also the
161 required hash function when used as part of HMAC to provide integrity
162 protection for encrypted packets.
165 <a name="f1_100"></a>
166 <samp class="highlight">Q: What public key algorithms SILC support?</samp><br />
167 A: The required public key algorithm is RSA, but optional support is
168 for DSS. The RSA algorithm in SILC supports PKCS#1 standard. During
169 the key exchange protocol also Diffie-Hellman public key algorithm
170 is used to exchange keys. The Diffie-Hellman in SILC supports PKCS#3
171 standard. Adding support for other algorithms like El Gamal is
172 possible by negotiating them in SILC key exchange.
175 <a name="f1_110"></a>
176 <samp class="highlight">Q: Does SILC support PGP keys?</samp><br />
177 A: PGP keys, or as they are officially called OpenPGP certificates are
178 supported in SILC protocol. Current implementation however does not
179 yet have support for them.
182 <a name="f1_120"></a>
183 <samp class="highlight">Q: Does SILC support SSH keys?</samp><br />
184 A: SSH2 public keys are supported in SILC protocol. Current
185 implementation however does not yet have support for them.
188 <a name="f1_130"></a>
189 <samp class="highlight">Q: Does SILC support X.509 certificates?</samp><br />
190 A: Yes, X.509 certificates are supported in SILC protocol. Current
191 implementation however does not yet have support for them. After the
192 support is added then adding support also for CRLs and also perhaps
193 OCSP will be added to the implementation.
196 <a name="f1_140"></a>
197 <samp class="highlight">Q: So SILC can be used with other keys too instead of just SILC public keys?</samp><br />
198 A: Yes, that's the purpose of having support for other public keys and
199 certificates. The implementation most likely still wants to create
200 you a SILC key pair, but if you have for example PGP key pair that
201 would be the one you are using in SILC.
204 <a name="f1_150"></a>
205 <samp class="highlight">Q: How the MAC is computed in SILC?</samp><br />
206 A: The MAC for SILC packet in the secure binary packet protocol is
207 computed always before encryption from the plaintext, and the MAC
208 is appended at the end of the SILC packet, and is never encrypted.
209 Also the channel message MAC is computed from plaintext when channel
213 <a name="f1_160"></a>
214 <samp class="highlight">Q: Why SILC does not use PGP to encrypt messages?</samp><br />
215 A: We know it is hard to understand why PGP is not used to encrypt
216 messages in SILC, but things in cryptography is never as simple as
217 they seem to be. PGP alone is not suitable to be used and does not
218 meet the security requirements in SILC, and therefore is not secure
219 enough to be used alone in SILC-like network
220 <a href="http://www.counterpane.com/chotext.html" class="normal">[1]</a>,
221 <a href="http://www.counterpane.com/pgp-attack.html" class="normal">[2]</a>.
224 However, PGP can be used with SILC. It is entirely possible to
225 use PGP to encrypt and/or sign messages in SILC, but as primary
226 protection PGP is not sufficient.
229 <a name="f1_170"></a>
230 <samp class="highlight">Q: Why SILC does not use TLS/SSL to encrypt messages?</samp><br />
231 A: The transport layer alone cannot provide security for individual
232 messages which are not point to point in nature. The TLS/SSL protects
233 only point to point traffic arbitrarily and using that to protect
234 for example private message which has no correlation to the actual
235 transport makes no sense. The messages need to be protected
236 with message specific keys, for example channel messages are protected
237 with channel keys. The transport in SILC is protected as well with
238 session keys (point to point), which would be analogous to using
239 TLS/SSL, but there is no specific reason to use TLS/SSL for that in
243 <a name="f1_180"></a>
244 <samp class="highlight">Q: Why SILC does not use SSH tunneling or IPSEC to encrypt messages?</samp><br />
245 A: For the same reasons as why it is not using TLS/SSL.
248 <a name="f1_190"></a>
249 <samp class="highlight">Q: How is the transport in SILC protected then?</samp><br />
250 A: The transport is protected with session keys negotiated during the
251 SILC key exchange protocol. SILC protocol defines secure binary packet
252 protocol, which provides encrypted and authenticated binary packets.
253 All data in SILC are sent using this secure binary packet protocol
254 and all packets are automatically encrypted. This is analogous of
255 using TLS/SSL to protect the socket layer, except that SILC defines
256 the binary packet protocol itself. Another example of protocol having
257 its own secure binary packet protocol is SSH, and it is analogous to
261 But note that protecting the transport is not sufficient enough to
262 protect individual messages. Transport is just arbitrary data point
263 to point, where as channel message for example is a message from one
264 sender to many recipients and requires different kind of protection.
265 Protecting transport is one thing, and protecting messages end to end
269 <a name="f1_200"></a>
270 <samp class="highlight">Q: Do I understand you correctly that TLS/SSL + PGP would be same as SILCs own protection now?</samp><br />
271 A: TLS/SSL + PGP + something else too, would be about same, but the end
272 result would be really ad hoc solution since these are separate,
273 external security protocols and not something designed to work
274 together. Also, at the time SILC was designed OpenPGP standard did
275 not exist so using it would have been out of question anyway. Your
276 favorite chat protocol does not suddenly become secure when you start
277 slapping different security protocols on top of it. It requires
278 thorough planning and designing to work in secure manner.
281 SILC has been designed the security in mind from the day one and
282 for this reason securing the transport and providing end to end
283 security for private messages, channel messages and other messages
284 is integrated. The end result would have not been as secure if
285 external protocols would have been just applied over insecure
286 chat protocol hoping for the best. Now they are integrated and
287 designed to work together, and there is no need to apply external
291 <a name="f1_210"></a>
292 <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 />
293 A: If it is used alone (no other protection), then basicly that's what I'm
294 saying, but of course things are not that simple. If the TLS/SSL is
295 used correctly, that is, all points in the chat network are protected
296 then it can provide security. But if even one point in the chat
297 network is not secured then the entire network can be considered
298 compromised. Also, if one server in the network is compromised then
299 entire network and all messages are compromised since messages are not
300 actually secure, only the transport. Ask yourself this: If you remove
301 the TLS/SSL, is your message secured or not? If you answer no, then
302 it doesn't provide sufficient security for chat networks. Also, note
303 that it does not provide message authentication, only packet data
304 authentication, and that is not the same thing (a packet is point to
305 point, a message is not).
308 <a name="f1_220"></a>
309 <samp class="highlight">Q: Are you also saying that a chat protocol using PGP alone is not actually sufficient (like ICQ+PGP)?</samp><br />
310 A: Here I assume protocols that just protect the message with PGP, then
311 yes, that's what I am saying. This is even more serious than
312 those using just TLS/SSL. Why? Because there is no packet protection
313 at all, only message protection. The message may be encrypted and
314 authenticated but the packet is not. This allows attacks like forgery
315 attacks, plaintext and ciphertext tampering, reply and out of order
316 delivery attacks, chosen ciphertext attacks, even adaptive chosen
318 <a href="http://www.counterpane.com/chotext.html" class="normal">[1]</a>,
319 <a href="http://www.counterpane.com/pgp-attack.html" class="normal">[2]</a>,
320 and many more. Some of these attacks may be rendered ineffective by
321 doing the implementation carefully but the protocol remains broken
325 <a name="f1_230"></a>
326 <samp class="highlight">Q: So chat protocol always needs both secured transport and secured messages, right?</samp><br />
327 A: Yes, you got it now! And SILC provides exactly that. Its transport
328 is secured with the secure binary packet protocol and it provides
329 message encryption and authentication.
332 <a name="f1_240"></a>
333 <samp class="highlight">Q: What is the purpose of the SILC key exchange (SKE) protocol?</samp><br />
334 A: The primary purpose of the SILC key exchange protocol is to create
335 session key for protecting the traffic between the client and the
336 server. It is executed always when client connects to the server.
337 It can also be used to create other key material for other sessions,
338 like file transfer session. The SKE use Diffie-Hellman for key
339 exchange algorithm, and supports digital signatures and mutual
340 authentication. The SKE is based on SSH2, STS and OAKLEY key exchange
341 protocols. The SKE is also used to negotiate the security properties
342 that are going to be used in the session. These properties are
343 the encryption algorithm, HMAC, public key algorithm, hash
344 algorithm, key lengths, encryption modes, etc.
347 <a name="f1_250"></a>
348 <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 />
349 A: Diffie-Hellman is known to be vulnerable to man-in-the-middle attack
350 when it is used alone. For that reason it must not be used alone
351 ever. In SILC key exchange (SKE) protocol digital signatures are
352 used to prevent the man-in-the-middle attacks. Using digital
353 signatures with Diffie-Hellman is the common way to avoid these
354 problems, and in addition it provides peer authentication at the
355 same time. Other key exchange protocols which use Diffie-Hellman
356 with digital signatures too are IKE, SSH2, TLS/SSL, and many more.
359 Naturally, in the end the user and the application is responsible of
360 avoiding the man-in-the-middle attack; the public key of the remote
361 must be verified before trusting it. If this is not done, then
362 the digital signatures makes no difference. This is the case with
363 any key exchange protocol using digital signatures.
366 <a name="f1_260"></a>
367 <samp class="highlight">Q: Would have it been possible to use some other key exchange protocol in SILC instead of developing SKE?</samp><br />
368 A: At the time SILC was developed the answer was simply no, it would have
369 not been possible. The problem often is that security protocols tend
370 to develop their own key exchange protocols even though at least
371 theoretically it would be possible and wise to use protocol which
372 is proved secure. In practice this is never done. TLS/SSL has its
373 own key exchange, SSH has its own key exchange, and SILC has its
374 own key exchange. When the Internet Key Exchange (IKE) protocol was
375 being developed it was our hope that it would have become general
376 purpose key exchange protocol but the reality was that it was tightly
377 developed for IPSEC instead. The end result is that it would be
378 huge overkill to use IKE with any other protocol than IPSEC.
381 <a name="f1_270"></a>
382 <samp class="highlight">Q: Should I verify the public key of the server when I connect to it?</samp><br />
383 A: Definitely yes. Commonly in security protocols which does not use
384 certificates by default the public key is verified in the first time
385 it is received and then it is cached on local disk. In SILC the same
386 thing is done. When you connect the very first time to the server
387 you will be prompted to verify and accept the public key. This is the
388 time when you should (must) verify the public key. After accepting
389 the key it is saved locally and used later to do the verification
390 automatically. This is same as with SSH; you accept the SSH server
391 key the very first time and then cache it locally for later use.
394 The moral is this: you always must verify all public keys to be
395 certain that man-in-the-middle attack is not in progress. It is your
396 risk to take if you do not verify the key.
399 <a name="f1_280"></a>
400 <samp class="highlight">Q: Should I verify all other public keys in SILC?</samp><br />
401 A: Definitely yes. You can receive public keys when you negotiate for
402 example private message key with some other client, and you must
403 verify the key before accepting it. Reason are same as in previous
407 <a name="f1_290"></a>
408 <samp class="highlight">Q: Why SILC does not used OpenSSL crypto library instead of its own?</samp><br />
409 A: The OpenSSL crypto library as you know it now did not even exist
410 when the SILC crypto library was developed in 1997. The SSLeay
411 crypto library which was the predecessor of OpenSSL package did
412 exist but was not suitable for our use at the time.
415 Now that OpenSSL crypto library is popular, it still is not
416 sufficient enough for us. SILC specification requires AES algorithm
417 but OpenSSL crypto library as of this writing (Oct 2002) still does not
418 support it. This alone makes the OpenSSL crypto library impossible
422 Also, we feel that using different crypto libraries and using the one
423 we have developed over the years is good in the end for everybody. A
424 bug that would affect SILC may not then affect OpenSSL, and on the
425 other hand bug that would affect OpenSSL crypto library may not then
426 affect SILC. Diversity also in crypto libraries is a good thing.
429 Finally, in our opinion SILC crypto library is equally good or even
430 better than OpenSSL crypto library.
433 <a name="f1_300"></a>
434 <samp class="highlight">Q: Is it possible to digitally sign messages in SILC?</samp><br />
435 A: Yes, this is possible, however the detailed definition of how this is
436 done with different public keys/certificates has not yet been defined
437 as of this writing (Oct 2002). The next protocol version 1.2 will
438 define this and it will be added to the implementation immediately.
441 <a name="f1_310"></a>
442 <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 />
443 A: Hehe. There is no simple answer to this question. Designing a
444 security protocol is extremely difficult. It is actually more
445 difficult than, say, designing an encryption algorithm. Why? Because
446 security protocols tend to be so complex. And even when they are
447 not complex they are always more complex than just one cryptographic
448 primitive like encryption algorithm. Now, attacking cryptographic
449 algorithm to break the protocol is usually never the best way to
450 go about since the attacks against algorithms are usually just
451 theoretical and hard to mount. Attacking the protocol as a whole may
452 also be pretty difficult since the operations in the protocol are
453 usually protected by those cryptographic primitives. The best way of
454 attacking any security protocol is usually to attack the
455 implementation, since that's the number one source of problems in
459 However, I don't know whether you want to analyze the protocol
460 itself, in an attempt to try to find security holes or weaknesses in
461 the protocol, or whether you want to just break the protocol. If you
462 want to do the first, then the best way to go about is to learn all
463 the details about SILC protocol, how it works, how the implementation
464 is supposed to work, and what security measures are used in the
465 protocol. Then you start analyzing the protocol and trying to look
466 for obvious mistakes. Then you can try to apply some attacks you know
467 about to the protocol and see what would happen. If you want to
468 do the second then you probably need to get your hands dirty and
469 try to figure out ways to do it in practice by finding implementation
470 problems, design problems and applying attacks in practice to the
471 implementation you are using. Also, always think big. Protocols are
472 not used in a class jar, they are used by human beings in a real world
473 and you can break a protocol by not attacking the protocol at all, but
474 by attacking something from the side.
477 <a name="f1_320"></a>
478 <samp class="highlight">Q: What could happen if a server in SILC network would become compromised?</samp><br />
479 A: This is of course hypothetical but let's assume the entire server would
480 be in the hands of malicious attacker and he can control everything
481 that happens in the server. This would of course mean that the
482 attacker has compromised the entire machine, not just SILC server.
483 He also would have replaced the original SILC server with tampered
484 version which the attacker can control. It would not be nice
485 situation. First, all local connections to the server would be
486 compromised since the server knows the session keys for local
487 connections. Second, all channels that the server has locally joined
488 users would be compromised since the server knows those channel keys.
489 However, other invite-only, private or secret channels would not be
490 compromised since the attacker has no access to those channels. Also
491 channels that are using channel private keys would not be compromised.
492 Third, all data and messages protected with session keys would be
493 compromised. However, all messages protected with private keys, like
494 private message keys, and channel private keys would not be
495 compromised since the server does not know these keys.
498 So it would not be pretty sight, but it's same with any security
499 protocol like SSH. If SSH server is compromised then there's not
500 much you can do. In SILC however you can still do something; you
501 can decide to use private keys to protect all messages. Servers
502 do not know these keys so even if the server is compromised it would
503 be safe. It cannot decrypt those messages. So, in SILC there is
504 always the fallback to something else. This is important in security
505 protocols; how can you make the protocol secure even if it partially
506 fails? Answer is by having fallbacks that are available if something
507 fails. Fallback after the other. As long it fallbacks to something
508 that provides security it is better than nothing. Another problem
509 is of course that of how fast the protocol is able to recover from
510 these security failures. This is more complicated matter however,
511 but naturally the compromised server need to be removed from the
512 network as soon as possible. The protocol recovers then immediately.
515 <a name="f1_330"></a>
516 <samp class="highlight">Q: What could happen if a router would become compromised?</samp><br />
517 A: The situation would be similar to having compromised server except
518 that router knows all locally (in the router, ie. in the cell) created
519 channels, so all local channels that are not using channel private
520 keys would be compromised. However, channels that are created on other
521 routers, and if there are no local users on those channels in the
522 router, would not be compromised, since channel keys are cell specific.
525 <a name="f1_340"></a>
526 <samp class="highlight">Q: Is my channel messages protected on compromised server or not?</samp><br />
527 A: If you are using channel private key then always yes. If the
528 compromised server does not know about the channel then always yes.
529 If you are not using channel private key, and the server knows the
530 current channel key then no, if the server is compromised. But note
531 that if some server in the network is compromised it does not
532 automatically mean that your channel messages are compromised.
535 <a name="f1_350"></a>
536 <samp class="highlight">Q: Is my private messages protected on compromised server or not?</samp><br />
537 A: If you are using private message keys then always yes. If you are not
538 using then no, if the server is compromised and the private message
539 passes through the compromised server. Again, a compromised server
540 in network does not automatically mean that private message is
541 compromised. Also the structure of the network in SILC is designed
542 so that messages do not go to servers unless they really need to
543 do so (since there is no tree-like network structure, where messages
544 could pass through several servers).
547 <a name="f1_360"></a>
548 <samp class="highlight">Q: Should I then always use private keys for all messages?</samp><br />
549 A: If you think that the network or server you are using is not something
550 you can trust in any degree then yes. If the server is your company's
551 internal SILC server then I guess you may even trust it. It is your
552 decision and you decide what is the acceptable level of risk you are
553 willing to take, and what is your required level of security. For
554 private messages using private keys is trivial since you can
555 automatically negotiate the keys with SKE. Using channel private key
556 is however more complicated since all users in the channel need to
557 know the key in order to be able to talk on the channel. It may be
558 for example pre-shared key that all users on the channel know.
561 <a name="f1_370"></a>
562 <samp class="highlight">Q: How likely is it that some server would become compromised?</samp><br />
563 A: Like said in last questions all these scenarios were hypothetical, and
564 if the server is not compromised then there are no problems of the
565 kind just discussed. It is very hard to say how likely it is. It is
566 unlikely, but a possibility. Server administrators must keep the
567 machine protected in general too, since if the machine is compromised
568 a whole lot of other stuff is compromised too, not just SILC server.
projects / silc.git / blob