Table des matières

Ceci est la traduction de la FAQ concernant la cryptographie et la sécurité du Projet SILC. Cette traduction a fait l'objet d'une relecture minutieuse et peut être considérée comme fiable. N'hésitez cependant pas à corriger toute éventuelle erreur que vous pourriez trouver.

Questions concernant la cryptographie et la sécurité dans le projet SILC

1. Qu'est-ce-que cette FAQ ?

Cette FAQ répond aux questions relatives à la cryptographie et à la sécurité dans le protocole SILC et dans son implémentation. Elle tentera de répondre aux questions les plus fréquemment posées par les utilisateurs. Elle essayera aussi de détailler suffisemment pour donner des réponses précises à ceux qui connaissent déjà un tant soit peu la cryptographie et la sécurité. Quand nous faisons des affirmations ou des suppositions concernant des problèmes de sécurité, nous essayons toujours d'inclure dans la réponse une référence qui permet d'en apprendre plus à ce propos. Ainsi, toute affirmation traitant de la sécurité de SILC n'est faite que lorsque nous pouvons la prouver.

2. J'ai trouvé une information incorrecte dans la FAQ, qui puis-je avertir ?

Si vous pensez que certaines informations sont incorrectes dans cette FAQ, vous pouvez envoyer vos commentaires à l'adresse de courriel info@silcnet.org .

3. J'ai trouvé un problème de sécurité dans le protocole/l'implémentation de SILC. Où dois-je le notifier ?

Si vous trouvez un problème de sécurité, que ce soit dans le protocole ou dans l'implémentation, nous apprécierions que vous le portiez à notre connaissance avant de faire quoique ce soit. Vous pouvez dans ce cas-là envoyer un message à cette adresse : security@silcnet.org .

4. SILC supporte-t-il l'AES ?

Oui, l'AES avec une clé de chiffrement de 256 bits est utilisé dans le protocole SILC. Le mode de chiffrement employé avec AES est CBC. SILC supporte aussi d'autres algorithmes mais ceux-là sont optionnels.

5. SILC supporte-t-il le DES ou le 3DES ?

Le protocole ne défini aucun usage du DES ou du 3DES pour SILC. Cependant, l'implémentation peut l'employer séparément si c'est vraiment nécessaire. Officiellement, SILC ne supporte ni le DES, ni le 3DES.

6. Quels autres algorithmes SILC supporte-t-il ?

L'AES est le seul algorithme employé. La spécification de protocole liste aussi des algorithmes optionnels comme Twofish, CAST, etc, mais vous pouvez aussi vous servir, si nécessaire, d'autres algorithmes durant le protocole d'échange de clé SILC.

7. Quels modes de chiffrement SILC supporte-t-il ?

Le mode de chiffrement employé actuellement est CBC avec un chaînage inter-paquets. La spécification recommande aux implémentations d'utiliser aussi le mode CTR ; elle définit un CBC aléatoire (avec un random de IV) comme mode facultatif. Il est aussi possible, si nécessaire, d'utiliser d'autres modes durant le protocole d'échange de clé SILC. Nous avons aussi jeté un coup d'oeil sur les fameux modes de chiffrement authentifiés que le NIST examine actuellement. D'autres informations viendront plus tard.

8. Quelles fonctions de hachage SILC supporte-t-il ?

La fonction de hash employée est SHA-1, mais MD5 fait aussi partie de la spécification en tant que fonction de hachage optionnelle. Le SHA-1 est aussi la fonction de hachage employée pour fournir la protection de l'intégrité des paquets chiffrés dans le cadre du HMAC.

9. Quels algorithmes à clé publique SILC supporte-t-il ?

L'algorithme employé pour la clé publique est RSA, mais il existe un support optionnel pour l'algorithme DSS. L'algorithme RSA présent dans SILC supporte le standard PKCS#1. L'algorithme de clé publique Diffie-Hellman est utilisé pour l'échange des clés. Le Diffie-Hellman de SILC supporte le standard PKCS#3. L'ajout du support d'autres algorithmes, comme El Gamal, est possible en les employant dans l'échange de clé SILC.

