Discussion :

[SkyBack]

Pas si sûr, c'est juste pour montrer que si ton random() renvoie plusieurs fois la même valeure, ce qui finira bien par arriver, on est dans le même cas. C'est pour cette raison, que les algorithmes modernes utilisent des S-Box choisie avec précaution et non du random().

Tu pourrais développer cette idée stp ? Parce que je ne vois pas en quoi ca peut poser problème ... Certes, si je demande une série de chiffre entre 0 et 9, il est possible que le générateur sorte 2 fois le même d'affilée mais c'est très bien comme ca, c'est d'autant plus proche du vrai aléatoire (le même numéro peut sortir 2 fois à la roulette)
Ensuite les valeurs que je demande de sortir sont utilisée de différentes manière. Pour avoir une clé, je demande d'abord un random (0,3) pour le type de permutation, un random (0,3) pour l'axe et un random(1,3) pour le nombre de crans ...
Comment le fait de sortir 2 fois la même valeur pourrait permettre de connaitre la clé ?

Quant à l'entropie de Shannon, je me documentes à ce sujet, ca a l'air intéressant, je vais soumettre ma solution à ce test Si tu as d'autres idées pour vérifier la qualité d'un algo de chiffrement, je suis preneur !

[Jimmy_]

Pas facile a comprendre, pourquoi ton random() affaibit la sécurité

Je vais essayé d'expliquer autrement :

En fait dans ton système, ta clé secrête reélle est le seed, car la clé de décryptage en découle, c'est une composante, puisque l'attaquant a accès au code et sais comment elle est construite. Si on lance l'algo deux fois avec le même seed, on obtient bien la même clé de décryptage on est bien d'accord ? Ce seed est déterminé, par une composante temporelle ou un numéro de process, c'est bien ça ?

Donc l'attaquant va déjà jetter cette partie qui n'est qu'un calcul de clé. Et implémenter pour l'attaque une version où il peut choisir une clé à sa guise et construire ses statistiques.

J'ai fait quelques tests avec ta page. Le problème principal a mon avis est le manque de diffusion, le fameux effet avalanche. Car avec la même clé en modifiant légèrement le message crypté, on change aussi que très légèrement le message en clair. C'est une très grosse faiblesse, car les statistiques sur les entrées/sorties a construire porteront sur assez peu d'octet. De plus j'ai l'impression qu'il y a des clés impossibles, ce qui elimine enormement de possibilité et qui affaiblit donc l'ensemble en fait.
Ton système semble très vulnérable sur ce point.

Un attaquant qui a construit ses statistiques et qui intercepte seulement ton message crypté, va l'insérer dans ses équations et en déduire ta clé qui a servit pour ton message en clair. Il pourra même accelérer la recherche s'il y a des mots probables dans le texte en clair.

Par contre si dans ton algorithme la diffusion est importante, cette méthode statistiques va être trop lourde, puisque il devra déterminer tous les octets impactés par une modification unitaire et construire un système de très grande taille. C'est l'un des buts recherchés par AES qui oblige l'attaquant a contruire un système d'équation irréalisable à l'echelle humaine.

C'est un point fondamental, démontré par de nombreuses recherches. L'aspect chaotique de la sortie est primordiale.

[SkyBack]

En fait dans ton système, ta clé secrête reélle est le seed, car la clé de décryptage en découle, c'est une composante, puisque l'attaquant a accès au code et sais comment elle est construite. Si on lance l'algo deux fois avec le même seed, on obtient bien la même clé de décryptage on est bien d'accord ? Ce seed est déterminé, par une composante temporelle ou un numéro de process, c'est bien ça ?

Tout juste sauf un petit détail : j'utilise comme seed, le résultat du précédent calcul stocké dans un fichier.

Donc l'attaquant va déjà jetter cette partie qui n'est qu'un calcul de clé. Et implémenter pour l'attaque une version où il peut choisir une clé à sa guise et construire ses statistiques.

Le code que je fournis permet déjà de créer ton objet Chiffrement et lui imposer une clé de ton choix (j'ai mis ca en place pour voir l'effet avalanche)

J'ai fait quelques tests avec ta page. Le problème principal a mon avis est le manque de diffusion, le fameux effet avalanche. Car avec la même clé en modifiant légèrement le message crypté, on change aussi que très légèrement le message en clair. C'est une très grosse faiblesse, car les statistiques sur les entrées/sorties a construire porteront sur assez peu d'octet.

