Cryptanalyse des extensions d'authentification PPTP de Microsoft (MS-CHAPv2)

Bruce Schneier
Counterpane Systems
schneier@schneier.com

Mudge
L0pht Heavy Industries
mudge@l0pht.com

Résumé: Le protocole Point-to-Point Tunneling (PPTP) est utilisé pour protéger les connections PPP au-travers de liaisons TCP/IP. En réponse à [SM98], Microsoft a distribué des extensions au mécanisme d’authentification PPTP (MS-CHAP), appellées MS-CHAPv2. Nous présentons une vue d’ensemble des modifications apportées aux portions d’authentification et de génération des clefs de chiffrement de MS-CHAPv2, et évaluons les améliorations et les faiblesses qui persistent dans l’implémentation PPTP de Microsoft.

[texte complet anglais – PDF (Acrobat)] [texte complet anglais – Postscript]

1 Introduction

Le protocole Point-to-Point Tunneling (PPTP) [HPV+97] est un protocole qui permet aux connections [Sim94] Point-to-Point Protocol (PPP) d’être convoyées au travers d’un réseau IP en créant un réseau virtuel privé (VPN). Microsoft a implémenté ses propres algorithmes et protocoles afin d’intégrer PPTP. Cette implémentation de PPTP, appellée Microsoft PPTP, est largement utilisée dans des produits VPN commerciaux en particulier parce que le PPTP fait déjà partie des systèmes d’exploitation Windows 95, 98 et NT.

Le protocole d’authentification dans Microsoft PPTP est le protocole d’épreuve/réponse de Microsoft (MS-CHAP) [ZC98]; le protocole de chiffrement est le chiffrement Point to Point de Microsoft (MPPE) [PZ98]. Après la cryptanalyse de Microsoft PPTP [SM98] et la révélation publique de ses faiblesses importantes, Microsoft a mis à jour ses protocoles [Zor98a, Zor98b, Zor99]. La nouvelle version s’appelle MS-CHAP version 2 (MS-CHAPv2); l’ancienne version a été renommée MS-CHAP version 1 (MS-CHAPv1). MS-CHAPv2 est disponible sous la forme d’une mise à jour pour Microsoft Windows 95, Windows 98 et Windows NT 4.0 (DUN 1.3) [Mic98a,Mic98b]. Bien que cette mise à jour soit disponible, nous pensons que la plupart des implémentations utilisent MS-CHAPv1.

Ce document examine MS-CHAPv2 et discute comment il règle les failles de sécurité soulignées dans [SM98].

