Discussion :

[guill663]

Bonjour, je crois avoir trouvé une méthode qui sépare BINAIREMENT un fichier en 2 parties égales.

Normalement lorsqu'on sépare un fichier en 2, on RECONNAIS les données qui s'y trouve. Même si elles sont CRYPTÉES, il suffit d'avoir la bonne clef et notre fichier est soudainement VULNÉRABLE.

Moi ce que je vous propose c'est un algorithme qui sépare le fichier en 2 sans lien LOGIQUE entre eux et le fichier d'origine. Je n'utilise même pas de clef d'encryption.

Exemple: MonFichier.exe ===> Fichier.POS et Fichier .DON

Donc il est impossible de déduire le fichier original(EXE) à l'aide d'un seul fichier(DON ou POS).

Il faut obligatoirement avoir les 2 fichiers réunis ensemble pour re-créer le fichier (Monfichier.exe)

Exemple d'application:
Je possède un fichier et je ne veux pas que personne sache c quoi qu'il contient. Alors je prend le .DON et je le laisse sur mon ordinateur. Mais je dois absolument empêcher que ses 2 fichiers se retrouvent sur le meme dossier dans mon ordinateur. Au pire je renomme le fichier pour plus de sécurité.

CONCLUSION:
Je suis capable maintenant de laisser la moitié du fichier original sur mon ordinateur en étant sûr à 100% que personne ne pourra savoir quoi que ce soit avec ce fichier étant seul. Car le contenu de chacun n'a aucun sens LOGIQUE ni MATHÉMATIQUE ENTRE EUX. C'est à dire, on ne peux pas décrypter le contenu avec une clef de désencryption.

[patoff]

Je suis tout a fait impressionné!

Ca veut dire quavec la technologie d'aujourd'hui c'est impossible de décrypter le tout!!!


Si jouvre le fichier et je lis le HEADER et c'est marquer fichier jpg, ou un document word avec ton nom dedans dans le header, ca veut dire que c'est vraiment FORT ton truc.!!!

Un prog qui merge tes fichier PLAIN text non encrypter, ca se code en 2minutes... Damn j'espere tu va worker en cryptographie dans ta future carrière de looser!

[Aurelien.Regat-Barrel]

Encore plus fort : découper un fichier de 1Mo en 1 million de fichiers de 1 octet
J'ai pas testé ton programme, mais c'est simplement un mélange d'octets. Si je concatèné Fichier.POS et Fichier .DON, j'obtiens un seul fichier avec les octets mélangés. Un petit programme qui "inverse" le début et la fin d'un programme produit un résultat comparable. Désolé, mais c'est pas du cryptage à mon avis.

[guill663]

Encore plus fort : découper un fichier de 1Mo en 1 million de fichiers de 1 octet
J'ai pas testé ton programme, mais c'est simplement un mélange d'octets. Si je concatèné Fichier.POS et Fichier .DON, j'obtiens un seul fichier avec les octets mélangés. Un petit programme qui "inverse" le début et la fin d'un programme produit un résultat comparable. Désolé, mais c'est pas du cryptage à mon avis.

Je m'excuse mais je ne MÉLANGE PAS d'octets lol
Car je ne sépare pas les octets d'un fichier à l'Autre....... on ne peux pas concaténer........ avec ma méthode. ESSAYE LE mon programme. Tu verra que le contenu des fichier .POS et .DON ne se retrouvent même pas dans le fichier d'origine.

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. Essayez le programme de cryptage en question..... C'est révolutionnaire comme technique.

Tout ce que je peux vous dire sur ma méthode c'est qu'avec un seul fichier .POS ou .DON, On ne peux pas déduire le fichier d'origine. Aucune clef d'encryption n'est utilisée. Je dirais même que le fichier lui-même est sa propre clef.

Encore plus fort : découper un fichier de 1Mo en 1 million de fichiers de 1 octet

