La résistance d'un système de protection est grandement influencée par les renseignements que l'intrus peut recueillir préalablement à sa tentative d'intrusion. On peut distinguer : absence d'écoutes, écoutes passives, écoutes actives. Si l'intrus est fraîchement débarqué, il ne manquera pas de se faire remarquer par son ignorance d'un élément ou d'un autre du protocole : une preuve par la connaissance le dépistera.
Les écoutes passives doivent être tenues pour indétectables : il est impossible de surveiller effectivement des kilomètres de câbles et de gaines techniques, et il est très peu probable de détecter un cheval de Troie qui se contente d'accumuler des informations (doña Ferrentes n'est pas toujours visible, qui ferait repérer Timéo Danaos). L'intrus a donc toute latitude pour essayer de décrypter "chez lui" les messages qu'il a écouté. S'il y arrive, il acquerra une connaissance qui le rendra égal aux usagers réguliers, et donc indétectable (sauf à excéder les ressources du système). On ne peut donc lui opposer que la résistance du chiffrement.
La dernière attitude, ce sont les écoutes actives. On se rappelle de ce qu'il faut craindre que le protocole lui même soit connu de l'intrus [14]. Celui-ci, peut donc essayer de repérer les messages protocolaires, puis deviner leur signification d'après leur ordre de succession, et enfin en déduire une façon de fabriquer un dialogue "de bonne allure" sans pour autant connaître la clef de chiffrement. Il convient en particulier de ne pas oublier que les utilisateurs "normaux" du système sont particulièrement bien placés pour procéder à ce genre d'attaques, à la fois par leur connaissance (théorique et expérimentale) du protocole et par le fait qu'ils sont naturellement destinataires de messages protocolaires, et n'ont donc besoin d'aucun moyen spécial pour capter un certain nombre de ces messages.
Un premier type d'attaque consiste à fabriquer un pseudo-message à partir de pièces et de morceaux de plusieurs messages précédents, dont on sait qu'ils ont été chiffrés par la même clef. Un exemple (assez fruste) est donné dans la Table 20. Cette attaque est facilitée par la structure en blocs des chiffrements DES et RSA.
Il convient que les messages contiennent dans leur partie chiffrée un descripteur de l'émetteur du message. Supposons en effet que le secret Wp soit partagé entre les seuls P et S, et que le message M prouve la connaissance de ce secret. Si P reçoit M, il n'aura la preuve de ce que c'est bien S qui a réalisé (un jour ou un autre) le chiffrement de M ... qu'à la condition d'être certain de ne pas être lui même l'auteur du message !
Une fois que la technique de chiffrement permet d'être certain de ce qu'un intrus ne peut pas fabriquer un message par pièces et morceaux avec une probabilité supérieure à celle du simple tirage au sort, il reste à se prémunir contre l'attaque qui consiste à "rejouer" un message qui a été régulièrement chiffré par un possesseur légitime de la clef correspondante.
Une façon bovine d'atteindre cet objectif serait d'archiver tous les dialogues passés et de comparer tout nouveau message avec les messages qui l'ont précédé. Il est clair qu'un tel procédé aurait pour résultat quasi-immédiat de saturer les capacités de stockage. Une façon élégante (et standard) d'éviter cela consiste à utiliser un heuristique fondé sur des horloges faiblement synchronisées. Tout message contient sa date d'émission, et est rejeté s'il arrive à une date jugée anormale. Il suffit alors d'archiver sur une profondeur de temps légèrement supérieure au décalage vraisemblable maximal entre les horloges.
Mais même ainsi, l'utilisation d'archives par les serveurs est loin d'être simple, car elle suppose une consultation en temps réel de celles-ci. Or les serveurs sont généralement implémentés sous forme de processus qui forkent à chaque requête : les différentes instanciations n'ont pas de mémoire vive commune; quant à rappeler du disque un fichier géré par appends successifs, c'est long, cela prend de la place, et il reste à gérer l'élimination des enregistrements périmés. Ce qui pose à son tour des difficultés de confidentialité, et constitue de toutes façons un cas typique de goulet d'étranglement.
La contre-mesure la plus souvent employée contre les attaques au "reviens-y"
est décrite dans la Table 21. La clef k étant le secret
commun des entités P et Q, chacun des messages a nécessairement été
chiffré par P ou par Q (à un moment ou à un autre). A réception du
deuxième message, P peut vérifier que ce message est récent, il vient
donc d'être émis par Q. Au troisième message, P (qui a déjà identifié
Q) envoie des données (X) en même temps que 
qui sert à
identifier ce message vis à vis de Q. A partir de là, il suffit d'estampiller
les messages. Cette façon de faire a un surcoût de deux messages,
qui peut sans doute être amorti au fil d'une connexion ... si connexion
il y a.
On voit donc qu'il y a un coût non négligeable à vouloir assurer la non-répétition d'un message, consistant ou bien à gérer une base de données en mode local, ou bien à échanger les messages d'une connexion. Dans ces conditions, il est tentant d'utiliser une horloge répartie, fortement synchronisée, comme preuve de la fraîcheur des messages, et non plus seulement comme une indication de celle-ci. Une telle utilisation crée à son tour des difficultés, dont nous discutons dans l'annexe suivante.