10. SILC supporte-t-il les clés PGP ?

Les clés PGP (ou certificats OpenPGP comme ils sont officiellement appelés) sont supportées par le protocole SILC. Cependant, l'implémentation actuelle ne les supporte pas encore.

11. SILC supporte-t-il les clés SSH ?

Les clés publiques SSH2 sont supportées par le protocole SILC, mais l'implémentation actuelle ne les supporte pas pour le moment.

12. SILC supporte-t-il les certificats X.509 ?

Oui, les certificats X.509 sont supportés par le protocole SILC. Néanmoins, l'implémentation actuelle ne les supporte pas encore.

13. Donc SILC peut-il être aussi utilisé avec d'autres clés à la place des clés publiques SILC ?

Oui, c'est la raison même du support d'autres clés publiques et certificats. L'implémentation voudra probablement que vous créiez une paire de clés SILC, mais si vous avez une paire de clés PGP, par exemple, vous pourrez l'utiliser dans SILC.

14. Comment le MAC est-il calculé dans SILC ?

Le MAC (Message Authentication Code : Code d'authentification de message) des paquets SILC — dans le protocole sécurisé de paquet binaire — est toujours calculé après le chiffrement à partir du message chiffré. C'est le fameux ordre chiffrement-puis-MAC (Encrypt-then-MAC). Le même ordre est utilisé par exemple pour le protocole IPSEC (ESP) pour calculer le MAC. Un nombre séquentiel de paquets est aussi employé pour le calcul du MAC. Ce dernier est lui-même attaché à la fin du paquet et n'est jamais chiffré. Donc les messages privés et les messages de canal ont un MAC qui est calculé à partir des données chiffrées, et donc après chiffrement.

15. Pourquoi SILC n'utilise-t-il pas PGP pour chiffrer les messages ?

PGP seul n'est pas approprié pour être utilisé en tant que protection principale dans un réseau de conférence. Il pourrait être approprié pour la protection des messages mais il ne peut pas protéger le transport sur le réseau. Il ne possède pas les exigences de sécurité requises dans le protocole SILC, et par conséquent ne peut pas être employé dans un réseau de type SILC, 1, 2.

Cependant, PGP peut être utilisé avec SILC. Il est tout à fait possible de l'utiliser pour chiffrer et/ou signer les messages de SILC, mais il n'est pas suffisant en tant que protection principale. L'implémentation actuelle ne le supporte pas.

16. Pourquoi SILC n'utilise-t-il pas TLS/SSL pour chiffrer les messages ?

A elle toute seule, la couche de transport ne peut pas fournir de sécurité pour des messages individuels qui ne sont pas, par nature, en point-à-point. Le TLS/SSL protège seulement arbitrairement le trafic point-à-point, et l'utiliser pour protéger des messages privés, par exemple, qui n'a aucune corrélation avec le transport actuel, ne veut strictement rien dire. Les messages ont besoin d'être protégés avec des clés de messages spécifiques, comme c'est le cas pour les messages de canal qui sont protégés par des clés de canal. Le transport dans SILC est aussi protégé par des clés de session (point-à-point), qui agissent de manière analogue à TLS/SSL. SILC possède un protocole sécurisé de paquets binaires pour la protection du transport et par conséquent, TLS/SSL n'est pas nécessaire.

17. Pourquoi SILC n'utilise-t-il pas de tunnels SSH ou IPSEC pour chiffrer les messages ?

Pour les même raisons qui poussent à ne pas utiliser TLS/SSL.

18. Alors comment le transport est-il protégé dans SILC ?

Le transport est protégé avec des clés de session échangées pendant le protocole d'échange de clés SILC. Le protocole SILC spécifie un protocole sécurisé de paquets binaires qui fournit des paquets binaires chiffrés et authentifiés. Dans SILC toutes les données sont envoyées en utilisant ce protocole et tous les paquets sont automatiquement chiffrés. Cela revient au même que d'utiliser TLS/SSL pour protéger la couche socket, à l'exception près que SILC définit le protocole de paquet binaire lui-même. Un autre exemple de protocole ayant son propre protocole sécurisé de paquet binaire est SSH, et c'est aussi analogue à TLS/SSL.

Mais notez que protéger le transport n'est pas suffisant pour protéger les messages individuels. Le transport est juste une donnée arbitraire point-à-point, tandis que les messages de canal sont des messages d'un seul expéditeur à beaucoup de destinataires et nécessitent divers types de protections. Protéger le transport est une chose, et protéger les messages du début à la fin en est une autre.

19. Est-ce-que TLS/SSL + PGP fourniraient la même protection que SILC aujourd'hui ?

TLS/SSl + PGP + encore autres chose reviendrait presque au même, mais le résultat final devrait être une solution ad hoc puisqu'ils sont séparés, que ce sont des protocoles de sécurité externe et qu'il ne sont pas conçus pour fonctionner ensemble. Donc, au moment de la création de SILC, le standard OpenPGP n'existait pas encore, donc l'utiliser était hors de question de toutes façons. Votre protocole de chat favori n'est pas soudainement devenu sûr en mettant différents protocoles de sécurité les uns sur les autres. Cela requiert une minutieuse planification et une conception approfondie pour que cela fonctionne de manière vraiment sûre.

SILC a été conçu dès le commencement dans une optique de sécurité, et pour cette raison, la sécurisation de A à Z du transport, des messages privés, des messages de canal et d'autres messages a été intégrée. Le résultat final n'aurait pas été aussi sûr si des protocoles externes avaient été appliqués sur un protocole de chat non fiable aussi bon qu'il soit. Aujourd'hui ils sont intégrés et conçus pour fonctionner ensemble. Autrement dit, il n'y a pas besoin d'utiliser des protocoles de sécurité externes.

20. TLS/SSL seul n'est-il pas déjà assez pour les protocoles qui l'utilisent ?

Si le TLS/SSL est utilisé correctement, c'est-à-dire que tous les points du réseau de chat sont protégés, alors il fournit une certaine sécurité. Mais si un seul point du réseau n'est pas sûr, alors le réseau entier peut être considéré comme compromis. Donc, si un serveur du réseau est compromis, alors c'est le réseau entier et tous les messages qui le deviennent puisque ce ne sont pas les messages, mais le transport qui est sécurisé. Posez-vous la question : si vous supprimez le TLS/SSL, est-ce-que votre message est-il sécurisé ou pas ? Si vous répondez non, alors il n'y a pas une sécurité suffisante sur le réseau de chat. Donc, notez que ces deux protocoles ne fournissent pas l'authentification des messages, seulement l'authentification des données du paquet, et ce n'est pas du tout la même chose (un paquet est de type point-à-point, mais pas un message).

21. PGP seul n'est-il pas déjà suffisant pour les protocoles qui l'utilisent (comme ICQ + PGP) ?

Le PGP fournit la sécurité des données là où il est appliqué, mais il ne fournit pas la sécurité des paquets ou du transport. C'est en effet plus sérieux que les protocoles qui utilisent juste TLS/SSL. C'est parce qu'il n'y a pas du tout de protection des paquets ou de l'authentification, seulement une protection des données. Cela permet des — attaques de type contrefaçon, falsification de texte chiffré ou clair, attaque par distribution de réponse et par livraison hors service —, attaques par textes chiffrés choisis, voire des attaques par textes chiffrés choisis adaptatifs 12, et bien d'autres encore. Certaines de ces attaques peuvent être rendues inefficaces en faisant une implémentation précautionneusement mais le protocole reste malgré tout assez peu fiable.

22. Donc un protocole de discussion nécessite toujours : un transport sécurisé ET des messages sécurisés, n'est-ce-pas ?

Oui, c'est parfaitement cela. Et SILC fournit exactement ça. Son transport est sécurisé avec le protocole sécurisé de paquets binaires et il fournit le chiffrement des messages et leur authentification.

23. Quelle est la raison d'être du protocole d'échange de clé SILC (SKE) ?

Le but premier du protocole d'échange de clé SILC est de créer des clés de session pour protéger le trafic entre le client et le serveur. Il est toujours exécuté à la connexion du client au serveur. Il peut aussi être utilisé pour créer d'autres clés pour d'autres sessions, comme les sessions de transfert de fichiers. Le SKE utilise le Diffie-Hellman pour l'algorithme d'échange de clés, et il supporte les signatures numériques et les authentifications mutuelles. Le SKE est aussi utilisé pour échanger les propriétés de sécurité qui vont être utilisée pendant la session. Ces propriétés sont l'algorithme de chiffrement, le HMAC, l'algorithme de clef publique, l'algorithme de hachage, les tailles des clefs, les modes de chiffrement, etc.

24. Le SKE utilise le Diffie-Hellman. Comment le protocole de SKE protège-t-il des attaques man-in-the-middle qui peuvent être utilisées pour attaquer l'échange de clé Diffie-Hellman ?

Diffie-Hellman est connu comme étant vulnérable aux attaques MITM (man-in-the-middle : troisième homme ou homme du milieu) quand il est utilisé seul. Et pour cette raison il ne doit jamais l'être. Dans le protocole d'échange de clés SILC (SKE), les signatures numériques sont utilisées pour empêcher les attaques MITM et pour fournir une authentification. Utiliser les signatures numériques avec le Diffie-Hellman est la façon la plus commune de régler ces problèmes, et de plus cela fournit en même temps une paire d'authentification. Les autres protocoles d'échange de clés qui utilisent aussi Diffie-Hellman avec des signatures numériques sont IKE, SSH2, TLS/SSL, et bien d'autres. Naturellement, au final, l'utilisateur et l'application sont capables d'éviter les attaques MITM ; la clé publique distante doit toujours être vérifiée avant d'être acceptée. Si ce n'est pas fait, alors les signatures numériques ne servent à rien. C'est le cas avec tout protocole d'échange de clé utilisant les signatures numériques.

25. Aurait-il été possible d'utiliser d'autres protocoles d'échange de clés dans SILC au lieu de développer SKE ?

Au moment du développement de SILC la réponse était tout simplement non, ce n'était pas possible. Le problème est souvent que les protocoles de sécurité tendent à développer leur propre protocole d'échange de clés, bien que, théoriquement du moins, il soit possible et préférable d'utiliser un protocole qui est prouvé comme étant sûr. En pratique, ce n'est jamais le cas. TLS/SSL possède son propre protocole d'échange de clés, SSH et SILC aussi. Quand le protocole d'échange de clés par Internet (Internet Key Exchange : IKE) a été développé, nous espérions qu'il aurait pour but principal d'être un protocole d'échange de clés en général, mais en réalité, il a été strictement développé pour IPSEC. Le résultat final est qu'il aurait été suicidaire d'utiliser IKE avec un autre protocole qu'IPSEC. La même tendance se dessine pour IKE version 2.

26. Dois-je vérifier la clé publique du serveur sur lequel je me connecte ?

Encore une fois, OUI. Habituellement, dans les protocoles de sécurité qui n'utilisent pas de certificats par défaut, la clé publique est vérifiée une première fois à sa réception et à sa mise en cache sur le disque local. Et c'est pareil pour SILC. Quand vous vous connectez pour la toute première fois à un serveur, vous devez être prompt à vérifier et accepter la clé publique. C'est cette fois-là que vous devriez (devez) vérifier la clé publique. Après l'avoir acceptée, la clé est sauvegardée localement et utilisée ultérieurement pour faire les vérifications automatiquement. C'est le même principe qu'avec SSH : vous acceptez la clé du serveur SSH à la toute première connexion, et elle se met en cache pour les futures connexions.

Voici la morale : vous devez toujours vérifier toutes les clés publiques pour être certain qu'une attaque man-in-the-middle n'est pas en cours. C'est le risque que vous prenez si vous ne vérifiez pas la clé publique.

27. Dois-je vérifier toutes les autres clés publiques dans SILC ?

C'est définitivement obligatoire. Vous pouvez recevoir des clés publiques lorsque vous échangez vos clés de messages privés avec un autre client, par exemple, et vous devez toujours vérifier la clé avant de l'accepter. Les raisons sont les mêmes que ci-dessus.

28. Pourquoi SILC n'utilise-t-il pas la librairie cryptographique OpenSSL à la place de la sienne ?

La librairie cryptographique OpenSSL que vous connaissez n'existait pas encore lors du développement de la librairie de cryptographie SILC en 1997. La librairie de cryptographie SSLeay qui était le prédécesseur du paquetage OpenSSL existait, mais n'était pas utilisable pour l'usage que l'on voulait en faire.

Quand l'OpenSSL est devenue populaire, elle n'était toujours pas suffisante pour nous. La spécification de SILC nécessite l'algorithme AES mais la librairie de cryptographie OpenSSL à l'époque de son écriture (Octobre 2002) ne le supportait pas encore. Rien que cela rendait OpenSSL inutilisable à nos yeux. Note : Aujourd'hui (Octobre 2003) OpenSSL supporte aussi l'AES.

Donc, nous pensons qu'utiliser différentes librairies de cryptographie et utiliser celle que nous avons développé année après année est aussi bien pour tout le monde. Une faille qui affecterait SILC n'affecterait alors pas OpenSSL, et d'un autre côté une faille affectant OpenSSL n'aurait aucune incidence sur SILC. La diversité dans les librairies cryptographiques est aussi une bonne chose.

Finalement, selon nous, la librairie de cryptographie SILC est aussi bonne voire même meilleure que la librairie OpenSSL.

29. Est-il possible de signer numériquement les messages dans SILC ?

Oui, il est possible de signer numériquement les messages de canal et les messages privés, et de délivrer des clés publiques et des certificats avec le message pour la vérification.

30. Je suis un super hacker, et je veux cracker votre protocole. Quel serait le meilleur moyen d'attaquer le protocole SILC ?

Il n'existe pas de réponse simple à cette question. Concevoir un protocole de sécurité est extrêmement difficile. C'est en effet plus difficile que de créer un algorithme de chiffrement. Pourquoi ? Parce que les protocoles de sécurité tendent beaucoup à se complexifier. Et même quand ils ne sont pas complexes, ils le sont toujours plus qu'un simple protocole cryptographique comme les algorithmes de chiffrement. Aujourd'hui, attaquer des algorithmes cryptographiques pour casser les protocoles n'est généralement pas le meilleur moyen d'en venir à bout puisque les attaques contre les algorithmes sont, la plupart du temps, juste théoriques et difficiles à mettre en place. Attaquer le protocole, dans sa totalité, peut aussi être très difficile puisque les opérations du protocole sont souvent protégées par ces primitifs cryptographiques. La meilleure manière d'attaquer un protocole de sécurité quel qu'il soit est, dans la plupart des cas, de s'attaquer à son implémentation, puisque c'est la première source de problème des protocoles de sécurité.

Cependant, je ne sais pas si vous voulez analyser le protocole lui-même, dans le but d'essayer de trouver des trous de sécurité ou des faiblesses dans le protocole, ou si vous souhaitez juste casser le protocole. Si vous êtes dans le premier cas, alors la meilleure manière d'en venir à bout est d'apprendre tous les détails du protocole SILC, comment il fonctionne, comment son implémentation est censée fonctionner, et quelles sont les mesures de sécurité qui sont employées dedans. Alors vous commencerez par analyser le protocole et essayer de voir les erreurs cachées. Ensuite, vous pourrez essayer de lancer des attaques que vous connaissez contre le protocole et en observer les effets. Si vous êtes dans le deuxième cas, alors vous avez probablement besoin de mettre les mains dans le cambouis et d'essayer de trouver des manières de casser le protocole en pratique en cherchant les problèmes d'implémentation et de conception, puis de lancer par la pratique des attaques contre l'implémentation que vous utilisez. Voyez aussi toujours plus grand : les protocoles ne sont pas utilisés par des machines, ils le sont par des être humains dans un monde réel, et vous pouvez casser le protocole, non en attaquant le protocole lui-même, mais en attaquant quelque chose qui lui est lié.

31. Qu'est-ce-qui pourrait arriver si un serveur du réseau SILC était compromis ?

C'est bien entendu hypothétique, mais supposons quand même que le serveur entier puissent être entre les mains d'un attaquant malveillant et qu'il puisse contrôler tout ce qui se passe dessus. Cela voudrait dire que l'attaquant aurait compromis la machine entière, et non seulement le serveur SILC. Il aurait aussi remplacé le serveur SILC original avec une version modifiée qu'il pourrait contrôler. Ce serait une belle situation. D'abord, toutes les connexions locales au serveur serait compromise puisque le serveur connaît les clés de session pour les connexions locales. Deuxièmement, tous les canaux locaux sur lesquels le serveur possède des utilisateurs seraient compromis puisque le serveur connaît les clés de canal. Cependant, les autres canaux de type privé, sur invitation seulement ou secret ne seraient pas compromis puisque l'attaquant n'a pas accès à ces canaux. De même, les canaux utilisant des clés privées de canal ne seraient pas compromis. Troisièmement, toutes les données et messages protégés avec les clés de session seraient compromis. cependant, tous les messages protégés avec des clés privées, comme les clés de message privé, et les clés privées de canal ne seraient pas compromis puisque le serveur ne connaît pas ces clés.

Donc ce serait un véritable cauchemar, mais ce serait pareil avec n'importe quel protocole de sécurité comme SSH. Si un serveur SSH est compromis alors il n'y a plus grand chose que vous puissiez faire. Dans SILC, cependant, vous pouvez toujours faire quelque chose; vous pouvez décider d'utiliser des clés privées pour protéger tous vos messages. Les serveurs ne connaissent pas ces clés donc, même si le serveur est compromis, ils seront en sécurité. Il ne peut pas décrypter ces messages. Donc, dans SILC il y a toujours un moyen de battre en retraite. C'est quelque chose d'important dans les protocoles de sécurité; comment pouvez faire un protocole sûr même en cas de chute partielle ? La réponse est en ayant des moyens de repli disponibles en cas de chute partielle du réseau. Toujours avoir un moyen de repli. Aussi longtemps qu'on se replie sur quelque chose qui fournit de la sécurité, c'est mieux que rien. Un autre problème est bien sûr à quelle vitesse le protocole est-il capable de se remettre de ces failles de sécurité. C'est un sujet bien plus compliqué cependant, mais naturellement le serveur compromis a besoin d'être supprimé du réseau aussi vite que possible. Le protocole se remet alors immédiatement.

32. Qu'est-ce-qui arriverait si un routeur devait être compromis ?

La situation serait identique au cas d'un serveur compromis, à l'exception près que les routeurs connaissent tous les canaux créés localement (sur le routeur, c'est-à-dire dans la cellule), donc tous les canaux locaux qui n'utilisent pas de clés de canal privé seraient compromis. Cependant, les canaux qui sont créés sur d'autres routeurs, et s'il n'y a pas d'utilisateurs locaux sur ces canaux du routeur, ne seront pas compromis, puisque les clés de canal sont spécifiques aux cellules.

33. Mes messages de canaux sont-ils protégés contre les serveurs compromis, ou pas ?

Si vous utilisez une clé privée de canal alors dans tous les cas c'est oui. Si le serveur compromis ne connaît pas le canal alors de même, vous êtes protégés. Si un serveur est compromis, que vous n'utilisez pas de clé privée de canal, et que le serveur connaît la clé actuelle du canal, alors vous n'êtes plus protégé. mais notez que si quelques serveurs du réseau sont compromis, cela ne signifie pas forcément que vos messages de canal sont compromis.

34. Mes messages privés sont-ils protégés contre les serveurs compromis, ou pas ?

Si vous utilisez des clés privées de message, alors vous serez toujours protégés. Sinon, si le serveur est compromis et que les messages privés passent par celui-ci, vos messages privés ne sont pas protégés. De plus, un serveur compromis sur un réseau ne signifie par forcément que les messages privés sont compromis. La structure du réseau dans SILC est aussi conçue pour que les messages ne passent pas par un serveur à moins que ce soit vraiment nécessaire (puisqu'il n'y a pas de structure de réseau à arborescence, où les messages peuvent passer par un grand nombre de serveurs).

35. Dois-je dans ce cas-là toujours utiliser ma clé privée pour tous les messages ?

Si vous pensez que le réseau ou le serveur que vous utilisez n'est pas sûr à un quelconque degré, alors oui. Si le serveur est votre serveur de groupe SILC interne, alors je suppose que vous pouvez quand même avoir confiance en lui. C'est votre décision et vous décidez quel est le niveau acceptable de risques que vous voulez prendre, et quel est le niveau de sécurité que vous exigez. Pour les messages privés, utiliser des clés privés est inutile puisque vous pouvez automatiquement échanger les clés avec SKE. Utiliser une clé privée de message est cependant plus compliquée puisque tous les utilisateurs du canal ont besoin de connaître la clé afin d'être capable de parler sur le canal. Cela pourrait, par exemple, être une clé pré-partagée que tous les utilisateurs du canal connaissent.

36. Est-il probable que plusieurs serveurs soient compromis ?

Comme ce fut dit dans la dernière question, tous ces scénarios sont hypothétiques, et si le serveur n'est pas compromis, alors il n'y a aucun problème du type traité précédemment. Il est très difficile de dire la probabilité de ces faits. C'est improbable, mais néanmoins possible. Les administrateurs systèmes doivent aussi, en général, garder la machine protégée, puisque si la machine est compromise alors c'est la totalité d'un grand nombre d'autres choses qui sont aussi compromises, et ap^s seulement le serveur SILC.

37. Il est dit que SILC est conçu dans l'esprit de sécurité d'aujourd'hui. Qu'est-ce-que cela signifie ?

Cela signifie que lorsque SILC a été conçu, il l'a été comme un protocole de sécurité, et non comme un protocole de conférence possédant des fonctionnalités de sécurité. Cela signifie que la sécurité était la priorité absolu et les questions de sécurité ont été analysées à chaque ajout de nouvelles fonctionnalités au protocole. Cela veut aussi dire que SILC a été conçu du point de vue de l'attaquant. Au lieu d'ajouter simplement des mesures de sécurité au protocole, nous avons d'abord analysé les attaques possibles contre le protocole (et d'autres protocoles) puis nous avons conçu SILC pour résister à ces mêmes attaques. Le protocole s'est bien entendu très complexifié et son analyse devient de plus en plus dure, de nouvelles attaques sont découvertes que nous ne connaissions pas, et pour cette raison, l'analyse est constante et continuellement en cours.

38. Si quelqu'un rejoint/quitte le canal, comment peut-on m'assurer qu'il ne pourra pas lire les vieux/nouveaux messages de canal ?

La clé de canal est toujours régénérée quand quelqu'un quitte ou rejoint le canal. Cela assure qu'il ne soit pas possible de décrypter les messages de canal avant de l'avoir joint, vous ne pouvez pas déchiffrer les vieux messages de canal après avoir joint le canal puisqu'ils ont été chiffrés avec une autre clé. Vous ne pouvez pas non plus déchiffrer les messages de canal après l'avoir quitté puisque, de même, les messages sont chiffrés avec une autre clé. En résumé, vous ne connaîtrez la clé de canal qu'en rejoignant ce dernier, et c'est seulement en étant sur le canal que vous pourrez envoyer ou recevoir des messages de canal.

39. Votre FAQ ne répond pas à mes questions, où puis-je les poser ?

Si vous avez des questions qui devraient, selon vous, faire partie de cette FAQ, vous pouvez les envoyer à l'adresse de courriel info@silcnet.org .

documentations/faq/silc_crypto_faq.txt · Dernière modification: d/m/Y H:i:s (modification externe)