Les changements les plus importants de MS-CHAPv1 vers MS-CHAPv2 sont:

  • Le hachage faible LAN Manager n’est plus transmis en même temps que le hachage Windows NT plus fort. Ceci afin d’éviter que des casseurs automatiques de mots de passe, comme L0phtcrack (http://www.l0pht.com/l0phtcrack) ne cassent le premier hachage et d’utiliser l’information obtenue pour casser le hachage plus fort Windows NT.
  • Un système d’authentification pour le serveur a été introduit, afin d’empêcher des serveurs malicieux de se faire passer pour des utilisateurs légitimes.
  • Les paquets d’échange de mots de passe de MS-CHAPv1 ont été remplacés par un unique paquet d’échange dans MS-CHAPv2. Ceci afin d’empêcher l’attaque active de détournement (spoofing) des paquets d’échec de MS-CHAP.
  • MPPE utilise des clefs uniques dans chaque direction, afin d’empêcher l’attaque cryptanalytique triviale du XOR de chaque flux dans chaque direction qui supprime les effets du chiffrement.

Ces changements corrigent les faiblesses majeures de sécurité du protocole originel: l’inclusion d’une fonction de hachage LAN Manager et l’utilisation de la même clef de chiffrement OFB à plusieurs reprises. Toutefois, beaucoup de problèmes de sécurité restent sans correction, par exemple comment le client se protège lui-même, ou le fait que la clef de chiffrement dispose de la même entropie que le mot de passe de l’utilisateur et le fait qu’assez de données sont transmises sur la ligne et permettent à des attaquants de réaliser des attaques de chiffrement-et-comparaison.

Ceci dit, Microsoft n’a visiblement pas seulement profité de cette opportunité que pour corriger quelques faiblesses cryptographiques dans leur implémentation de PPTP, mais aussi pour améliorer la qualité de leur code. LA nouvelle version est beaucoup plus robuste contre les attaques de dénégation de service et ne laisse plus filtrer d’information au sujet du nombre de sessions VPN actives.

2 MS-CHAP, Versions 1 et 2

Le mécanisme d’épreuve/réponse de MS-CHAPv1 a été décrit dans [SM98]. En résumé:

  1. Le client fait une demande d’épreuve au serveur.
  2. Le serveur envoie une épreuve avec 8 octets aléatoires.
  3. Le client utilise le hachage LAN Manager de son mot de passe pour en dériver trois clés DES. Chacune de ces clés est utilisée pour chiffrer l’épreuve. Les trois blocs sont concaténés dans une réponse de 24 octets. Le client crée alors une seconde réponse de 24 octets en utilisant le hachage Windows NT, avec la même procédure.
  4. Le serveur utilise les hachages du mot de passe client, conservés dans une base de données, afin de déchiffrer ses réponses. Si les blocs une fois déchiffrés correspondent à l’épreuve, alors l’authentification est complète et un paquet de “succes” est transmis au client.

Cet échange a été modifié dans MS-CHAPv2. Le protocole révisé est le suivant:

1. Le client demande une épreuve au serveur.

2. Le serveur envoie en réponse une épreuve de 16 octets aléatoires.

3a. Le client génére un nombre aléatoire de 16 octets, appellé “l’épreuve égale d’authentification.”

3b. Le client génére une épreuve de 8 octets en hachant l’épreuve de 16 octets reçue à l’étape (2), les 16 octets de l’épreuve égale d’authentification générés à l’étape (3a) et le nom de l’utilisateur du client. (voir la section 3 pour les détails).

3c. Le client crée une réponse de 24 octets, en utilisant la fonction de hachage Windows NT et les 8 octets de l’épreuve générés à l’étape (3b). Ce processus est identique à celui de MS-CHAPv1.

3d. Le client transmet au serveur les résultats des étapes (3a) et (3c).

4a. Le serveur utilise les hachages du mot de passe du client, conservé dans une base de données, afin de déchiffrer les réponses. Si les blocs déchiffrés correspondent à l’épreuve, le client est authentifié.

4b. Le serveur utilise les 16 octets de l’épreuve égale d’authentification du client, tout comme le mot de passe haché du client, afin de créer une “réponse d’authentification” de 20 octets (voir la section 4 pour les détails).

5. Le client calcule aussi une réponse d’authentification. Si celle-ci correspond à celle reçue en réponse, le serveur est authentifié.

Une description générale des changements entre MS-CHAPv1 et MS-CHAPv2 est donnée en figure 1.

MS-CHAP version 1 MS-CHAP version 2
Négociation CHAP avec une valeur d’algorithme de 0x80. Négociation CHAP avec une valeur d’algorithme de 0x81.
Le serveur envoie une valeur épreuve de 8 octets. Le serveur envoie une valeur de 16 octets qui devra être utilisée par le client dans la création d’une valeur d’épreuve de 8 octets.
Le client envoie 24 octets LANMAN et 24 octets NT en réponse aux 8 octets d’épreuve. Le client envoie 16 octets d’épreuve égale qui ont été utilisés pour créer l’épreuve de 8 octets cachés, et la réponse NT en 24 octets.
Le serveur envoie une réponse indiquant le SUCCES ou l’ECHEC. Le serveur envoie une réponse indiquant SUCCES ou ECHEC et transmet une réponse d’authentification de 16 octets.
Le client décide de continuer en fonction de la réponse SUCCES ou ECHEC du serveur. Le client décide de continuer en fonction de la réponse SUCCES ou ECHEC. En plus, le client vérifie la validité de la réponse d’authentification et se déconnecte si elle est incorrecte.

Figure 1: quelques différences de base entre les authentifications MSCHAP v1 et MSCHAP v2

Ce protocole fonctionne, et élimine la faiblesse la plus importante qui frappait MS-CHAPv1. Dans MS-CHAPv1, deux valeurs parallèles de hachage étaient transmises par le client au serveur: le hachage LAN Manager et le hachage Windows NT. Il s’agissait de deux hachages différents d’un même mot de passe. Le hachage LAN Manager est beaucoup plus faible que celui de Windows NT, et un programme à briser les mots de passe comme L0phtcrack était capable de briser le hachage LAN Manager et d’utiliser cette information pour briser le hachage Windows NT [L97]. En éliminant le hachage LAN Manager dans MS-CHAPv2, Microsoft a rendu cette attaque de conquête par la division impossible. Malgré cela, la sécurité de ce protocole reste basée sur le mot de passe utilisé, et L0phtcrack peut toujours casser les mots de passe faibles par une attaque à dictionnaire [L99].

Comme nous en discuterons plus loin, des couches multiples de hachage sont utilisées à différentes étapes de MS-CHAPv2. Bien que ce hachage soit utilisé pour dissimuler certaines valeurs, leur signification cryptographique n’est pas claire. Elles semblent n’avoir pour effet qu’une réduction de la vitesse d’exécution du protocole.

Nous avons aussi des inquiétudes quand à la quantité de contrôle dont dispose le client sur l’influence portant sur les 8 octets d’épreuve utilisés, bien que nous n’ayons pas encore conçu une attaque viable capable de l’exploiter. Cela ouvre certainement une attaque par canal subliminal, qui peut être exploitée dans d’autres contextes.

3 MS-CHAPv2: dériver l’épreuve 8 octets à partir de la réponse 24 octets

Dans MS-CHAPv1, le serveur envoie au client une épreuve aléatoire de 8 octets. Cette épreuve est utilisée avec le mot de passe du client et une fonction de hachage afin de créer une paire de réponses sur 24 octets.

Dans MS-CHAPv2, le serveur envoie au client une épreuve de 16 octets. Cette épreuve n’est pas utilisée directement par le client; il en dérive une valeur de 8 octets. Ce processus de dérivation est le suivant:

  1. Le client crée un nombre aléatoire de 16 octets, appelé l’épreuve égale d’authentification.
  2. Le client concatène l’épreuve égale d’authentification avec l’épreuve de 16 octets reçue du serveur et le nom d’utilisateur du client.
  3. Le client hache le résultat avec SHA-1 [NIST93].
  4. Les premiers huit octets du hachage deviennent l’épreuve 8 octets.

Ce sont ces 8 octets que le client va utiliser pour chiffrer le hachage local du mot de passe 16 octets (en utilisant la fonction de hachage Windows NT) afin d’obtenir une réponse 24 octets, que le client va transmettre au serveur. Cette méthode est identique à MS-CHAPv1 et a été décrite dans [SM98].

3.1 Analyse

Les raisons qui ont poussé à rendre ce protocole aussi compliqué ne nous semblent pas claires. Au premier regard, il semble raisonable que le client n’utilise pas l’épreuve du serveur directement, puisqu’elle peut être perçue par une personne à l’écoute. Mais au lieu de dériver une nouvelle épreuve à partir d’une information qui serait secrète, le hachage du mot de passe par exemple, le client utilise un nombre aléatoire unique qui est envoyé plus tard au serveur. Il n’y a aucune raison qui empêche le client d’utiliser directement l’épreuve du serveur et de ne pas utiliser du tout l’épreuve égale d’authentification.

4 MS-CHAPv2: dériver la réponse d’authentification 20 octets

Dans MS-CHAPv2, le serveur transmet au client une réponse d’authentification de 20 octets. Le client calcule la même valeur, et la compare à la valeur reçue du serveur afin de compléter le processus d’authentification mutuel. Cette valeur est créée de la manière suivante:

  1. Le serveur (ou le client) hache le hachage Windows NT de 16 octets avec [Riv91] pour obtenir un hachage du hachage du mot de passe (le serveur conserve le mot de passe haché du client par MD4; il s’agit de la valeur de hachage de Windows NT).
  2. Le serveur concatène le hachage de hachage de mot de passe, la réponse 24 octets NT et une chaîne littérale “constante et magique du serveur au client” puis hache le résultat avec SHA.
  3. Le serveur concatène les 20 octets en sortie du SHA avec l’étape (2), l’épreuve originelle de 8 octets générée (voir section 3) et la chaîne littérale “coussin pour lui faire plus qu’une itération” puis hache le résultat avec SHA.

Les 20 octets résultants sont la réponse mutuelle d’authentification.

4.1 Analysis

A nouveau, le processus est plus compliqué que requis. Il n’y a aucune raison pour utiliser deux fois de suite SHA; une simple fonction de hachage dispose déjà de ses propriétés de sécurité.

5 Analyse de MS-CHAPv2

Nous ne savons pas pourquoi Microsoft a choisi d’utiliser un protocole aussi compliqué, parce qu’il n’est pas plus fort que ce qui suit:

  1. Le serveur envoie au client une épreuve de 8 octets.
  2. Le client chiffre le hachage local du mot de passe (16 octets) avec l’épreuve de 8 octets et envoie au serveur la réponse 24 octets, 8 octets d’épreuve qui lui sont propres et le nom de l’utilisateur.
  3. le serveur envoie un paquet de réussite/échec avec une réponse 24 octets de l’épreuve client, qui est le hachage du hachage du mot de passe de l’utilisateur, chiffré avec l’épreuve de 8 octets.

Le mauvais côté du protocole MS-CHAPv2 est qu’une personne à l’écoute peut obtenir deux exemplaires du même texte en clair, chiffré avec deux clés différentes. Toutefois, dans le modèle actuel, observer le réseau pour n’importe quelle durée de temps vous donnera toujours des choix multiples d’épreuve/réponse d’utilisateurs à mesure que l’utilisateur entre et sort, et elles seront chiffrées par des clefs différentes.

En l’état, un écouteur passif sera capable d’obtenir les 8 octets d’épreuve et la réponse 24 octets avec les informations transmises. L’outil répandu L0phtcrack [L97], qui casse les mots de passe Windows NT, fonctionne sur ces données en entrée. Cette tâche est rendue beaucoup plus facile que dans MS-CHAPv1; L0phtcrack a d’abord brisé le premier, puis a utilisé cette information pour briser le second [L99]. L0phtcrack peut toujours casser la plupart des mots de passe du hachage seul de Windows NT [L97]. Et ceci ne règle pas le problème de l’utilisation du hachage de l’utilisateur pour les clefs MPPE, l’authentification PPTP, etc. Sans voir de négociation préalable, et des méthodes de clés publiques/privées pour échanger une clé aussi importante.

5.1 Attaques par compatibilité arrière

Puisque Microsoft a tenté de conserver une certaines compatibilité avec MS-CHAPv1, il est possible à un attaquant de monter une “attaque par compatibilité arrière” contre MS-CHAP. Dans cette attaque, l’attaquant va convaincre aussi bien le client que le serveur qu’ils ne peuvent négocier avec le protocole plus sûr CHAPv2, mais que seul le MS-CHAPv1 est disponible.

Dans sa documentation, Microsoft annonce que les systèmes d’exploitation tenteront de négocier d’abord avec MS-CHAPv2, et ensuite MS-CHAPv1 si la première négociation échoue [Mic99]. En plus, il est possible de demander au serveur qu’il requière MS-CHAPv2. Nous trouvons ce scénario peu plausible pour deux raisons. La première, la bascule pour couper la compatibilité arrière se trouve dans la base de registres, et elle peut être difficile à trouver. La seconde, comme les anciennes versions de Windows ne peuvent utiliser MS-CHAPv2, la compatibilité arrière doit être activée. Nous en concluons que les attaques par compatibilité arrière sont une menace importante.

6 Changements apportés à MPPE

Le mécanisme de chiffrement originel de protocole Point to Point de Microsoft utilise les mêmes clefs de chiffrement dans chaque direction (client vers serveur et serveur vers client). Comme la routine de chiffrement des données brutes est le chiffrement de flux RC4 [Sch96], ceci rend possible une attaque cryptographique par XOR des deux flux l’un contre l’autre, et de réaliser une cryptanalyse classique sur le résultat.

Dans une version plus récente, les clefs MPPE sont dérivées de références MS-CHAPv2 et une clef unique est utilisée dans chaque direction. Les clefs pour chaque direction sont toujours dérivées d’une même valeur (le hachage du mot de passe du client) mais diffèrent selon la direction.

6.1 Dérivation des clefs MPPE Keys à partir des références MS-CHAPv2

Les clés MPPE peuvent avoir soit 40 bits, soit 128 bits et peuvent être dérivées soit des références MS-CHAPv1, soit des références MS-CHAPv2. Le protocole de dérivation originel (de MS-CHAPv1) a été décrit dans [SM98]. De manière brêve, le hachage du mot de passe est haché à nouveau avec SHA, puis tronqué. Pour une clé de 40 bits, le hachage SHA est tronqué à 64 bits, puis les 24 bits de poids fort sont fixés à 0xd1269e. Pour une clé 128 bits, le SHA est tronqué à 128 bits. Cette clef est utilisée pour chiffrer les échanges entre le client et le serveur, et du serveur vers le client ce qui crée une vulnérabilité majeure. Ceci a été corrigé dans MS-CHAPv2.

La dérivation des clefs MPPE des références MS-CHAPv2 fonctionne comme suit:

  1. Hachage du hachage 16 octets du mot de passe, de la réponse 24 octets de l’échange MS-CHAPv2 et d’une constante de 24 octets (la chaîne “This is the MPPE Master Key”) avec SHA. Tronqué pour obtenir une clé maître-maître de 16 octets.
  2. En utilisant un procédé déterministe, convertir la clé maître-maître vers une paire de clefs de session.

Pour une session à 40 bits, ceci est fait de la manière suivante:

  1. Hachage de la clé maître-maître, 40 octets de 0x00, une constante de 84 octets et 40 octets de 0xF2 avec SHA. Tronqué pour obtenir une sortie de 8 octets.
  2. Fixer les 24 bits de poids fort à 0xd1269e, ce qui donne une clé de 40 bits.

Les constantes magiques sont différentes, selon la clé est utilisée pour chiffrer les échanges du client vers le serveur, et du serveur vers le client.

Pour une session à 128 bits, le processus est le suivant:

  1. Hachage de la clé maître-maître, 40 octets de 0x00, une constante de 84 octets (constante magique 2 ou 3) et 40 octets de 0xF2 avec SHA. Tronqué afin d’obtenir une sortie de 16 octets.
6.2 Analyse

Cette modification signifie que des clefs uniques sont utilisées dans chaque direction, mais ne résoud pas le problème des clefs faibles. Les clefs sont toujours une fonction du mot de passe, et ainsi ne contiennent pas plus d’entropie que le mot de apsse. Même si l’algorithme RC4 peut en théorie avoir 128 bits d’entropie, les mots de passe actuellement utilisés n’en n’ont pas autant. Ceci dit, utiliser des clefs différentes dans chaque direction est une amélioration majeure du protocole.

7 Conclusions

Microsoft a amélioré PPT afin de corriger les failles majeures de sécurité décrites dans [SM98]. Toutefois, les faiblesses fondamentales dans les protocoles d’authentification et de chiffrement persistent, et sont pas plus sûres que le mot de passe choisi par l’utilisateur. A mesure que les ordinateurs sont plus rapides, les attaques contre les fichiers de mots de passe distribuées seront plus faciles, et les dictionnaires de mots de passe, les mots avec chiffres, la casse, les mots inversés, les acronymes, les mots avec l’addition de ponctuation deviennent plus grands. Comme les protocoles d’authentification et d’échange des clefs (qui ne permettent pas d’attaques passives par dictionnaire contre le mot de passe de l’utilisateur) sont possibles, l’échange de clefs chiffrées BM92,BM94] et ses variantes [Jab96,Jab97,Wu98], IPSec, il semble imprudent pour Microsoft de continuer à faire reposer sa sécurité sur des mots de passe. Nous espérons que PPTP va continuer à décroître en utilisation au profit d’IPSec.

