Discussion :

[guill663]

La séquence de sortie est la même (en nombre d'octets) que la séquence d'entrée, c'est une faute, selon moi.

Ce n'est pas une faute car la seule information qu'une personne pourrait avoir de cette "FAUTE" c'est la longueur du fichier final. Qui est le double du fichier .POS ou .DON.

Pardon, mal lu les exemples ^^ par contre, je peux pas tester, pas sous windows, et apprement, c'est du VB ou VC++ ? Euh, oui, au fait, ne te prend pas trop la tête quand même, ton système n'est sûrement pas révolutionnaire, faudrait pas te faire miroiter des trucs non plus .
De toutes façons, l'avenir n'est plus vraiment aux méthode de cryptage de fichiers (sous windows, tu peux pas développer dans un langage qui fasse que c'est portable ?), mais aux techniques de compression/cryptage et ce, sur des données qui sont "transportées" (hertzien, 802.1x, etc.).

Je ne m'enfle pas trop la tête car j'ai fait des calculs de probabilité par rapport à ma méthode.

Une personne a 1 chance sur 16 exposant [Longueur du fichier] de trouver le bon fichier final si elle possède seulement 1 fichier .POS ou .DON. C'EST RÉEL JE L'AI DÉMONTRÉ.

Pour ce qui est de la portabilité du code, il est en VC++. Donc il serait TRÈS FACILE de porter le code en LINUX ou tout autre OS...
Vu que je suis un PRO-MICROSOFT.... Jlé codé en VC++ LOL

[guill663]

Si 9<=>B (par rapport au premier exemple), et 8<=>C alors 5<=>F... ce qui correspond exactement au troisième exemple...

B n'égale pas toujours 0x9
C n'égale pas toujours 0x8
F n'égale pas toujours 0x5

Désolé !!!

[Jedai]

Néanmoins cela ne constitue en rien une méthode cryptographique, sinon la méthode suivante l'est également, et elle est infaillible : je stocke le premier octet d'un fichier sur mon ordinateur, et la suite ailleurs, tu es bien d'accord que je ne peux pas recréer le fichier original à partir des informations sur mon ordinateur ? Et bien c'est exactement ce que tu fais !

Ce n'est pas exactement ce que je fais. Je ne stock pas le début du fichier dans le .DON et l'autre partie dans le .POS.

Avoir seulement 1 fichier .POS ou .DON c'est comme avoir rien....
Il faut absolument avoir les 2 pour reconstituer le fichier avec la table de désencryption.

C'est réel.... ça marche.

Relis mon post, j'ai bien compris ce que tu fais, mais ça ne change strictement rien à mon argument... Mon "C'est exactement ce que tu fais" n'était pas à prendre au pied de la lettre, mais comme : "cette méthode et la tienne sont parfaitement équivalente dans l'esprit". Et le fait que "ça marche" ne change pas le fait qu'il ne s'agit pas de cryptographie, j'ai écris des dizaines de programmes qui marchent parfaitement et qui n'ont rien à voir avec la cryptographie... (as-tu vraiment l'esprit littéral ? J'attend ta réponse pour conclure)

(par ailleurs, une "nouvelle méthode d'encryptage révolutionnaire" annoncé par un type parfaitement inconnu sur un forum comme Developpez.com, avec un login comme le tien... Même si je n'avais rien compris à la méthode, je n'y aurais pas cru une seule seconde, désolé !)

--
Jedaï

[guill663]

Je suis désolé mais présentement je travaille sur une table de désencryption dynamique. Cette table empêchera les attaques par statistique en mode plain text. Après tout, il y a seulement 26 lettre dans l'alphabet.... pas 256....

Avant de commencer à prétendre que ce que je fais c RIEN et INUTILE (ou que ce n'est pas de la cryptographie, dit moi ce que c'est lol);

Tu pourrais essayer de comprendre ceci:

-Avoir 1 seul fichier .POS ou .DON ce n'est pas comme avoir la moitié du fichier encrypté.

-Une personne a une chance sur 16 exposant [Longueur du fichier] de décrypter le bon fichier.

-Être capable de décrypter le début du fichier ne permet pas de décrypter le reste du fichier.

Je me base sur ce principe:
C'est comme l'exemple suivant: 1+? = ?
Traduction: DON + POS = FICHIER FINAL
Il y a 2 inconnus dans l'équation.


TOUT CE QUE JE VIENT DE DIRE A ÉTÉ PROUVÉ et REVÉRIFIÉ.

Avant de parler, serais tu capable de créer un programme qui déchiffre un .DON en un fichier original ? Sans utiliser le .POS ? Avant de dire oui, essaye toi. Tu verras que c'est impossible.

Les chances sont de l'ordre de 16 exposant [Longueur du fichier];
JE LE RÉPÈTE

[guill663]

(par ailleurs, une "nouvelle méthode d'encryptage révolutionnaire" annoncé par un type parfaitement inconnu sur un forum comme Developpez.com, avec un login comme le tien... Même si je n'avais rien compris à la méthode, je n'y aurais pas cru une seule seconde, désolé !)

Faut vraiment pas avoir l'esprit ouvert pour prétendre ceci.
Il faut croire en des découvertes. Ça existe l'évolution.

[patoff]

HELLO?

cest parceque cest la PIRE ALGO au monde ce truc, ca se decrypte en moins de quelques minute/heures ... ridicule!!!

[guill663]

prouve moi le,

pour que ça soit la pire algo, il faudrais que tu sache c QUOI mon algo !!!

[Jedai]

Avant de parler, serais tu capable de créer un programme qui déchiffre un .DON en un fichier original ? Sans utiliser le .POS ? Avant de dire oui, essaye toi. Tu verras que c'est impossible.

Les chances sont de l'ordre de 16 exposant [Longueur du fichier];
JE LE RÉPÈTE

Bien sûr... J'en serais parfaitement incapable comme je l'ai déjà dit dans mon post initial, mais pas parce que tu cryptes ton fichier, simplement parce que je ne suis pas un magicien qui peut recréer l'information à partir du néant : ton fichier .DON ne contient pas l'intégralité des informations du fichier original donc bien sûr il m'est impossible de reconstituer celui-ci !

Je devrais néanmoins être plus précis : ton système s'apparente à une cryptographie à l'ancienne, archaïque, c'est-à-dire une cryptographie où il faut transmettre la clé et le message codé. Bien sûr le problème est de transmettre la clé sans qu'elle soit interceptée... Mais si on dispose d'un moyen de faire cela, pourquoi ne pas transmettre directement le fichier ?
Sauf que ton cas est incomparable à la cryptographie à l'ancienne, car elle permettait au moins de transmettre la clé d'abord (éventuellement lors d'une rencontre), puis de l'utiliser pour crypter des messages qui n'avaient pas encore été écris au moment où l'on avait remis la clé. Ton système ne permet même pas cela : tu dois disposer du message pour connaître sa clé... donc cela perd tout potentiel cryptographique.
(NB : si tu veux voir un vrai algorithme de cryptographie à l'ancienne encore utile, le "one-time-pad" est absolument inviolable (mieux que ton algorithme), mais permet de transmettre une clé puis un message, il conserve donc encore une certaine utilité pour les organismes capables d'utiliser la valise diplomatique pour le transfert des clés par exemple)

On est au temps du cryptage asymétrique guill663, plus au temps de la préhistoire de la cryptographie (et ton algorithme ne relève pas de la cryptographie de toute façon).

Faut vraiment pas avoir l'esprit ouvert pour prétendre ceci.
Il faut croire en des découvertes. Ça existe l'évolution.

Très très drôle.... Franchement essaie de réfléchir au temps qu'a déjà consacré l'humanité (et certain de ses meilleurs esprits en plus) à la cryptographie et au nombres de spécialistes qui travaillent sur le sujet actuellement... Tu penses vraiment qu'un génie qui se surnomme lui-même guill663 (note l'absence de majuscule, le chiffre ridiculeusement élevé et sans signication symbolique, l'originalité formidable de la partie "guill") va découvrir dans son coin et subitement une méthode de cryptographie qui va révolutionner le monde et va la publier AVANT d'avoir fait ses statistiques, avant d'avoir une vraie implémentation stable et multiplateforme, sans le code source (tu veux vraiment protéger ton algorithme ? je suppose que tu n'as jamais entendu parler de désassemblage, ô génie ?), avant d'avoir contacté un journal scientifique spécialisé, va la publier donc sur le forum de Developpez.com, l'endroit idéal bien sûr pour trouver les experts en cryptographie prêt à critiquer son algorithme que notre génie doit forcément connaître ?
Peut-être est-ce plutôt toi qui a l'esprit trop étroit et te prend pour plus que tu ne l'est ? A moins que tu n'ais des références de tes travaux antérieurs qui nous feront prendre conscience de ta grandeur, mais bizarrement j'en doute.


Désolé pour le ton, mais je trouve ce genre de comportement et d'assurance infondée assez énervante pour ma part.

--
Jedaï

[guill663]

Bon ok, je vais remettre les pendules à l'heure.

1 - Je sais que c'est risqué d'envoyer un .EXE car on peut désassembler le code. Mais je m'en fou, si ya qqun qui veux se donner la peine de le faire. Bein qu'il le fasse ce désassemblage !!!

2- On ne parlera pas de CRYPTOGRAPHIE ALORS. Car ça l'air que ça offusque certaines gens. Mon algorithme n'est pas DU TOUT ADAPTÉ pour fonctionner sur internet. TCP-IP...

VOICI CE QUE C'EST (EXEMPLE):

ENCODAGE:
1-Je possède un fichier se nommant FICHIER.WMV
2-Je l'encode avec mon programme.
3-J'obtient 3 fichiers; un POS et un DON et un .LIB
4-Je conserve le .DON sur mon ordinateur
5-Je conserve le .LIB et le .POS sur un autre support amovible.

DÉCODAGE:
1-Je dois absolument réunir les 3 fichiers dans le meme dossier
2-Je peux alors le décoder et réobtenir mon FICHIER.WMV

EXEMPLE CONCRET D'UTILISATION:
1- Je possède un fichier de 2 gigaoctets TRÈS CONFIDENTIEL
2- Je laisse le .DON sur mon ordinateur.
3- Je met le .POS et le .LIB sur ma clef USB de 1 gigaoctets.
4- Le seul moyen de lire le fichier confidentiel est de RÉUNIR le contenu
de la clef USB et le contenu du disque dur. (.DON+.POS+.LIB)

P.S. Lorsque le fichier .DON n'est pas avec le .POS, il est IMPOSSIBLE de réassembler le fichier d'origine. Je serais prêt à m'obstiner des heures et des heures pour vous le prouver. Si ça fonctionnerais; ça serais comme créer quelque chose avec rien. 1 chance sur 16 exposant [longueur du fichier]...... Pour ne pas dire, tes chances sont quasiment NULLES de trouver le fichier lol

Je pourrais me créer un générateur de fichiers de 1 meg !!!!
Un moment donné sans le savoir, j'aurai réussi à créer tous les fichiers de 1 meg possible sur terre MDR


Finalement, parlez moi pas de cryptographie assymétrique juste pour me caler. Je me suis TROMPÉ de terme. Vous prenez toute au littéral. Je ne dirai plus jamais le mot CRYPTER alors. je vais parler d'ENCODAGE ??? LOL


Voici la version presque finale:http://www.logementraide.com/interface/2048-kabber.zip

Il faut charger la bibliothèque au préalable avant d'encoder ou de désencryptcoder.....MDR. J'ai incorporé un exemple d'une bibliothèque de 2048bits

[guill663]

http://www.logementraide.com/interface/2048-kabber.zip

J'ai rajouté une fonction de création de bibliothèque de 2048bits aléatoirement.

ça s'en vient sérieux

[pcaboche]

Bon, je vais essayer de comprendre et de rester objectif.

En gros, ton programme fait la chose suivante:
- il prend un fichier
- à partir de ce fichier, il sort 2 choses:
1) une clef publique: ton fichier DON (le plus gros) que tu peux laisser à la vue de tout le monde
2) une clef privée: ton fichier POS (le plus petit) que tu gardes précieusement sur ta clef USB

