CRYPTOGRAPHIE FRACTALE
MoDDiB
Messages postés
546
Date d'inscription
mardi 26 novembre 2002
Statut
Membre
Dernière intervention
4 mai 2007
-
13 nov. 2003 à 17:31
verdy_p Messages postés 202 Date d'inscription vendredi 27 janvier 2006 Statut Membre Dernière intervention 29 janvier 2019 - 18 juin 2007 à 17:53
verdy_p Messages postés 202 Date d'inscription vendredi 27 janvier 2006 Statut Membre Dernière intervention 29 janvier 2019 - 18 juin 2007 à 17:53
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/17898-cryptographie-fractale
https://codes-sources.commentcamarche.net/source/17898-cryptographie-fractale
18 juin 2007 à 17:53
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!)
12 juin 2007 à 17:32
Tu dois penser à camoufler ton chainage par des permutations dynamiques!!!
Hint : (les permutations doivent dépendre de la clef et de la taille du fichier)
28 janv. 2006 à 17:01
Je suis plus développeur que cryptographe!
Un attaquant parvenant à faire crypter un fichier par cet algorithme arriverai à retrouver facilement la suite de nombres pseudo aléatoires et à l'utiliser pour décrypter sans clé. Ce, jusqu'au changement de clé suivant.
Si la clé (suite de nombres pseudo aléatoires) est utilisée une seule fois, une telle attaque devient impossible?
Il existe une autre version de l'algorithme fractal appelé perfract (voir http://www.javafr.com/code.aspx?ID=30540 ). La particularité de cet algorithme est d'avoir une vitesse nettement plus élevée que rijndael. Cet algorithme n'est valable que si une clé est utilisée une fois. Utilisé en combinaison avec RSA (très lent?), la transmission de gros fichier attaché à un email devient aisée. Scénario :
- Le destinataire d'un gros fichier envoie une clé de cryptage RSA (publique) à l'expéditeur.
- L'expéditeur génère une clé secrète pour perfract (ou rijndael) à l'aide de Secure Random de Java.
- Cette clé secrète est cryptée avec la clé de cryptage RSA.
- Le gros fichier est crypté avec la clé secrète.
- Le gros fichier crypté et la clé secrète cryptée sont placés dans un fichier qui sera joint à un email puis envoyé au destinataire.
- Le destinataire décrypte la clé secrète à l'aide de la clé de décryptage RSA (privée).
- Il décrypte ensuite le gros fichier avec la clé secrète.
Le programme effectuant tout cela est disponible à l'URL ci-dessus.
A propos de l'utilisation des courbes de Julia :
Pour ne pas pouvoir repérer de cycles,
- Les nombres obtenus sont tronqués afin de supprimer les octets les plus significatifs, puis recombinés.
- Les coordonnées de bases (zone) sont choisies de sorte que l'imprécision du processeur ajoute une touche aléatoire?
Voir http://www.glardsoft.com/Crypt/PrincipeCryptageFractal.htm
Je vais essayer de trouver un moment pour améliorer!
27 janv. 2006 à 21:46
il faut aussi s'assurer que la suite u_k(n) ne contient aucun cycle (faute de quoi la connaissance de quelques-un des premiers termes permet d'en connaitre une grande quantité sur un message clair suffisamment long, ou d'en déduire la valeur par analyse de fréquence), ou au moins garantisse un cycle d'ne longueur minimale extrèmement longue. Le générateur pseudo-alétoire devrait offrir cette garantie. Cependant une courbe fractale de Juliaprésente de nombreux cycles très similaires, dont on peut reconnaitre leurs caractéristique par un calcul de FFT qui déterminera les longueurs de cycles.
Cet algo n'est pas du tout sécurisé et facilement cassable.
27 janv. 2006 à 21:17
Donc si on crypte un message clair ne contenant que des zéros, on obtient directement un message "crypté" ne contenant que les termes de u_k(n). Si maintenant un nouveau message contient quelques octets différents de 0, il n'est pas difficile de voir lesquels par simple analyse statistique de la fréquence d'occurence des valeurs possibles à chaque position n, et donc de savoir quel est le terme u_k(n) réel.
Moralité:si l'entropie du message source est faible, celle du message crypté l'est tout autant, ce qui permet de déduire la suite u_k(n) sans même connaitre la clé secrète k qui a théoriquement servi à la générer!
Exemple de cryptage non sur équivalent: le cryptage par XOR avec un fichier aucontenu totalement aléatoire, mais fixe entre deux messages.
Moralité: NE PAS utiliser la simple méthode XOR pour crypter un message avec une suite aléatoire secrète, car cela révèle la clé elle-même (rappel: toute suite pseudo-aléatoire dépendant d'une clé secrète k même très longue est équivalente à la suite elle-même.
Si cette suite est constante entre deux messages, elle ne doit pas êtrerévélée dans le message crypté, ce qui n'est pas le cassile message source a une entropie faible, par exemple si on dispose de plusieurs messages cryptés avec la même suite, quelle que soit son caractère aléatoire, et même si la suite secrète a été générée avec un générateur aléatoire sûr (comme un capteur de température ou un capteur de désintégration nucléaire, un détecteur de neutrinos, un compteur de bulles gazeuses dans un liquide, un compteur d'électrons émis d'unesource chauffée accélérée dans un tube à vide, etc...)! Toute suite secrète est aussi précieuse que la clé l'ayant générée avecun algorithme de génération de suite pseudo-aléatoiresûr.
Méthode à ne pas utiliser également:lecryptage avec un simple XOR avec le texte d'un livre tenu secret. Cela souffre du même problème si le livre ne change pas et celas'aggrave avec lalonguer du message àcrypter, puisque un seul message suffisamment long permet de lire partiellement le texte clair puis de déduire le texte clair manquant par un dictionaire...
27 janv. 2006 à 20:53
Autre danger: la méthode de cryptage avec simple XOR (sans "feedback") permet de retrouver la suite par cryptanalyse simple en comparant deux messages en clair cryptés avec la même suite.
Comme cette methode génère une suite unique indépendante du message, une simple analyse de fréquence du début des messages cryptés permet de trouver très facilement les premiers termes de la suite,et donc d'utiliser ces termes pour décrypter au moins le début de n'importe quel messagecrypté avec la même suite!
Cet algorithme est donc très facilement cassable, à l'aide seulement d'un nombre suffisant (pas très élevé en fait... une cinquantaire suffirait sur des messages clairs limitésà du texte, et environ 5000 à 10000 sur un message source d'abord compressé) de messages distincts cryptés avec la même suite (c'est-à-dire la même clé).
Pour crypter de façon plus sûr un message, il utiliser un feedback du résultat du cryptage sur la suite, et s'assurer d'un nombre suffisant d'octets de feedback. Une solution: d'abord compresser le message pour en augmenter l'entropie dès le début, ajouter des octets aléatoires sans signification au début du message en clair.
Supposons que l'algo ci-dessus produit la suite déterministe u_k(n) où k est la clé secrèteet n le numéro d'ordre de la suite, alors on peutcrypter le message en faisant ceci:
* ajouter au début du message M(n) clair par exemple 1Ko de données aléatoires (ces octets seront supprimés après décryptage) provenant par exemple de sources aléatoires fiables (compteurs de performance mémoire dans un système multi-utilisateurs, capteurs de température du processeur, derniers mouvements souris, performance d'accès disque aléatoire, source unique sure de UUID du système si une telle source existe). On obtient le message clair M'(n), où M'(n+1024)=M(n) et M(0) à M(1023) sont un long vecteur d'initialisation UNIQUE pour chaque message à crypter.
* calculer M''(0)u_k(0) XOR M'(0), et M''(n+1) u_k(n+1) XOR M'(n+1) XOR M''(n).
* M'' est le message crypté (plus long que le message M de 1024 octets)
* on peut augmenter en fait le nombre d'octets de feedback en choisissant un nombre prédéterminé suffisant dans les derniers 1024 octets cryptés, au lieu d'unprendre un seul ici.
Pour décrypter M'', il fautconnaitre la suite u_k(n) donc la clé k
* on renverse le feedback de M' dans M'' à chaque étape.
* on supprime les 1024 premiers octets de M'(n) pour obtenir M(n).
Cependant le feedback de type XOR est encore déterministe puisque sa valeur provient du message crypté (donc connu). Pour lerenforcercontre la cryptanalyse différencielle, il faut utiliser une fonction de combinaison plus sure que le simple XOR.
Dans le chiffrage DES avec CBC, le cryptage se fait par bloc de 64 octets à la fois, et le feedback porte sur les 64 octets obtenus après cryptage, mais utilise une fonction combinatoire bien plus sûre que le simple XOR (qui n'est qu'une fonction linéaire).
On peut aussi renforcer un peu le feedback contre la cryptanalyse linéaire avec une récursion multiple.
L'effet du feedback est que la fonction de cryptage reste inversible, mais que son inverse n'est pas la simple fonction de cryptage elle-même.
24 févr. 2005 à 12:58
17 nov. 2003 à 07:51
Ref :
http://www-rocq.inria.fr/codes/Anne.Canteaut/des.html
http://www.mines.u-nancy.fr/~tisseran/I33_Reseaux/cryptage/cryptana.htm
Dans ce logiciel à clé secrète, la modification de 1 caractère sur les 80 caractères acceptables pour un mot de passe produit une suite de nombres aléatoires très différentes.
(suivez avec un debbuger le code concernant le test d'un mot de passe...)
14 nov. 2003 à 15:12
Nous pouvons uiliser la cryptanalyse du chiffrement par subsistution,la criptanalyse du chiffrement affine,la criptanalyse du chiffrement de Vigenère ou une attaque à teste clair connu du chiffrment Hill.
14 nov. 2003 à 14:33
14 nov. 2003 à 12:46
Pour pouvoir cypter il faut utiliser le Standard de Chiffrement de Données ou DES.Une des attaques bien connues de DES et la méthode de cryptanalyse différentielle,inventée par Biham et Shamir.
Par exemple,DES à 8 tour peut etre cassé en quelques minutes seulement sur un mico-ordinateur!!! il exite aussi le chiffrement RSA et la factorisation qui fait intervenir l'algorithme d'Euclide.Il existe un sytème de partage de secret qui est en fin de compte n'est que le système à seuil de Shamir.
14 nov. 2003 à 12:33
14 nov. 2003 à 12:09
14 nov. 2003 à 11:07
14 nov. 2003 à 07:27
13 nov. 2003 à 18:30
13 nov. 2003 à 18:22
13 nov. 2003 à 17:31