8 Bibliographie

[BM92] S.M. Bellovin et M. Merritt, “Encrypted Key Exchange: Password-Based Protocols Secure Against Dictionary Attacks,” Proceedings of the IEEE Symposium on Research in Security and Privacy, May 1992, pp. 72-84.

[BM94] S.M. Bellovin et M. Merritt, “Augmented Encrypted Key Exchange: A Password-Based Protocol Secure Against Dictionary Attacks and Password File Compromise,” AT&T Bell Laboratories, 1994.

[HPV+97] K. Hamzeh, G.S. Pall, W. Verthein, J. Taarud, et W.A. Little, “Point-to-Point Tunneling Protocol,” Internet Draft, IETF, Jul 1997. http://www.ietf.org/internet-drafts/draft-ietf-pppext-pptp-10.txt. [link dead]

[Jab96] D. Jablon, “Strong Password-Only Authenticated Key Exchange,” ACM Computer Communications Review, Oct 96, pp. 5-26.

[Jab97] D. Jablon, “Extended Password Key Exchange Protocols Immune to Dictionary Attacks,” Proceedings of the Sixth Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, IEEE Computer Society, 1997, pp. 248-255.

[L97] L0pht Heavy Industries, Inc., “A L0phtCrack Technical Rant,” Jul 1997. http://www.l0pht.com/l0phtcrack/rant.html. [link dead]

