CipherSaber - Chiffrement en kit


Sabre laser de chiffrement

Au détour d'une naviguation web fortuite mais bienheureuse, je suis tombé sur CipherSaber. Vous savez, c'est ce genre de moment où on tombe sur une initiative sympa, facile à suivre et qui fait sens. Bref, j'ai accroché tout de suite, alors j'ai laissé tomber ce que j'étais en train de faire et y ai consacré mes heures suivantes.
CipherSaber, c'est la reprise du concept selon lequel il faut en savoir faire un minimum, tout seul, comme un grand. A l'instar des Jedis dans l'univers Star Wars qui vont réaliser eux-même leur sabre laser (vous comprenez maintenant le nom du projet), on nous propose de réaliser nous-même notre petit logiciel de chiffrement. Je vous laisse parcourir le site pour une explication plus en détail de la philosophie derrière ce petit combat pour la cryptographie, mais l'idée est là : A n'importe quel moment, nous devrions être capable de produire un logiciel de chiffrement suffisamment solide pour être utilisé sans risque, afin de s'affranchir des éventuelles lois contre l'exportation et garantir notre liberté de parole, autant que faire se peut. Joli programme !
Voici les instructions que l'on nous fournit pour réaliser cet outil (directement traduites depuis le lien du début de l'article) :

  1. Utiliser l'algorithme de chiffrement ARCFOUR (ou RC4), tel que décrit par exemple ici.
  2. Chaque fichier chiffré se compose d'un Vecteur d'Initialisation (IV) de 10 octets, puis du contenu chiffré. Un nouveau vecteur aléatoire devra être généré à chaque chiffrement de fichier.
  3. La clé de chiffrement se compose elle de la clé que l'utilisateur nous fournit suivie de ce même Vecteur d'Initialisation.

Et effectivement, ce sont les seules indications dont nous aurons besoin. Une fois le programme réalisé, nous aurons la possibilité de déchiffrer un certificat en gif, preuve de notre petite réussite. Si l'idée vous plait et que vous souhaitez vous contenter de ces informations pour vous-même construire votre CipherSaber, alors ne revenez lire la suite de cet article que quand vous aurez votre certificat !

ARCFOUR ?

ARCFOUR, c'est l'algorithme libre identique au RC4 qui lui est une propriété de RSA Security. Ici, pas de clé publique/privée, pas d'algorithme alambiqué, mais une solution implémentable "de tête", pour peu qu'on fasse l'effort de la comprendre et d'en retenir les fondements.

Bon, ok, c'est gentil, mais le ARCFOUR moi, je ne le connais pas. Qu'à cela ne tienne, il suffira de suivre le lien donné ou de rechercher RC4 sur le web pour que l'algorithme nous tombe tout cru, ou presque. Mais j'insiste, le but ici est de pouvoir à tout moment réécrire ce logiciel de mémoire, donc on apportera un soin tout particulier à en retenir les principes de fonctionnement.

C'est un algorithme de chiffrement à flot, il repose sur deux phases :

  1. A partir de la clé K que nous donne l'utilisateur, on va générer un tableau d'état S que l'on va mélanger de nombreuses fois afin d'obtenir une suite de chiffres pseudo-aléatoires.
  2. On va ensuite chiffrer le contenu sensible par un simple XOR entre ses octets et ceux du tableau d'état. Si c'est votre tout premier pas dans le monde de la cryptographie, sachez que l'opération XOR est "réversible" (il y a sûrement un terme mathématique approprié à cette propriété, pardon à eux pour mon ignorance), c'est à dire que si A xor B = C, alors A xor C = B. On utilise donc exactement la même procédure et la même clé pour chiffrer et déchiffrer.

Maintenant qu'on saisit la généralité de la méthode, voyons comment la réaliser plus en détail :

  1. Créons notre tableau d'état :
    1. Soit la clé K d'une taille de 256 octets (si elle fait moins, on la répète à la suite jusqu'à obtenir 256 octets pile)
    2. Construisons un tableau S de 256 valeurs, chacune contenant son index basé à 0 : S[0] = 0, S[255]=255.
    3. Mélangeons S, avec i allant de 0 à 255 et j démarrant à 0:
      1. Inverser l'élément i de S avec celui de rang (S[i]+K[i])+j, j étant le rang du "mélangé" précédent. Autrement dit, ajouter S[i]+K[i] à j et inverser S[i] et S[j]
  2. Chiffrons :
    1. Boucler sur chaque octet du fichier à chiffrer, et avec i et j démarrant à 0 :
      1. incrémenter i
      2. Un peu comme précédemment, inverser l'élément i de S avec celui de rang (S[i]+j), j étant le rang du mélangé précédent. Autrement dit, ajouter S[i] à j et inverser S[i] et S[j]
      3. Combiner l'octet à chiffrer avec la valeur de l'élément S[i]+S[j] par un XOR.