Pour reconstituer ton fichier d'origine, tu as besoin à la fois de ta clef publique et de ta clef privée.

C'est ça?

Je ne veux pas me faire voler mon code source. Alors c'est pour ça que je post seulement l'exécutable sur le forum.

C'est là que c'est un peu plus génant: en principe, pour de la cryptographie, l'algorithme est connu de tous. Ce qui fait la force d'un algo de cryptage, c'est qu'on peut difficilement retrouver la clef privée en ne connaissant que la clef publique, et ce même en connaissant l'algo de départ.

Après, comme tu dis, pour connaître l'algo on peut toujours désassembler le code (c'est plus long, mais c'est possible).

C'est révolutionnaire comme technique.

Là, je ne serait pas si sûr que toi !


<humour>
PS: Ce message a été crypté en ROT26. Toute tentative de décryptage entrainera des poursuites.
</humour>

[progfou]

Bon, ben il démarre pas ton dernier programme :
"Cette application n'a pas pu démarrer car la configuration de l'application est incorrecte. Réinstaller l'application pourrait résoudre ce problème".
Ca veut dire quoi ?
Il manquerait pas des fichiers dans ton archive ?

Sinon, ne nous énervons pas .
Tu parlais au départ de deux fichiers, et subitement, tu parles de trois (un pos, un don et un lib) .