Exemple en rapport à ta citation:
Source: "ABCDEFGH"
Fichier 1: "ACEG"
Fichier 2: "BDFH"

Voici CE QUE JE propose:
Exemple 1:
Source: "ABCDEFGH"
.POS: "@34G"
.DON: "HFd%"
Exemple 2:
Source: "IJKLMNOP"
.POS: "hFb%"
.DON: "vFR%"

Comme vous voyez, les fichiers .DON et .POS n'ont AUCUNE LOGIQUE mathématique entre eux. C'est ça différence. L'on ne peux même pas décrypter un texte brut seulement en détectant les octets redondants (la lettre "e" par exemple) pour un jour déchiffrer le message.

Car exemple l'octet "0A" peut aussi bien dire "E" que "j" ou "k"

Merci de ne pas ridiculiser ce que je prétend. MERCI

[damien99]

C'est bien trouvé comme technique,
mais il faut quant même avoir la moitié du fichier pour le lire ce qui peut être assez volumineux.
Avec une clé de cryptage traditionnelle il ne suiffit que du password (ça prend pas beaucoup de place)

C'est quant même pas mal pour les petits fichiers

[Aurelien.Regat-Barrel]

J'ai testé avec la chaine "AAB", encrypt->decrypt, j'obtiens "AA"

[guill663]

Il y a DEUX bogues dans mon algorithme et je le savais.
Il faut que ton fichier ait un nombre d'octets PAIRS.
Et il faut que le fichier soit > 2 octets je crois

Mais je vais le corriger quand je vais avoir le temps.

À part de ça il fonctionne #1 !!!! (avec des MP3, JPEG, etc.....)


Désolé

[guill663]

C'est bien trouvé comme technique,
mais il faut quant même avoir la moitié du fichier pour le lire ce qui peut être assez volumineux.
Avec une clé de cryptage traditionnelle il ne suiffit que du password (ça prend pas beaucoup de place)

C'est quant même pas mal pour les petits fichiers

LE ratio est de 4 pour 4
Je peux changer le ratio, donc le fichier .POS ou .DON sera plus petit !!! Et aussi sécuritaire.

[Aurelien.Regat-Barrel]

J'ai fait tourner ton programme. Sans se poser la question de l'algo, on constate que pour un couple non crypté A-B un couple crypté C-D est généré, avec C stocké dans un fichier et D dans l'autre. Ton algo est donc une manière économique de coder une table de correspondance sur 16 bits. Je suis désolé, mais c'est absolument pas fiable. Une analyse statistique sur du texte casse cet algo en peu de temps, sans rien savoir de lui.
Et ta table de correspondance est fixe car tu n'utilises pas de clé. Ce n'est donc pas du cryptage

Pour créer un programme de cassage:
- créer un fichier source contenant toutes la valeurs possibles sur 2 octets (en hexa : 0x0000 0x0001 0x0002 0x0003 ...)
- crypter ce fichier
- fusionner les 2 fichiers résultat en entrelançant les octets (1° octet donnee - 1° octet position - 2° octet donnee - 2° octet position - ...)
- on obtient la table de corespondance

pour décrypter un fichier : pour chaque mot de 2 octets, chercher sa position dans le fichier crypté fusionné, et en déduire celle de la valeur décryptée dans le fichier source.

[guill663]

LORSQUE les 2 fichiers .POS et .DON sont ensemble, IL N'Y A plus de sécurité. Donc on ne parle plus de cryptage.

Mais LORSQUE une personne possède seulement le .POS ou le .DON, il est tout simplement impossible de décoder QUOI que ce soit !!!

Une personne qui possède seulement un de ces fichiers, ne possède même pas la moitié début ou la moitié fin du fichier ORIGINAL non crypté.

Finalement, le ratio est de 4 pour 4. Pour ne pas dire 1 pour 1....
Les fichiers sont la moitié du fichier original.

J'envisage faire un ratio de 7 pour 1. Avec la même sécurité.

à venir......

[guill663]

