Cryptographie fractale

Soyez le premier à donner votre avis sur cette source.

Vue 9 259 fois - Téléchargée 608 fois

Description

Méthode de cryptage utilisée:
Une suite de masques est créée par un générateur de nombres aléatoires basés sur les mathématiques fractales. Le mot de passe coïncide avec le nombre source du générateur de nombre aléatoire. Un mot de passe peut compter jusqu’à 80 caractères pertinents pour le cryptage (clé de 640 bits ? !). Au besoin, je peux encore augmenter le nombre de bits de la clé… Les octets à crypter/décrypter sont ensuite combinés au masques par un OU exclusif (XOR).
Voir : http://www.glardsoft.com

Codes Sources

A voir également

Ajouter un commentaire

Commentaires

verdy_p
Messages postés
203
Date d'inscription
vendredi 27 janvier 2006
Statut
Membre
Dernière intervention
29 janvier 2019

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!)
SProgrammable
Messages postés
2
Date d'inscription
lundi 27 décembre 2004
Statut
Membre
Dernière intervention
28 décembre 2004

votre methode paret interessante basée sur des opérations bien simples ce qui augmente sa performance mais en effet il vous manque l'usage des permutations!! Car en effet un chainage classique est rapidement cassable surtout que cette methode contient un nombre fini de valeurs qui ne sont pas vraiment aléatoire.

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)
Vallorbain
Messages postés
29
Date d'inscription
vendredi 18 juillet 2003
Statut
Membre
Dernière intervention
1 février 2019

Grand merci pour les précieuses remarques?
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!
verdy_p
Messages postés
203
Date d'inscription
vendredi 27 janvier 2006
Statut
Membre
Dernière intervention
29 janvier 2019

Dernier problème non traité ici:
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.
verdy_p
Messages postés
203
Date d'inscription
vendredi 27 janvier 2006
Statut
Membre
Dernière intervention
29 janvier 2019

Pour s'en convaincre, il suffit de voir que la suite u_k(n) ne dépend que de la clé k, et que même si on ne connait pas k, connaitre suffisamment de terme de u_k(n) suffit pour décrypter n'importe quel message pastroplong utilisant cette même suite.

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...

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.