J'ai conscience que ce n'est sûrement pas clair au premier abord, mais j'ai essayé ici de résumer l'algorithme par ses opérations logiques, afin que ce soit appréhendable pour l'esprit et donc plus aisé à retenir. Pour une version plus proche de l'implémentation, il vous reste votre moteur de recherche préféré. Retenez par contre un détail important : Chaque éléments de chaque tableau est un octet, il en va de même pour i et j. Par conséquent, chaque addition se fait modulo 256.

Une fois votre implémentation écrite, n'hésitez pas à la tester. Un petit chiffrement/dechiffrement pour s'assurer que tout va bien ne sera pas de trop, croyez-moi.

IVs et tests

Maintenant que votre ARC4 est implémenté et testé, reste à en faire quelque chose. Oui car utilisé tel quel, c'est un algorithme tout à fait prévisible, or nous recherchons un chiffrement suffisament fort. La règle qui semble être celle de base, c'est qu'un même chiffrement appliqué à un même fichier ne doit pas donner le même résultat. L'idée est donc d'ajouter un IV, l'Initialisation Vector dont on parlait plus haut. Ainsi, lors du chiffrement, on va générer un IV aléatoire de 10 octets, qu'on va :

  • Mettre à la suite de la clé que nous a fourni l'utilisateur pour produire une clé unique à fournir à l'argorithme de chiffrement
  • Ajouter en clair au début du fichier crypté, afin quand même que l'on puisse connaitre la clé à utiliser pour déchiffrer.

L'IV est donc une donnée "publique" puisqu'en clair, mais cela suffit à notre besoin de non-répétition. Par contre son choix est important, crucial même, alors attention à la méthode de génération pseudo aléatoire que vous allez utiliser.

Et voilà ! Une fois ce dernier détail implémenté, il ne vous reste plus qu'à tester votre programme sur les fichiers chiffrés fournis sur le site. Si vos tests ne fonctionnent pas, vous trouverez dans la FAQ quelques points à vérifier dans votre code pour trouver le bug. Voici ceux qui m'ont servi :

  • Si vous programmez en C/C++, ouvrez vos fichiers en binaire... On aurait tendance à l'oublier.
  • Double, triple-vérifiez vos index et les combinaisons de tailles, ajout, suppression, décalages.

Aller un peu plus loin

Ainsi que vous avez peut-être lu quelque part, certaines faiblesses ont été décelées dans l'ARC4. Elles sont notamment à la base des attaques contre le protocole WEP maintenant si rapides qu'on peut faire tomber un réseau Wifi en 15 minutes. L'auteur recommande donc de passer à... CipherSaber 2 ! <Musique épique, et là avouez, ça picote !>

En fait ce n'est qu'une petite évolution de votre programme actuel : le moyen le plus simple de sécuriser son CipherSaber est de démultiplier le nombre de mélanges de S. Ainsi, à l'étape 3 de la création de notre tableau d'état décrite ci-dessus, on va non pas effectuer ce mélange complet de S une fois mais N fois, N étant une donnée qu'il faudra bien évidemment connaitre lors du déchiffrement. Pour être tranquille, utilisez un N de 15 ou 20.

Aller vraiment au bout de son sabre