Pour créer un programme de cassage:
- créer un fichier source contenant toutes la valeurs possibles sur 2 octets (en hexa : 0x0000 0x0001 0x0002 0x0003 ...)
- crypter ce fichier
- fusionner les 2 fichiers résultat en entrelançant les octets (1° octet donnee - 1° octet position - 2° octet donnee - 2° octet position - ...)
- on obtient la table de corespondance

Tu me parle de table de correspondance.... En effet il y en a une.
Mais elle est valable seulement lorsque les 2 fichiers sont réunis.
Cette table a besoin d'une valeur position et une valeur donnée.

Quand tu as seulement un fichier ça donne ceci comme exemple:
C'est comme 1+? = ?

Quand tu as les fichiers ça donne ceci comme exemple:
C'est comme 1+2 = ? ===> 3!!!!!

Tu vois..... c'est comme trouver la solution quand on connais seulement la moitié de la source de notre questionnement..... LOL

Le but de mon algorithme c'est de séparer un fichier en 2 parties pour qu'elles soient parfaitement INDISOCIABLES. C'est à dire: Si tu n'as pas le .POS et le .DON en même temps, tu ne peux RIEN faire de bon avec ces données bidons.....


Avec mon rapport 1 pour 7, il sera envisageable de laisser le .POS dans ma clef USB et le .DON beaucoup plus volumineux sur mon ordinateur !!!

En plus, je vous casse la tête avec mes .POS et mes .DON; si vous avez d'autres suggestions pour les extensions de mes fichiers, faite le moi savoir. Et puis pour le code source, c'est 1 million $US hahahahahaaha

[/quote]

[guill663]

- fusionner les 2 fichiers résultat en entrelançant les octets (1° octet donnee - 1° octet position - 2° octet donnee - 2° octet position - ...)

J'ai une chose à rajouter; ça donne rien d'alterner les octets de donnée et position puisqu'ils n'ont jamais été dissocié LOL

J'encode linéairement sans alternance. tk je dévoilerai pas ma technique

[Aurelien.Regat-Barrel]

Donc ta clé, en somme, c'est la moitié du fichier. En crypto classique aussi si tu maintiens la clé séparée du fichier crypté, avec les derniers algos, c'est très sécurisé.

[guill663]

Donc ta clé, en somme, c'est la moitié du fichier. En crypto classique aussi si tu maintiens la clé séparée du fichier crypté, avec les derniers algos, c'est très sécurisé.

oui maintenant oui...

Mais dans pas grand temps, la clef sera le 1/8 du fichier avec la même sécurité.

Vous allez voir !!! En théorie ça marche, il me reste juste modifier mon code.

2 chance * 2 chance * 2 chance * 2 chance = POSSIBILITÉ D'AVOIR LE BON FICHIER de 4 octets

Donc en mode ratio 1 pour 7, plus le fichier est volumineux, plus il est dur à décrypter. c'est exponentiel comme principe

1 chance sur 2 de trouver la bonne combinaison en mode ratio 1 pour 7 pour le 1er octet

1 chance sur 16 de trouver la bonne combinaison en mode ratio 4 pour 4 pour le 1er octet


Ce qui veux dire pour un fichier d'un meg en mode 4 pour 4:
1 meg = 1024*1024 = 1048576 octets

donc les chances sont de l'ordre de 16 exposant 1048576 pour trouver la combinaison. Ainsi de suite.

Et en mode ratio 1 pour 7 ===> 2 exposant 1048576

Donc je préconiserais le ratio 4 pour 4 pour les petits fichiers et le mode 1 pour 7 pour les grands fichiers qui de toute façon sont assez gros pour être bien protégés.

[RAPPEL]
Pour une solution donnée. Exemple : 3454
Essaye de trouver la solution si tu ne connais pas la source de ton questionnement et tu ne connais pas la réponse.
Exemple:
? + ? = ?

tu as une chance sur (256 exposant 1048576) de trouver le bon fichier d'un meg.... c'est à dire toutes les possibilités. LOL

