NOUVEL ALGORITHME D'ENCRYPTION-DÉSENCRYPTION DYNAMIQUE (INFAILLIBLE)
vletktol
Messages postés
12
Date d'inscription
mercredi 19 février 2003
Statut
Membre
Dernière intervention
26 novembre 2010
-
14 nov. 2010 à 16:18
lilington Messages postés 158 Date d'inscription samedi 31 janvier 2004 Statut Membre Dernière intervention 12 mars 2009 - 7 déc. 2010 à 08:15
lilington Messages postés 158 Date d'inscription samedi 31 janvier 2004 Statut Membre Dernière intervention 12 mars 2009 - 7 déc. 2010 à 08:15
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/52476-nouvel-algorithme-d-encryption-desencryption-dynamique-infaillible
https://codes-sources.commentcamarche.net/source/52476-nouvel-algorithme-d-encryption-desencryption-dynamique-infaillible
7 déc. 2010 à 08:15
je programme generalement en C et rarement en C++ ca fait si vous verifier des annees que j'ai pas poste ni une source ni un commentaire(meme si je lis souvent des sources). j'ai lu cette source et TOUS les commentaires.
Je n'y connais rien en chiffrement/cryptage (meme en vocabulaire :)) mais faut reconnaitre que l'auteur est sur la defensive et pas pres a ecouter les critiques notemment celle de LeFauve42 qui a l'aire de s'y connaitre.
celle du debut donnaient l'impression de repondre a l'arogance de l'auteur qui au vu de ce que j'ai lu et au passage j'ai secret and lies que j'ai immediatement lu, l'auteur de notre code s'entete et s'aveugle.
Oui les commentaires sont agressif, sauf pour LeFauve42 sont assez dure a prendre quand on s'est mit soit meme tres haut. mais oui ils disent la verite. et meme moi qui m'y connait pas trop j'ai compris la difference entre ce que tu dis et ce qu'on te demande.
en un mot acceptes que tu as pas tout a fait raison sur ce coup la et ce que j'aurai fait a ta place c'est lire plus sur le sujet poster un code et demander l'avis des autres de maniere un peu plus humble et crois moi tu apprendras plus.
2 déc. 2010 à 11:17
Oui, c'est ca dont je parlais dans mon premier post :
> Une petite remarque: si en plus tu veux crypter des fichiers (et non de l'information brute), il y a des mesures supplementaires a prendre, comme ne surtout pas crypter l'entete du fichier (celui-ci est facilement deductible, ce qui va compromettre une bonne partie de ta cle).
La procedure est :
-1) Avec une partie du message "en clair" (le header) on peut determiner une partie de la cle.
-2) Cette partie de la cle permet de decoder une partie du message.
-3) A partir de morceaux en clair du message, on peut deduire certaines parties du texte (ex: si tu as un bout de phrase comme "Cher Mons@#$$@#$#%" tu peux facilement deduire que les 4 premiers caracteres manquants sont "ieur" (suivi probablement d'une virgule ou d'un espace)).
-4) Avec cette nouvelle partie du message "clair", on peut completer un bout de la cle et revenir au "-2)" jusqu'a obtention du message complet.
1 déc. 2010 à 15:51
30 nov. 2010 à 19:03
29 nov. 2010 à 17:08
On peut critiquer surement bcp de choses sur cette source, mais pas le choix du chiffrement symétrique :)
29 nov. 2010 à 14:16
Si on crypte un fichier, c'est parce qu'il risque d'être intercepté d'une manière ou d'une autre. Or, ta clef est un fichier, et donc il est tout aussi probable qu'elle se fasse récupérer que ton fichier.
Si tu trouves un moyen sûr de transférer une clef, sans qu'elle se fasse intercepter / déchiffrer, alors tu auras révolutionné la sécurité informatique. En attendant, tout système est à considérer comme faillible.
26 nov. 2010 à 07:15
26 nov. 2010 à 02:17
De là vient le mot infaillible,
Une chose est sûre à 100%. One Time Pad c'Est la chose la plus puissante qui existe sur terre.
Essayons de créer quelque chose qui s'en rapproche le plus.
La perfection n'est pas sur cette terre. Mais nous pouvons s'en rapprocher.
25 nov. 2010 à 11:42
N'oubliez pas, Jornov, que l'auteur lui-même conclut son post par "j'attends vos commentaires", alors qu'il est très peu enclin à les entendre...
Concernant la puissance nécessaire pour craquer en brute force des clés, il y a un justement un nouvel article très intéressant concernant cela : l'utilisation du cloud computing à ce genre de fins. Ou comment avoir, grâce au cloud, la puissance de 200 ordinateurs dans ton petit dual core tout ce qu'il y a de plus classique...
25 nov. 2010 à 11:29
25 nov. 2010 à 11:13
Voilà, c'est aussi de la même façon que des génies sont mort avec leurs trouvailles dans l'ombre. Je dis cela par rapport au principe.
Ceux qui ont un Nom et ceux qui les défendent se mettront toujours en ordre de bataille contre un petit David qui croit que sa fronde est efficace au grand rire moqueur du Goliath.
Alors rassurez-vous, ne vous découragez pas car peut être qu'un jour une personne bien optimisera votre travail pour le rendre vraiment infaillible.
Ce qui fait avancer les choses c'est la complémentarité des collaborateurs pour obtenir un résultat probant et non pas la rivalité de parti orgueilleuse et jalouse.
Bon courage!
24 nov. 2010 à 11:50
@X_CLI: Merci, mais tes commentaires etaient tres pertinents aussi :o)
@VLETKTOL:
> Donc le seul moyen de déchiffrer est d'essayer 2^2048 possibilités (2048 bits).
> DE LÀ VIENT LE MOT INFAILLIBLE (ONE TIME PAD)
Hum.. comment dire ca de maniere un peu diplomatique... Non !
La taille de la clé n'a rien a voir avec l'infaillibilite.
Attaquer en force brute une cle de 2048 bits, c'est pas impossible, c'est juste tres long.
Le one-time-pad, par contre, c'est impossible a dechiffrer.
2048 bits peuvent te parraitre incassable parce qu'avec les CPUs actuels, il faudrait 10, 100 ou meme 1000 ans pour tester toutes les possibilites, mais un jour ca se cassera en moins d'une minute avec un smartphone d'entree de gamme :o)
Le one-time-pad par contre, meme si tu avais un ordinateur "magique" capable de tester instantanement toutes les combinaisons, ca reste incassable. Je veux dire par la que si tu attaques en force brute, tu vas bien trouver le message envoye, mais aussi tous les autres messages possibles de la meme taille, et tu n'auras aucun moyen de savoir lequel etait le bon.
> ET Vu que je ne chiffre pas par bloc de 2048 bits; Nous ne pouvons pas COMPARER chaque bloc entre eux.
Dans le cas du carre de Vigenère (c'est qu'est le one-time-pad, si on lui enleve sa cle non reutilisable), la comparaison des blocks entre eux est surtout utilisee pour trouver la taille de la cle.
Dans ton algo, on la connait :o)
Je vais essayer de reformuler ce que j'ai dit :
Oui, les methodes classiques d'attaque d'un chiffrement a la Vigenère ne vont pas fonctionner "out of the box" sur les messages chiffres avec ton programme, mais une simple adaptation prenant en compte tes modifications rend ton chiffrement aussi vulnerable que si ta cle ne faisait que 2048 bits.
Alors oui, 2048 bits c'est long a casser, mais pas impossible.
Sinon pour parler du code, voici quelques autres remarques :
- Il y a des moyens plus efficaces de transformer des octets en bits et vice versa, mais surtout : Est-ce que tu as vraiment besoin de transformer tes octets en bits pour realiser ton chiffrement ?
- Essaie d'etre consistant dans tes nommages de fonction ou variables. Certaines sont en majuscules, ce qui n'aide pas vraiment a la relecture (les vieux de la vielle vont essayer de trouver ou tu as planque tes "#define" :o) ).
- Tu n'as sans doute pas besoin d'utiliser un thread pour afficher la progression de ton chiffrement.
- Si tu veux vraiment faire du multithread, tu pourrais par exemple faire faire tes tranches de 2048 bits a des threads differents afin de paralleliser.
- Plutot que de faire un system("cls") pour effacer l'ecran, tu devrais regarder vers les sequences ANSI. Ce serait bien plus rapide (surtout sur un monocore).
- D'ailleur, un simple cout << '\r' devrait remettre le curseur en debut de ligne, donc tu pourrais juste afficher ton avencement sans avoir a effacer l'ecran.
23 nov. 2010 à 21:01
23 nov. 2010 à 18:46
23 nov. 2010 à 18:32
Alors nous pouvons dire que tout le fichier repose sur 2048 bits.
Nous ne pouvons pas établir de lien ou de relation sur les données du fichier chiffré.
Donc le seul moyen de déchiffrer est d'essayer 2^2048 possibilités (2048 bits).
DE LÀ VIENT LE MOT INFAILLIBLE (ONE TIME PAD)
-Simulation de ONE TIME PAD sans avoir besoin de la clef aussi grosse que le fichier pour le déchiffrer. JE ne chiffre pas par bloc de fichier. Donc à chaque 2048 bits; ce ne sera pas la même clef temporaire de chiffrement. (comme TKIP)
-Je le répète: Vu que je n'établie AUCUNE RELATION entre la clef et le fichier à chiffrer; alors nous ne pouvons pas établir de LIEN par attaque par statistique.
ET Vu que je ne chiffre pas par bloc de 2048 bits; Nous ne pouvons pas COMPARER chaque bloc entre eux.
MERCI ET BONNE JOURNÉE
23 nov. 2010 à 18:20
SAUF QUE CETTE CLEF ELLE-MÊME A UNE RELATION AVEC ELLE-MÊME ET JE N'UTILISE PAS LES OCTETS DU FICHIER À CHIFFRER POUR MODIFIER CETTE CLEF. CONTRAIREMENT AUX AUTRES ALGORITHMES DE CHIFFREMENT.
LA CLEF SE MODIFIE PAR ELLE-MÊME SELON 3 VARIABLES.
LE COMPTEUR, LA LONGUEUR DU COMPTEUR, LES FONCTIONS, ETC....
23 nov. 2010 à 17:30
23 nov. 2010 à 13:47
En fait, si par "infaillible" tu entends qu'il n'est pas possible de dechiffrer le message sans connaitre la cle de chiffrement, il se trouve que le "one time pad" ou "masque jetable" l'est :o).
Ce chiffrement a cependant d'autres inconvenients, comme le besoin de partager une cle aussi longue que le message.
J'ajouterais cependant une remarque a ce que j'ai lu dans certains commentaires du style "Si tu peux transferer la cle de maniere sure, tu peux transferer directement le message (qui fait la meme taille)".
Ce n'est pas tout a fait vrai :
- D'abord, on n'est pas oblige de transferer la cle. On peut tres bien imaginer que les deux parties desirant correspondre de maniere securisee se rencontrent en personne et s'echangent une longue cle securisee (identique). Par exemple, un DVD grave avec des octets aleatoires. Il leur suffit ensuite de s'envoyer des messages cryptes en one-time-pad avec cette cle, plus l'offset de debut de la cle (pour ne jamais reutiliser plusieurs fois la meme partie de la cle qui deviendrait alors vulnerable aux attaques statistiques). Durant la seconde guerre mondiale, les espions utilisaient des livres. Par exemple l'espion A utilisait "Les 3 mousquetaires", et quand il donnait comme offset 5623 le recepteur savait qu'il fallait utiliser comme cle les lettres du livre a partir du 23eme mot de la page 56 (de la meme edition bien sur :o) )
- On peut aussi transferer la cle d'abord, et n'envoyer le message qu'une fois qu'on n'est sur que la cle n'a pas ete interceptee (ce n'est pas toujours possible, mais sur un reseau quantique par exemple, ca l'est).
- Une autre option est d'utiliser plusieurs canaux differents pour la cle et le message (un peu comme les premiers sites de payement internet ou on pouvait envoyer le debut de son numero de CB par internet et la fin par telephone). Par exemple, si vous ne voulez pas que votre operateur mail lise vos message, vous pourriez utiliser 2 adresses (chez des operateurs differents), et envoyer la cle sur une, et le message sur l'autre (un peu comme Nike qui fait fabrique ses chaussures gauches et droites dans des pays differents pour eviter que le personnel local ne puisse sortir des paires en douce... mais je m'eloigne du sujet :o) ).
Bref, pour simplifier, ce programme propose une methode pour "allonger" une cle de 2048 bits afin d'utiliser le one-time-pad. C'est cette methode d'allongement qui compromet l'infaillibilite du one-time-pad, qui a part ca est un bon algo qui a fait ses preuves dans des cas reels.
23 nov. 2010 à 12:09
C'est le même principe qui fait qu'un logiciel libre tendra à être plus sécurisé qu'un logiciel privateur.
Ce principe, en crypto, s'appelle le Principe de Kerckhoffs.
http://fr.wikipedia.org/wiki/Principe_de_Kerckhoffs
23 nov. 2010 à 11:55
Je ne comprends pas grand chose à la cryptographie mais cela ne m'intéresse pas moins pour autant.
Mais j'aimerais savoir: Est il possible de déchiffrer un fichier si tout le programme de chifrement
est mise en clair sur le Net ?
C'est peut être une question bête !!!
Lzappeur...
Merci à tous pour ces commentaires éclairés.
23 nov. 2010 à 10:54
22 nov. 2010 à 22:37
Encryption est le mot englais, et tout bon informaticien programme en anglais, même le meilleur cryptanalyste(mais si). (même si ce site est français)
Désolé d'avoir perturbé cette petite "dispute", je m'en vais. Salut
22 nov. 2010 à 11:36
Il s'agit d'une reprise du "one time pad" sauf que ca n'utilise qu'une cle de 2048 bits... ce qui enleve donc l'unique interet du one time pad (ou masque jetable).
En effet, meme si tu generes une cle plus longue en utilisant un algo (aussi tordu soit-il), vu que l'algo est connu, c'est comme si tu n'avais qu'une cle de 2048 bits.
Et donc, les classiques attaques a base de statistiques vont fonctionner.
Une petite remarque: si en plus tu veux crypter des fichiers (et non de l'information brute), il y a des mesures supplementaires a prendre, comme ne surtout pas crypter l'entete du fichier (celui-ci est facilement deductible, ce qui va compromettre une bonne partie de ta cle).
Si "Applied Cryptography" est bien le livre dont je me souviens, il commencait par une phrase du genre "Il existe 2 sortes de cryptographie : Celle destinee a empecher votre petite soeur d'acceder a vos donnees et celle destinee a empecher les dirigeants des grandes puissances de ce monde a acceder a vos donnees. Ce livre parle de la seconde".
Ce code source appartient par contre a la premiere :o).
VLETKTOL: Plutot que de raler contre ces commentaires tres pertinents, tu devrais lire un de ces bouquins (ou selon ton niveau de math, un de ces bouquins expliquant la crypto qu'on trouve chez nature et decouvertes (serieusement, c'est une bonne base au moins pour comprendre les trucs a ne pas faire :o) )).
Et puis le but de ce genre de site est de poster des codes utiles aux gens, alors plutot que de mettre des remarques genre "Veuillez prendre note que certaines variables et commentaires de ce code source sont incohérents.... J'ai copié du code de mes anciens code source pour sauver du temps :)", prend une dizaine de minutes pour mettre des commentaires pertinents. C'est plus correct pour les gens qui vont donner leur temps pour lire ton code, et en plus ca te sera utile quand tu voudras modifier ton code.
22 nov. 2010 à 10:01
1/ "J'ai testé avec un fichier de 3 mégas". Crois-tu qu'un test suffise ? L'exception qui fait la règle ? T'es-tu juste penché sur la possibilité qu'une des combinaisons puisse résulter en un chiffrement indéchiffrable ensuite (la base de l'analyse de tout chiffrement réversible).
2/ X_CLI essaye de t'expliquer un principe de base : puisque ton masque est jetable, il est appelé à être renouvelé / différent à chaque chiffrement. Et donc : ce masque va lui aussi devoir être transporté avec le fichier crypté, sous peine de ne pouvoir le déchiffrer ensuite. Donc, la sécurité "relative" de ton chiffrement dépend uniquement de la sécurité avec laquelle tu vas transporter ton masque; si tu as une sécurité INFAILLIBLE pour transporter ton masque, alors ne t'emmerde pas : transporte directement ton fichier en clair via ce canal, puisqu'il est INFAILLIBLE.
Je comprends que tu sois enthousiaste, mais un bon procédé de chiffrement, validé, réputé, ne peut être approché "au-pti-bonheur-la-chance", et testé avec un aussi petit panel d'échantillons.
15 nov. 2010 à 18:26
JE vous conseille donc d'aller voir la pièce jointe. Vous y trouverai un document WORD qui vous explique la procédure
en détail. (un genre d'algorithme très rudimentaire :P)
15 nov. 2010 à 15:41
il est vrai que ce que nous avons la n est pas un algorithme mais un programme.
Un algo(algorithme) est une ecriture litterale d'un programme ce qui lui permet d'etre traduis d'en n importe quel langage de programmation
BON COURAGE
et merci d'ecrire l algo pour mieux le comprendre je ne fais pas de C et j aimerai le faire en java.
15 nov. 2010 à 13:58
PS: crypter => chiffrer
15 nov. 2010 à 13:20
Mon code source utilise un masque jetable et possède la qualité d'avoir un vecteur d'initilisation de 2048 bits pour déchiffer tout le fichier.
pas besoin d'une clef de la longueur du fichier.....
De plus mon algorithme n'est pas conçu actuellement pour fonctionner en mode client-serveur sur internet..... Il est conçu pour crypter des FICHIERS....
15 nov. 2010 à 13:14
Pourtant, dans le monde de la cryptographie, leur usage est quasi inexistant : pourquoi ?
Parce qu'il est aussi couteux de transporter de manière sécuriser le masque que de transporter le message lui même. Si le masque est intercepté, le message a beau être chiffré, il sera déchiffré, et si le masque n'est pas intercepté, alors nous aurions aussi bien fait d'envoyer par cette méthode directement le message en clair.
C'est justement tout l'intêret des algo comme DES et consort : la taille de la clé n'a pas besoin d'être bcp plus longue de 128 bits. C'est d'ailleurs sur des clé 128 bits, (parfois 256 bits) que reposent toutes les transactions bancaires actuelles sur internet, et pas sur des one time pad.
15 nov. 2010 à 12:54
"Monsieur j'ai écrit 2 livres donc j'ai raison et écoute moi.... AHAHAHAH"
15 nov. 2010 à 12:49
Il y aura sous doute mieux que AES et DES (relire le post de X_CLI), mais ça ne sera sûrement pas ta source.
Rien que dans ta source, il y a déjà des lourdeurs de code:
- "return" en fin de fonction inutile lorsqu'il y a un type void en sortie
- using namespace std, à proscrire.
- Instanciation d'objet inutile (pas besoin de new-delete dans le main, juste l'objet en local)
- Code dans le .h
- Utilisation de system
Joins à ça des termes mal employé, la crédibilité est au plus bas.
15 nov. 2010 à 12:48
L'algorithme théoriquement parfait.
1 chance sur 256 à chaque octet de trouver la bonne clef.
Plus le fichier est grand; plus les chances sont minces à le décrypter.
J'aimerais bien que vous lisiez le tutoriel en format .DOC que j'ai mis dans le fichier zip avec le code source.
15 nov. 2010 à 12:45
Vous parlez d'ouverture d'esprit ? Prenez le recul nécessaire pour juger votre travail en lisant les deux oeuvres que j'ai recommandé, et vous comprendrez de quoi il retourne.
15 nov. 2010 à 12:38
ESSAYEZ et CRITIQUEZ après....
15 nov. 2010 à 12:30
@vletktol : Si vous lisez l'anglais, je vous recommande deux livres qui vous permettront d'avoir du recul sur votre code ; ces deux livres sont de Bruce Schneier, qui fait autorité dans le domaine : "Applied Cryptography" et "Secrets and Lies".
15 nov. 2010 à 11:23
J'ajouterais juste: En quoi est-ce un code .Net ?
15 nov. 2010 à 10:24
Je n'ai pas étudié le code source, mais rien que le titre me fait tiquer :
NOUVEL ALGORITHME D'ENCRYPTION-DÉSENCRYPTION DYNAMIQUE (INFAILLIBLE)
Nouvel : un algorithme a besoin d'être prouvé mathématiquement comme étant un problème difficile à résoudre. De plus, AES peine encore à s'imposer face à DES, alors il est assez improbable qu'un nouvel algorithme puisse être conseillé d'être utilisé aujourd'hui.
Encryption-Désencryption : cela dénote un manque de culture générale dans le domaine de la cryptographie, puisque les termes adéquats en francais sont chiffrement et déchiffrement. Je ne dis pas que vous n'êtes pas expert dans le domaine, ca je n'en sais rien, mais que l'usage des mots standards me met la puce à l'oreille.
Infaillible : un algorithme de chiffrement peut être prouvé mathématiquement comme difficile à résoudre, pour le moment. Ca ne signifie pas qu'il ne le sera pas un jour. Ce qui est réputé difficile aujourd'hui ne le sera plus dans 10 ans. Infaillible dénote une absence de compréhension totale du fonctionnement de la cryptographie. De plus, même si un algo est mathématiquement difficile à résoudre, cela ne signifie en rien que son implémentation ne soit pas faillible, et c'est pourtant très souvent le cas (cf. openssl et debian par exemple).
Pour finir, l'utilisation de rand comme source de bits aléatoires me semble bien insuffisant, car l'entropie est trop faible. Je vous conseille de regarder autour des algorithmes de génération de bits aléatoires qui sont bien plus efficaces.
14 nov. 2010 à 16:18
-Normalement en compilant la source; il faut avoir un fichier "test.mp3" dans le meme dossier que l'exécutable. Le logiciel va l'encrypter et créer 3 fichiers.....
crypted.kbm --> Fichier encrypté (même taille que le fichier non encrypté)
masque.kbm --> Fichier qui contient le masque jetable.... Il est de la taille du fichier encrypté... Ce n'est pas utile d'avoir une clef aussi longue que le fichier lui-même. Mais il est possibe de décrypter le fichier avec celui-ci aussi. Il est plus avantageux d'utiliser "kabz.kbk" pour décrypter le fichier. "MASQUE.KBM" est inutile et a été généré seulement pour démonstration et tests....
kabz.kbk --> Fichier qui contient la bibliothèque, le filtre binaire et le séquenceur.... (Vecteur d'initialisation interrelié en 3 parties)
decrypted.mp3 --> Fichier décrypté à l'aide de "kabz.kbk"
J'Attends vos commentaires :P