Si tu as démontré (de manière littérale, car sinon, ce n'est pas une démonstration) qu'il est "incassable" car "1 chance sur 16^(long du fichier)", j'aimerais bien la voir, cette démonstration .
Car dire j'ai démontré ne suffit pas à convaincre, tu t'en doutes .
Euh, dernière chose, tu as quel niveau de maths (rien de subjectif derrière cette question, juste connaître ton âge, et puis ce que tu as comme "bagage", c'est tout ).

[plegat]

Salut,

A lire tout ça, je pense qu'on oublie que guill663 n'a jamais dit que son programme faisait du cryptage dans son premier post. Il dit juste qu'il sépare son fichier en deux fichiers distincts... donc normal que si on en a qu'un seul, on ne peut pas reconstruire le fichier initial (à moins de créer des données dont on ne sait rien, mais...). Pour peu qu'on mélange un peu les données séparées entre temps, ça devient un peu complexe. C'est comme si je prenais un bouquin, que je le séparais en deux en mettant une lettre sur deux dans l'un, et l'autre dans l'autre (je simplifie un peu...). Ensuite je pars avec le second volume sous le bras, et je te laisse essayer de comprendre de quoi parle le premier (encore qu'à force d'obstination, on devrait trouver... pour un livre...)

Bon, ensuite j'ai un peu lâché, ça s'embrouille un peu entre les critiques, les commentaires, et les explications. Bref, rien de bien constructif...

guill663, je te conseillerais d'étayer un peu l'aspect "commercial" de ton programme. Evite de dire que c'est révolutionnaire et que personne ne pourra casser la méthode comme ça, à froid... montre les avantages de ta méthode, des exemples concrets (le cas du fichier WMV n'est pas mal... quoi que je ne vois pas l'intérêt... si je dois me balader avec une clef USB pour pouvoir relire mon fichier...), en quoi il pourrait changer ma vie!!!

Enfin, en gros, essaye de convaincre les sceptiques... comme moi. Pour le moment, je n'ai pas envie de tester ton programme, je ne suis pas convaincu de son intérêt (je ne dis pas qu'il n'est pas intéressant, mais que je ne vois pas ce qu'il pourrait m'apporter)

[Sivrît]

Je rejoins les commentaires précédants : Ce n'est pas de la cryptographie car le fichier n'est pas codé à l'aide d'une clef mais divisé en deux. Et c'est donc difficilement cassable car on ne peut pas recréer un moceaux de fichier dont on ne dispose pas.

Par contre c'est moyennement nouveaux puisque ça s'apparente à déchirer une carte en deux avec l'idée qu"on ne touve pas le trésors sans réunir les deux morceaux. L'informatique permet juste de faire un découpage qui rend l'exploitation d'un seul des deux morceaux plus difficile.

Et surtout quelle utilité ? Prendre la moitié d'un fichier d'un giga sur sa clef USB ? Si c'est pour le protéger en le gardant physiquement sur soit autant acheter une clef de 2Go ou graver un DVD comme ça il ne reste rien du tout. En plus il faut veiller à ce que le fichier d'origine soit physiquement effacé du disque sinon on peut encore récupérer l'original dessus.

Si je dois protéger un fichier j'aime autant le crypter avec PGP par ex. Aucune technique actuelle ne peut casser ça avant que je ne meure de vieillesse et je garde ma clef dans ma tête, c'est plus sécurisé qu'un support physique. On peut se rappeller d'une clef de crypto, pas de la moitié d'un fichier de 2Go.

[Hephaistos007]

Il dit juste qu'il sépare son fichier en deux fichiers distincts... donc normal que si on en a qu'un seul, on ne peut pas reconstruire le fichier initial (à moins de créer des données dont on ne sait rien, mais...). C'est comme si je prenais un bouquin, que je le séparais en deux en mettant une lettre sur deux dans l'un, et l'autre dans l'autre (je simplifie un peu...). Ensuite je pars avec le second volume sous le bras, et je te laisse essayer de comprendre de quoi parle le premier (encore qu'à force d'obstination, on devrait trouver... pour un livre...)

+100000000

Quant on ne dipose que d'une partie d'une information, elle est inexploitable, c'est une évidence de la vie de tous les jours. Il n'y a même pas besoin de venir parler de chiffrement la dessus.

Et puis, tu décides de ne laisser qu'une partie de l'information sur le disque. Tant qu'on y est, moi je te propose de ne rien laisser du tout, tu verras, c'est une technique infaillible.

Le vrai intérêt est d'avoir une information complète, mais sous une forme incompréhensible aux personnes non autorisées. Sinon ca n'a aucun intérêt.

Bonne continuation néanmoins. A+

[guill663]

Et surtout quelle utilité ? Prendre la moitié d'un fichier d'un giga sur sa clef USB ? Si c'est pour le protéger en le gardant physiquement sur soit autant acheter une clef de 2Go ou graver un DVD comme ça il ne reste rien du tout. En plus il faut veiller à ce que le fichier d'origine soit physiquement effacé du disque sinon on peut encore récupérer l'original dessus.

1- Mon algorithme n'utilise pas le principe de clef privé et clef publique.

2- Le fichier .lib est NOUVEAU, il me permet d'avoir une sécurité supplémentaire de 256 exposant 256 au cas où le .DON serais accidentellement en présence du .POS

3- Si mon programme ne fonctionne pas c'est p-ê à cause que j'ai optimisé mon code pour les instructions processeur SSE et SSE2 dans le linker.

4- Présentement j'utilise un RATIO 4 pour 4 donc le .DON est aussi gros que le .POS.
Sécurité actuelle: 16 exposant [Longueur du fichier] pour le .POS et le .DON à part la sécurité supplémentaire du .LIB

5- Prochainement j'utiliserai un RATIO 1 pour 7 donc le .POS sera aussi grand que le 1/8 du fichier original.
Sécurité du .POS: 128 exposant [Longueur du fichier] pour le .POS et le .DON à part la sécurité supplémentaire du .LIB
Sécurité du .DON: 2 exposant [Longueur du fichier] pour le .POS et le .DON à part la sécurité supplémentaire du .LIB

6- Je ne sépare pas l'information du fichier original en 2 parties. Avoir 1 seul fichier consiste à avoir une "PROBABILITÉ" sur l'autre fichier. Le .POS et le .DON se completent. Le .LIB agit comme sécurité supplémentaire. J'imaginerais utiliser mon algorithme de concert avec la cryptographie actuelle. Ça serais INVIOLABLE.

7- Ce que j'ai remarqué avec le principe de mon algorithme; c'est qu'il est INSENSIBLE aux attaques par force brute. Le fondement même de ma technique repose sur des incertitudes et non des ÉQUATIONS MATHÉMATIQUE. (chiffrement)

Sérieusement, chu sérieux !! LOL

[TicTacToe]

Je viens ajouter mon grain de sel

Je suis totalement d'accord avec Hephaistos007.

Je ne vois aucun interet à tout ca. (a part faire le post le plus long )

Quel est l'interet / aux cryptages actuels ? il y a plutot plus de défauts que d'avantages
Si la clef doit être de la moitié, ou même 1/8 du fichier original, c'est un peu lourd...

J'imagine, 1 Tera de données confidentielles à gerer...
Elle sont bien protégées, j'ai mon HD amovible de 500Gig pour lire mes données, à me trimbaler partout...

Il faut surtout nous donner l'interet / aux cryptage de maintenant, qui sont déjà hors de portée des PC les plus puissants. (enfin je crois)

[guill663]

Quel est l'interet / aux cryptages actuels ? il y a plutot plus de défauts que d'avantages
Si la clef doit être de la moitié, ou même 1/8 du fichier original, c'est un peu lourd...
J'imagine, 1 Tera de données confidentielles à gerer...
Elle sont bien protégées, j'ai mon HD amovible de 500Gig pour lire mes données, à me trimbaler partout...

1 terraoctet sera pas assez dans 20 ans. Pense à l'avenir. Ce que je propose c'est UNE FORTERESSE. Je propose un algorithme qui est plus sécuritaire que la cryptographie actuelle.

Imaginons la sécurité absolue pour un fichier de 1 meg:
256 exposant 1048576 possibilités
256 étant le nombre de valeur possible pour un octet
1048576 étant 1 meg (1024x1024 octets)
--> Autrement dit, je possède 0 octets et je veux comme résultat le bon fichier d'un meg

Avec mon rapport 4 pour 4; je vous propose la moitié de la sécurité ABSOLUE. En plus du .LIB (256^256)
(je ne sais pas si j'additionne 256^256 avec 16^[longueur fichier] ou je le multiplie ou je le met en exposant.... EN TOUT CAS.... C'est pas mal plus sécuritaire que tout ce qui existe actuellement.

Prenons par exemple un algorithme de cryptographie actuel à 1024bits:
La probabilité est de l'ordre de 256^128. QUEL QUE SOIT la longueur du fichier.

On est loin de ce que je vous propose.....


Regardez les messages précédents et vous allez voir que mon ratio 1 pour 7 est envisageable et aussi plus sécuritaire.

[guill663]

J'ai eu mon éclair de génie pour concevoir cet algorithme quand j'étais entrain de faire de l'électronique.

J'était entrain de faire un MULTIPLEXEUR / DÉMULTIPLEXEUR.

Adresse, Donnée

POS, DON

Allumez !!!! LOL

[Jedai]

Quel est l'interet / aux cryptages actuels ? il y a plutot plus de défauts que d'avantages
Si la clef doit être de la moitié, ou même 1/8 du fichier original, c'est un peu lourd...
J'imagine, 1 Tera de données confidentielles à gerer...
Elle sont bien protégées, j'ai mon HD amovible de 500Gig pour lire mes données, à me trimbaler partout...

1 terraoctet sera pas assez dans 20 ans. Pense à l'avenir. Ce que je propose c'est UNE FORTERESSE. Je propose un algorithme qui est plus sécuritaire que la cryptographie actuelle.

T'as rien compris, il te dit que devoir se trimballer un disque de 500 Go pour assurer la sécurité de ses données c'est pas super... Quand à parler de forteresse, désolé mais si j'emploie la moitié du fichier comme clé pour le reste (puis que je la stocke ailleurs), j'obtiens un truc VRAIMENT inviolable (la sécurité absolue comme tu dis), donc ton algorithme sans parler du fait qu'il est inutilisable est vraiment faible....

Si on veut vraiment éviter que son fichier soit accessible sur son ordinateur, on peut l'emporter tout entier, c'est plus simple que d'en emporter juste une partie et ça assure tout autant la sécurité que ta solution...


J'adore en plus quand tu parles d'"éclair de génie" plus tard.
Tu ne nous as toujours pas donné tes références ou ton niveau en maths (sur lequel j'ai des doutes vu ton "je ne sais pas s'il faut multiplier ou additionner").

--
Jedaï