Donc moi avec mon 16 exposant 1048576 pour 1 meg c'est DÉJÀ PAS MAL BON.

2 meg sera ===> 16 exposant 2097152 et non pas 2*(16^1048576)
Principe exponentiel.

Finalement j'appellerais mon principe le cryptage progressif exponentiel selon la taille du fichier source.

[Aurelien.Regat-Barrel]

De ce que j'ai vu dans ton principe, c'est un algo bijectif : la même double séquence d'octet est toujours cryptée de la même manière. Exemple : AABBAABBAABB produit un résultat du type XYXYXY dans un des 2 fichiers. A partir de là, c'est très peu fiable car sensible aux attaques par analyse statistique etc...
Les algos modernes ne produisent pas le même résultat pour la même séquence cryptée à 2 endroits différents du fichier.
Sur ce principe, on peut créer un truc simple à base de XOR et un seul octet au lieu de la moitié du fichier. C'est la base du cryptage le XOR. Renseigne toi dessus, ça va te plaire.
C'est pas mal pour une utilisation personnelle, mais pour crypter des communications militaires y'a mieux

Et moi je suis super nul en crypto. Je vais déplacer vers le forum algo, c'est plus approprié.

[guill663]

De ce que j'ai vu dans ton principe, c'est un algo bijectif : la même double séquence d'octet est toujours cryptée de la même manière. Exemple : AABBAABBAABB produit un résultat du type XYXYXY dans un des 2 fichiers. A partir de là, c'est très peu fiable car sensible aux attaques par analyse statistique etc...

FICHIER SOURCE:
AABBAABBAABB===>(414142424141424241414242)

.POS: 00 11 00 11 00 11
.DON: 99 99 99 99 99 99

Ce que tu ne comprend pas c'est que même s'il y a alternance de bits dans le .POS, Cette même alternance ne veux rien dire. En voici la preuve:

FICHIER SOURCE:
@@CC@@CC@@CC===>(404043434040434340404343)

.POS: 00 11 00 11 00 11
.DON: 88 88 88 88 88 88

FICHIER SOURCE:
ááFFááFFááFF===>(E1E14646E1E14646E1E14646)

.POS: CC 11 CC 11 CC 11
.DON: 55 BB 55 BB 55 BB


Voici la preuve que l'alternance des bits que tu vois n'a aucun rapport avec le type de données rencontrées. Le .POS est aussi sécuritaire que le .DON en mode de ratio 4 pour 4.

1 chance sur 16 exposant [longueur du fichier]

pour ce qui concerne le fichier contenant AABBAABBAABB,
c'est 1 chance sur 16 exposant 12.

[guill663]

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

Voici la version avec une interface Windows graphique de mon programme.

[progfou]

Ben, le fichier DON il te donne la moitié de ton résultat...
Si 9<=>B (par rapport au premier exemple), et 8<=>C alors 5<=>F... ce qui correspond exactement au troisième exemple...
Le reste est finalement simplissime !
Donc, le fichier DON n'est déjà pas très sécurisé.
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.
[Edit] 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.).

[Jedai]

Si j'ai bien compris, tu découpes le fichier en deux parties (c'est plus sophistiqué parce que dans l'un tu retiens un certain type d'information, et dans l'autre tu retiens un autre type, néanmoins ça n'influe pas sur la suite de ce que je vais dire). Et tu dis que si tu as seulement l'un des fichiers, tu ne peux pas réobtenir le fichier d'origine... En admettant que cela soit vrai, et je pense que cela l'est pour une raison toute simple : ton programme n'effectue pas de compression, donc retrouver le fichier d'origine à partir d'un des fichiers créés, plus petit reviendrait à recréer de l'information, ce qui est impossible (bien sûr sous réserve que les données soient quelconques).

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 !
Pour avoir cryptographie, il faudrait que tu puisses crypter des fichiers différents avec la même clé...

--
Jedaï

[guill663]

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.