Le premier préalable à notre étude, est de fixer quelques points de vocabulaire. Nous appellerons entité (= principal) tout émetteur de message, qu'il s'agisse d'une personne physique, d'une machine ou d'un processus et quelque soit son rôle : client, serveur, intrus ou autre. Mais l'utilisation de ce terme générique ne doit pas faire oublier que, à travers toute chaîne d'identifications, l'objectif final équivaut à assurer une identification personne-personne et qu'ainsi une simple identification processus-processus serait insuffisante.
Nous désignerons par chiffrement/déchiffrement les opérations de traduction entre un texte en clair et sa forme chiffrée ou cryptogramme lorsque ces opérations sont réalisées dans le cadre du protocole par des entités autorisées. Par contre, la traduction en clair du cryptogramme réalisée par un intrus sera appelée décryptement.
Il n'est évidement pas possible d'implémenter un protocole de sécurité sans faire un certain nombre d'hypothèses sur le matériel ou le système d'exploitation (ou en tout cas le noyau de celui-ci). L'annexe A1 montre que rien ne doit être tenu pour assuré en ce domaine.
D'autre part, nous analysons dans l'annexe A2 plusieurs utilitaires « de sécurité » inclus dans les versions réseau de plusieurs produits commerciaux... Certains sont d'aimables passoires, qui ne procurent rien d'autre qu'une illusion de sécurité, ce qui est pire que de ne rien faire, car cela peut amener des utilisateurs naïfs à ne pas prendre les précautions élémentaires qu'ils auraient peut-être prises sans cette illusion. Nous en donnons trois exemples typiques.
Trois techniques de chiffrement au moins sont connues pour leur résistance et semblent remplir les objectifs mentionnés au paragraphe 2 : la combinaison avec un flot pseudo-aléatoire, l'algorithme DES (à clef secrète) et l'algorithme RSA (à clef publique).
Nous les décrivons brièvement dans les annexes A3, A4 et A6. Indiquons seulement ici qu'avec ces algorithmes les tentatives pour faire porter l'essentiel de la charge du chiffrement/déchiffrement sur l'extrémité dotée de la plus forte puissance de calcul lors d'un dialogue entre un "gros" ordinateur et un "petit" terminal risquent de compromettre gravement la sécurité.
D'autre part, il est tout à fait remarquable qu'une attaque contre l'un de ces protocoles par une recherche systématique de la clef ne nécessite en aucune façon un "gros" ordinateur centralisé et pourrait tout aussi bien (ou aussi mal) être menée en parallèle sur un réseau de processeurs faiblement couplés, chaque processeur explorant aléatoirement l'espace des clefs possibles, indépendamment des autres, à charge pour celui qui trouve la clef de diffuser sa découverte.
Le calcul [37] montre en effet que pour 
processeurs explorant
aléatoirement un espace de 
clefs, avec
,
l'espérance du nombre total d'essais avant découverte est équivalent
à 
, soit le double seulement de l'espérance correspondant
à une recherche systématique, avec de plus l'avantage de la tolérance
aux pannes et d'une meilleure architecture matérielle.
Un dernier présupposé des protocoles que nous allons examiner est qu'il ne soit pas possible de falsifier un cryptogramme. L'annexe A7 décrit des techniques permettant de certifier qu'un intrus ne peut pas fabriquer un message "de bonne allure" à partir de pièces et de morceaux. Tant que l'intrus n'a pas trouvé la clef, il ne doit pas avoir d'autre possibilité que de "rejouer" des messages déjà émis par les entités en possession de la dite clef.