Mais toute bonne votre méthode de chiffrement soit-elle, si vous utilisez une passphrase de 3 lettres ou votre date d'anniversaire, tout cela n'aura servi à rien. Ce n'est pas le but de l'article que de décrire un moyen efficace d'en générer une, mais sachez qu'il existe des méthodes comme celle décrite sur Diceware (c'est depuis ce site que j'ai découvert CipherSabre, ce n'est donc pas par hasard que je met ce lien ici). Retenez tout de même qu'un mot de passe n'est pas une.. hm, et bien phrase de passe. Le premier est adapté à un contexte local, lorsque vous avez besoin d'un mot court à entropie forte. La passphrase, de ce que j'en comprend, permet de s'affranchir plus ou moins du coté "impossible à retenir" d'un vrai de mot de passe fort, en augmentant la taille de la clé à 15 ou 20 caractères avec des mots courants, tout en fournissant pour peu qu'elle soit bien choisie (aléatoire) un entropie plus que satisfaisante.

Et alors ?

Et bien voilà, maintenant vous savez écrire un logiciel de chiffrement. Gardez bien-sûr conscience qu'il ne remplacera jamais une vraie solution comme OpenPGP, qui malgré sa puissance est deja suffisament mal diffusée pour qu'on n'en rajoute pas à vouloir utiliser notre solution personnelle moins pratique et moins sûre. Mais enfin, à votre niveau vous savez reproduire tout seul un outil basique mais potentiellement utile en situation réelle, vous avez limité votre dépendance à ceux qui savent, ceux qui dirigent, ceux en qui on vous demande d'avoir une confiance presque aveugle. Et enfin, vous en aurez un peu appris sur les fondements de la cryptographie, peut-être plus qu'en jouant avec AirCrack sur votre propre réseau ou celui du voisin...

, , , , ,

  1. #1 by david - août 17th, 2009 at 17:37

    Pas de nom pour la propriété de xor dans l'article de Wikipedia, par contre je j'ai trouvée mieux décrite par: (A xor B) xor B = A
    qui est ce qu'on utilise directement en cryptographie.
    Concernant l'aspect politique, pour aller plus loin que le site initial, un problème qui me semble majeur est que il n'est pas prévu de cacher que l'on utilise de la cryptographie. Savoir fabriquer soi-même une bombe dans un pays qui l'interdit n'autorise pas plus à s'en servir sans se créer des ennuis. Ceci dit, l'initiative est pertinente, à nous maintenant de ciphersaberiser nos eMule...

  2. #2 by Wett - août 18th, 2009 at 09:36

    Effectivement la crypto ne résoud pas ce genre de problèmes. La stéganographie pourrait être l'objet d'un (tout) autre article, mais je ne connais aucune méthode sûre d'en faire. Et très franchement, je ne suis pas sûr qu'il en exitera une un jour... Du peu que j'en sais, tout reposerait plus ou moins sur le secret de la méthode. Autrement, avec des analyses statistiques des données qui circulent, il est serait facile de repérer un contenu crypté qui ressemblerait beaucoup à du bruit. A moins de le noyer dans un contenu "normal", mais comment en générer en quantité suffisante sans que ce soit louche ?
    Je crois que la stégano ne peut être viable qu'en échangeant une quantité ultra minime de données. On planque ça dans une photo qu'on joint à un mail banal et pas plus.

    "Savoir fabriquer soi-même une bombe dans un pays qui l’interdit n’autorise pas plus à s’en servir sans se créer des ennuis."
    Tout à fait ! Par contre, je me permet de repréciser que la loi ne concerne pas que l'utilisation de la crypto mais aussi son exportation/importation, chose que CipherSaber permet de contourner à petite échelle.

    Quant au p2p, il serait dommage de réduire la crypto à ça... Et d'ailleurs impossible de réduire la problématique du p2p à la crypto, il manque la question de l'anonymat. Il existe plusieurs solutions, un peu à "l'essai" en ce moment, qui se penchent sur l'échange secret et anonyme de données (allant au delà du simple p2p). Certaines se basent sur des projets de recherche et ont l'air à peu près fiables pour un threat model pas trop oppressant, je pense notamment à Tor.

  3. #3 by david - août 18th, 2009 at 14:55

    Dans une certaine même idée il me vient à l'esprit la série des Tiny Encryption Algorithms :
    The first published version of TEA was supplemented by a second version that incorporated extensions to make it more secure, Block TEA (sometimes referred to as XTEA)[...].
    A third version (XXTEA), published in 1998, described further improvements for enhancing the security of the Block TEA algorithm.
    http://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm
    contient les liens vers les descriptions des versions.
    En lisant, il semble que XXTEA est sûr pour être utilisé au même motif que CipherSaber. Par contre sa complexité est un peu plus grande...

(will not be published)

  1. No trackbacks yet.