[L99] L0pht Heavy Industries, Inc, L0phtcrack, 1999, http://www.l0pht.com/l0phtcrack/. [link dead; see http://www.atstake.com/research/lc3/]

[Mic96a] Microsoft Corporation, Advanced Windows NT Concepts, New Riders Publishing, 1996. Chapitre concerné à http://www.microsoft.com/communications/nrpptp.htm.

[Mic96b] Microsoft Corporation, “Point-to-Point Tunneling Protocol (PPTP) Frequently Asked Questions,” Jul 1996. [Mic99] Microsoft, Corporation, “Windows 98 Dial-Up Networking Security Upgrade Release Notes,” Feb 1999, http://support.microsoft.com/support/kb/articles/Q189/7/71.asp.

[Mic98a] Microsoft Corporation, “Frequently Asked Questions about Microsoft VPN Security,” Dec 1998, http://www.microsoft.com/NTServer/commserv/deployment/moreinfo/VPNSec_FAQ.asp [link dead; see http://www.microsoft.com/ntserver/support/faqs/VPNSec_FAQ.asp]

[Mic98b] Microsoft Corporation, “Microsoft Windows 95 Dial-Up Networking 1.3 Upgrade Release Notes,” 1998, http://support.microsoft.com/support/kb/articles/q154/0/91.asp

