CRYPTOGRAPHIE FRACTALE

Commentaire de verdy_p le 18/06/2007 17:53:14

Il n'est pas nécessaire de faire dépendre les permutations de la taille du fichier.
En revanche, coder en tête du flux en clair la taille en bits de la source est utile et suffit à produire des bits supplémentaires d'entropie en début de séquence, et si on utilie la technique du feedback, permet d'éviter de conserver l'identité de l'entropie entre deux messagers distincts cryptés avec la même clé (ou séquence déduite de la clé).

D'une façon générale, c'est la méthode de combinaison "message_crypté = message_clair XOR suite(clé)" qui est le point le plus faible ici, car la suite dépendant de laclé est nécessairement finie (et ilest faiule de déduire cette longueur de suite par un calcul de FFT (et recherche des fréquences d'amplitude la plus élevée). D'où l'utilité du feed-back, qui permet de modifier la suite à chaque cycle (en fonction du message transporté) au lieu de la reproduire à l'identique à chaque cycle.

L'idée des permutations des termes de la suite à chaque cycle est aussi intéressante en plus du feedback progressif.

Une idée toute bête:
* imaginons un message clair de 30 kilo-octets.
* on génère d'abord un vecteur d'initialisation de 1 kilooctet de façon aléatoire V(n): peu importe le contenu, il doit seulement ne pas être réutilisé pour deux messages différents, n'a pas besoin d'être révélé directement (ces nombres servent à augmenter l'entropie du message initial en augmentant sa longueur pour profiter au maximum de l'effet feedback dès le début)
* de la clé secrète on génère une permutation secrète des nombres de 1 à 1024 (la suite P(n) est secrète et aussi précieuse que la clé secrète). Ces nombres serviront à sélectionner un des octets du vecteur en cours. (Il y a factorielle 1024 permutations possibles, bien plus qu'il n'en faut à partir de n'importe quelle longueur de clé secrète légale; on peut se servir par exemple de la clé secrète pour initialiser un générateur pseudo-alétoire à concruence afin de réaliser les tirages de permutations entre P(n) et P(r(n)) où n progresse de 0 à 1023, et r(n) est un tirage de nombre entre 0 et 1023 issu de ce générateur, le vecteur P(n) étant initialisé au début par tous les entiers de 0 à 1023, qui se retrouvent ainsi mélangés (après 1024 boucles) grace à la clé secrète); cette permutation secrète permettra de mélanger plus tard les octets du vecteur de cryptage.
* Pour chaque bloc clair de 1Ko du message clair à crypter (préfixé du codage de sa taille totale réelle codée sur au moins 64 bits, et suffixé à la fin de 1024 octets nuls), sachant que le dernier bloc peut contenir moins de 1024 octets tant que chacun des 1024 octets nuls sont présents dans ce bloc ou le précédent:
* Pour chaque octet M(n) du bloc clair à crypter,
** on calcule: V'(N) = M(n) XOR V(n) XOR V(P(n)) XOR XOR S(i)
** on émet en sortie M'(n) = V(n) (autrement dit les octets cryptés sont permutés et proviennent du bloc précédent s'il y en a un, ou du vecteur alétoire d'initialisation)
* où S(i) est un vecteur pseudo-aléatoire de longueur arbitraire (mais de cycle suffisamment long) dépendant de la clé secrète (par exemple ton générateur pseudo-alétoire fractal, s'il est sûr...)
* à la fin de chaque bloc de 1Ko on remplace V=V' (d'où la nécessité à la fin de crypter 1024 octets nuls supplementaires après le message clair, pour émettre la totalité du message)
* à la fin, ce qui reste dans V'(n) n'a aucune importance (c'est le résultat du cryptage des 1024 derniers octets nuls, avant permutation) et n'a pas besoin d'être transmis.

Au décryptage, le premier bloc de 1Ko de données cryptées ne contient AUCUNE information du mesage en clair, mais il est absolument nécessaire pour interprêter le reste du message, notamment connaitre la longueur exacte du message clair et en déduire où commenceront les derniers octets nuls dont le cryptage n'a pas été transmis.

Parmi les variantes qu'on peut proposer, on peut suggérer de modifier entre chaque bloc de 1Ko le vecteur secret de permutation P(n), en opérant dessus de nouvelles permutations à l'aude du même générateur initilisé avec la clé secrète.

Ces permutations ont pour effet de gommer les cycles résiduels provenant du vecteur pseudo-aléatoire S(i) généré par ton algo de cryptage fractal (ou tout autre générateur pseudo-aléatoire). Le feedback dans cette méthode reste progressif mais utilise un des 1024 octets précédents du message crypté choisis parmi un grand nombre au lieu de reprendre seulement l'octet précédent (qui n'est pas forcément très bon si le message clair contient des répététions et une entropie faible)

Le défaut de cette méthode est que le message crypté a une longueur augmentée de 1024 octets : pas très génant pour crypter un fichier voire un courriel ou une signature, mais génant si on doit crypter de nombreux petits messages comme des champs indépendants d'une table de base de données, ou des datagrammes UDP indépendants transmis sur une connexion à taux d'erreur ou de perte important et sans protocole de récupération des données manquantes, ni garantie d'ordre de transmission de ces datagrammes dans un réseau étendu hétérogène comme l'Internet:

Pour ce type d'applications àmessage courts, le vecteur de 1Ko pourra être réduit, mais il vaut mieux utiliser un algo de signature et numéroter explicitement les datagrammes afin de connaitre et reproduire l'état du générateur en réception, même s'il y manque des données; l'autre solution c'est IPSec et/ou un canal d'encpsulation VPN sur TCP pour transporter les datagrammes sur une connexion fiable sans perte, de sorte que le cout du vecteur initial de 1Ko est faible et réparti sur l'ensemble des datagrammes transmis)

D'une façon générale, sur les messages longs, il est toujours intéressant d'y appliquer systématiquement une compression classique (deflate par exemple) des messages clairs avant leur cryptage pour en augmenter l'entropie. C'est valable quel que soit l'algo de cryptage utilisé ensuite. On s'en passera seulement si on sait que le message clair est déjà fortement compressé (un flux audio ou vidéo MPEG par exemple (non compris les entêtes de présentation et de formatage de flux qui ont une entropie faible et mériteraient malgré tout d'être compressés même si leur taille est souvent très faible proportionnellement au reste du flux, car ils révèlent des infos à protéger comme les métadonnées, étiquettes de contenus ou de langues, copyrights, signatures d'auteurs, tables de paramètres identifiant les flux et les codecs utilisés, titres, sous-titres, textes HTML, javascripts d'interactivité...)

Ne pas oublier qu'un fichier MPEG ou même une image JPEG ou PNG est d'abord un conteneur composite pour pleins de flux de natures différentes et d'entropies très différentes. Si on transmet ces conteneurs de contenus audio-vidéo en clair, la compression ne s'impose généralement pas, mais si on veut crypter, on doit se demander si le reste du conteneur doit être ou non crypté, et l'utilisation qu'on pourrait faire de ces autres données encapsulées en dehors du flux audio/vidéo déjà compressé par un codec performant. L'autre problème du cryptage de ces flux est leur utilisation: que se passe-t-il si on ne le reçoit pas en totalité (par exemple un flux en direct dont on manque le début)? Il faut bien pouvoir trouver des points de récupération régulièrement et assez souvent, et le cryptage doit se limiter aux segments entre ces points. C'est pour ça que MPEG spécifie comment on peut encapsuler des segments cryptables au sein même du codage d'encapsulation du conteneur (faute de quoi, la TV cryptée ne marcherait pas, ou les abonnés raleraient sur la durée excessive du temps de réponse en cas de changement de chaîne si les segments sont trop longs, ou de coupures trop longues de l'émission en cas d'erreur de réception irrécupérable!)