Je vais aller plus loin et dire qu'en cas d'utilisation de la même clé, l'effet avalanche est de 0%. Et je suppose qu'il serait assez facile de déduire les permutations effectuées par les 30 clés valides. Mais à quoi bon ? Car avec un message chiffré avec une clé de taille 12 (12 permutations de suite choisies parmi les 30 possibles) il faudrait se rabattre sur le brut-force pour utiliser ces déductions.

De plus j'ai l'impression qu'il y a des clés impossibles, ce qui elimine enormement de possibilité et qui affaiblit donc l'ensemble en fait.

Tout a fait. C'est d'ailleurs logique puisque je code une permutation sur un octet. Un octet peut prendre 256 valeurs et je n'ai que 30 clés de base distinctes. Il y a donc effectivement de nombreuses clés impossibles (la fonction qui reçoit une clé imposée par l'utilisateur teste cette dernière et la refuse si besoin)

Un attaquant qui a construit ses statistiques et qui intercepte seulement ton message crypté, va l'insérer dans ses équations et en déduire ta clé qui a servit pour ton message en clair.

Ben ... c'est sur ce point que j'aimerais des infos parce que -ne le prend pas personnellement- mais j'en doute quand même. N'étant pas cryptanalyste, je ne perçois pas de moyen technique de faire ca.

Par contre si dans ton algorithme la diffusion est importante, cette méthode statistiques va être trop lourde, puisque il devra déterminer tous les octets impactés par une modification unitaire

Je ne suis pas sur d'avoir compris, mais si tu regarde la doc (2e page), je montre comment une seule modification d'une seule cellule de l'hypercube modifie 100% des octets contenus dans l'hypercube.


De toute façon, cette histoire d'hypercube n'était que pour jouer avec la 4e dimension. Là, tout de suite, la solution de chiffrement que je recherche serait basée sur l'aléatoire. Et il me semble avoir trouvé ce que je cherchait : http://fr.wikipedia.org/wiki/Masque_jetable

Le masque jetable [...] perfectionné par Joseph O. Mauborgne, qui rajouta la notion de clé aléatoire [...] est le seul qui soit théoriquement impossible à casser.

C'est exactement ce que je voulait savoir \o/

Condition d'impossibilité mathématique de casser le code :
- clé aussi longue que le message
- clé unique (ne jamais utiliser 2 fois la même clé)
- clé vraiment aléatoire

problèmes de mise en œuvre :
- l'émetteur et le récepteur doivent s'être mis d'accord sur la clé avant chaque envoi
- stockage et traitement des anciennes clés
- "vrai aléatoire" + "informatique" = problème (peut-être l'info quantique le permettra)

Mon objet hypercube fonctionnant de manière satisfaisante à mes yeux, je vais le laisser tranquille un moment pour me concentrer sur ma fonction my_random() et la façon de s'en servir pour générer des cryptogrammes.

[Jimmy_]

Citation:
Un attaquant qui a construit ses statistiques et qui intercepte seulement ton message crypté, va l'insérer dans ses équations et en déduire ta clé qui a servit pour ton message en clair.
Ben ... c'est sur ce point que j'aimerais des infos parce que -ne le prend pas personnellement- mais j'en doute quand même. N'étant pas cryptanalyste, je ne perçois pas de moyen technique de faire ca.

C'est juste une question de temps, mais vu qu'il n'y a pas de diffusion entre les blocs, ni plusieurs tours. Le problème se réduit à attaquer un seul bloc. Et avec seulement 30 clés possible, ca ira très vite. Bon au moins tu auras suivit mes explications sur l'intérêt de la diffusion.

Bon courage pour la suite et ton générateur pseudo-aléatoire.

[SkyBack]

D'acc.
Enfin, si la seule solution restante est le brut-force sur un bloc, je suis content. Le reste n'est qu'une question de taille de bloc/possibilités de clé. Du paramétrage un peu chiant loin de l'algo.

Merci pour les pistes que tu m'as donné j'ai appris pas mal de trucs.

Pour la génération de vrai aléatoire sur un PC, c'est possible en fait (webcam sur une lava lamp, utilisation de phénomènes quantique comme le passage d'un photon, attribution d'adresse mémoire couplée avec une donnée temporelle, etc)

Je vais bien m'éclater sur ce nouveau projet