[NIST93] National Institute of Standards and Technology, “Secure Hash Standard,” U.S. Department of Commerce, May 1993.

[PZ98] G.S. Pall et G. Zorn, “Microsoft Point-to-Point Encryption (MPPE) Protocol,” Network Working Group, Internet Draft, IETF, Mar 1998. http://www.ietf.org/internet-drafts/draft-ietf-pppext-mppe-03.txt. [link dead]

[Riv91] R. Rivest, “The MD4 Message Digest Algorithm,” Advances in Cryptology-CRYPTO ’90 Proceedings, Springer-Verlag, 1991, pp. 303-311.

[Sim94] W. Simpson, “The Point-to-Point Protocol (PPP),” Network Working Group, STD 51, RFC 1661, Jul 1994. http://www.isi.edu/in-notes/rfc1661.txt.

[Sch96] B. Schneier, Applied Cryptography, 2nd Edition, John Wiley & Sons, 1996.

[SM98] B. Schneier et Mudge, “Cryptanalysis of Microsoft’s Point-to-Point Tunneling Protocol (PPTP),” Proceedings of the 5th ACM Conference on Communications and Computer Security, ACM Press, pp. 132-141. http://www.schneier.com/pptp.html.

[Wu98] T. Wu, “The Secure Remote Password Protocol,” Proceedings of the 1998 Internet Society Network and Distributed System Security Symposium, Mar 1998, pp. 97-111.

[ZC98] G. Zorn et S. Cobb, “Microsoft PPP CHAP Extensions,” Network Working Group Internet Draft, Mar 1998. http://www.ietf.org/internet-drafts/draft-ietf-pppext-mschap-00.txt.

[Zor98a] G. Zorn, “Deriving MPPE Keys from MS-CHAP V1 Credentials,” Network Working Group Internet Draft, Sep 1998. http://www.ietf.org/internet-drafts/draft-ietf-pppext-mschapv1-keys-00.txt.

[Zor98b] G. Zorn, “Deriving MPPE Keys from MS-CHAP V2 Credentials,” Network Working Group Internet Draft, Nov 1998. http://www.ietf.org/internet-drafts/draft-ietf-pppext-mschapv2-keys-02.txt.

[Zor99] G. Zorn, “Microsoft PPP CHAP Extensions, Version 2,” Network Working Group Internet Draft, Apr 1999. http://www.ietf.org/internet-drafts/draft-ietf-pppext-mschap-v2-03.txt.

up to Academic

Sidebar photo of Bruce Schneier by Joe MacInnis.