Nous allons maintenant nous pencher sur ce qui fait la force du protocole Signal.
Admettons que nous souhaitions créer notre propre protocole de chiffrement pour des communications de type chat, commençons par lister les problèmes que nous aurions à résoudre.

Confidentialité
Comme souvent en cryptographie, la difficulté de mise en place d’un protocole « parfait » réside dans l’échange initial des clés entre les 2 parties.

Le premier problème qui se pose est celui de la confidentialité de l’échange. En effet, dans la mesure où on ne contrôle pas tous les nœuds du réseau, on doit se méfier des intermédiaires et d’éventuelles écoutes/interceptions (NEVER TRUST THE NETWORK !).

Historiquement, ce problème très commun a d’abord été résolu par la création en 1976 du protocole Diffie-Hellmann, permettant l’échange de clé sur un canal non sécurisé. Ce protocole, robuste dans le concept présente en revanche le défaut de ne pas fournir d’authentification entre les 2 parties.

Un attaquant souhaitant se positionner au milieu de la communication de façon passive peut ainsi très facilement se faire passer pour l’autre partie auprès de chacun des 2 correspondants (on parle d’attaque man-in-the-middle) et relayer les communications sans que personne ne puisse s’en rendre compte.

Asynchronisme
Outre l’absence de confiance en le réseau, un autre problème à résoudre réside dans l’aspect asynchrone des échanges.
En effet, dans un certain nombre de cas, comme celui du très répandu protocole TLS (utilisé pour HTTPS notamment), on se trouve dans une situation dite « synchrone », c’est-à-dire que la communication n’a lieu que lorsque le client ET le serveur sont en ligne, si le serveur est injoignable, il n’y a simplement pas d’échange. De cela résulte que les clés de chiffrement utilisées pour la session sont générées instantanément dès la communication engagée, ce qui laisse une fenêtre de temps extrêmement courte à un attaquant pour tenter une cryptanalyse.

Or, pour un protocole de discussion textuelle, il faut envisager que le téléphone de l’un des protagonistes ne soit pas connecté. Cela implique que les clés utilisées lors de l’échange initial soient stockées sur le serveur central jusqu’à ce que la communication puisse être établie. Cela laisse donc à un attaquant potentiel davantage de temps pour tenter de casser les clés utilisées, et pose un problème : il faut stocker les clés et s’assurer que celui qui vient les chercher est légitime !

La persistance des messages ou le perfect forward secrecy
Le dernier problème à résoudre est un autre classique de la cryptographie. Encore une fois, on suppose qu’avec les ressources nécessaires, un attaquant peut finir par casser un secret. Admettons qu’un adversaire coriace et obstiné a enregistré tous les échanges effectués sur un canal chiffré depuis 6 mois entre vous et votre interlocuteur. A force de temps et de ressources en calcul, il a finalement réussi au bout de quelques mois à « casser » le chiffrement d’un des messages, peut-il de fait lire tous les autres messages ?

Ce problème, qui se pose pour tous les échanges « longue durée », s’appelle le perfect forward secrecy (PFS pour les intimes). Expliqué autrement, cela consiste à s’assurer que si un secret est révélé, les secrets ultérieurs et antérieurs ne sont pas mis en danger, ce qui nécessite la création de nouvelles clés indépendantes des clés précédentes, et une mise à jour des clés à chaque échange.