Nouvel algorithme d'encryption (invention)

**guill663** · 19/02/2006, 17h57

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

C'est toi qui a rien compris LOL ce n'est pas la moitié du fichier mais le 1/8. Je possède le fichier .EXE sur mon ordinateur. je vais le mettre sur le forum + tard.

On le sait que tu ne veux rien comprendre

T'aime ça t'ostiner.

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

Je m'excuse; TOUT fichier étant en son seul entité. Où qu'il soit est VULNÉRABLE. Si jamais tu te ferais voler ta clef USB avec ton fichier au complet IL RESTE VULNÉRABLE. Moi ce que je propose c'est une SORTE D'ARCHIVAGE de données dont le fichier .POS serais sur un ordinateur en CHINE par exemple et le .DON serais sur la LUNE. LOL

Il faut VOLER les 2 ordinateurs pour être capable de reconstituer le fichier.
Si je ré-encode le résultat de mon encodage, j'obtient 2 .DON et 2 .POS alors je peux les mettre sur 4 ordinateurs ainsi de suite!!

VOICI une application à mon algorithme. Ton exemple de ton disque dur de 500 gig est logique. Tu n'avais pas la bonne interprétation utile à ma méthode.

**guill663** · 19/02/2006, 17h59

donc ton algorithme sans parler du fait qu'il est inutilisable est vraiment faible....

Tu es comme un enfant alors je dois comprendre le contraire !!! MERCI du compliment.

donc ton algorithme sans parler du fait qu'il est utilisable est vraiment fiable....

**pcaboche** · 19/02/2006, 18h17

Envoyé par guill663

J'ai eu mon éclair de génie...

Ca va? T'as pas trop les chevilles qui enflent?

**guill663** · 19/02/2006, 18h19

Non! J'ai tellement la certitude que mon algorithme est FIABLE et SÉCURITAIRE. Je me le suis même prouver en calcul de probabilités.

Alors pourquoi je continue à répondre a vos demandes ?

1- Je veux partager ma découverte

2-J'aime les gens qui s'ostinent

sont tellement cute !!

**guill663** · 19/02/2006, 18h46

Je viens de découvrir une vertue à mon algorithme (HAaaa non pas encore LOL)

Les voici:
Une redondance dans le fichier source indique forcément une redondance dans l'un des deux fichier .POS ou .DON.

Une non redondance dans le fichier source peut être redondante ou non dans un ou l'autre ou les 2 fichier .POS et .DON.

CONCLUSION:
Mon algorithme est insensible aux attaques par STATISTIQUE positionnelle. Donc on ne peux pas déduire si un caractère est redondant dans le fichier source si il y a une redondance dans le .POS ou le .DON.

chu ému MDR

Je viens de corriger quelque chose à mon programme.

AVANT:
MonFichier.exe
kab.pos
kab.don
kab.par
kab.lib

APRÈS:
MonFichier.exe ===> ORIGINAL
MonFichier.exe.pos ===> POSITIONS
MonFichier.exe.don ===> DONNÉES
MonFichier.exe.par ===> PARITÉ SUR LA TAILLE DU FICHIER ORIGINAL
MonFichier.exe.lib ===> BIBLIOTHÈQUE DE DÉCODAGE

J'ai fait ceci pour ne pas être obligé de renommer à chaque fois les fichiers.

Vous remarquerai aussi qu'il y a un fichier de plus. Le .PAR
Il sert seulement à déterminer le nombre de bits à enlever à la fin du fichier. Car en mode 4:4 si la longueur du fichier est impaire, alors lors de son décodage, il aura un OCTET de trop !!! le .PAR sert seulement à empêcher de recréer un octet de trop à la fin du fichier.

.PAR = PARITÉ

P.S. Ultérieurement, je pourrai fusionner le .PAR et le .LIB etc...

**Jedai** · 19/02/2006, 19h15

Envoyé par guill663

donc ton algorithme sans parler du fait qu'il est inutilisable est vraiment faible....

Tu es comme un enfant alors je dois comprendre le contraire !!! MERCI du compliment.

donc ton algorithme sans parler du fait qu'il est utilisable est vraiment fiable....

Je voulais dire que l'algorithme qui prend comme clé la moitié du fichier et l'utilise pour encoder l'autre moitié est juste inviolable tandis que ton algorithme semble (d'après tes calculs, vu qu'on a pas l'algorithme, on ne peut pas savoir s'ils sont exacts, et tu n'est même pas vraiment sûr du résultat) laisser une probabilité bien plus grande que 256^(longueur du fichier / 2) de retrouver une partie des données originale.

(J'aime bien le "comme un enfant"... pour ta gouverne bien que je ne sois pas un spécialiste, je pense qu'être un Normalien spécialisé en Informatique théorique me donne plus d'autorité (aussi limité soit elle) sur le sujet qu'une personne qui se refuse à donner ses références)

--
Jedaï

**Eric Sigoillot** · 19/02/2006, 19h17

Eh, moi je prends mon fichier, je le zip, et je copie les octets pairs dans un coin, et les impairs dans l'autre.
J'ai deux fichiers, impossible de retrouver les données initiales si on assemble pas les deux fichiers.

Est-ce pour autant révolutionnaire ? Bien sûr que non... A l'heure actuelle, tout l'intérêt de la protection des données tient dans le fait que connaître l'algorithme et disposer des données cryptées ne permet pas de reconstituer les données originales sans avoir la connaissance de la clé.

Les méthodes précédentes, ressemblant aux tiennes, ou bien s'appuyant sur le fait que l'algorithme n'ait pas été dévoilé, sont passées de mode. En effet, il est très simple d'intercepter des données. Si une information est extrêmement confidentielle, qu'elle soit stockée en deux, quatre ou 50 000 bouts ne change pas grand chose : elle est vulnérable.

Donc ta méthode ne semble pas spécialement intéressante. Par exemple, avec ce que j'ai écrit au debut de mon message, non seulement les données ne sont pas reconstituables avec un seul des deux fichiers, mais en plus elles prennent moins de place qu'à l'origine. Ce serait presque mieux que le tiens. C'est dire...

Si tu arrives à nous donner posément un exemple d'application concrête et unique, alors on sera prêt à t'écouter plus avant. Pour le moment, le seul exemple d'utilisation que tu as donné est tout sauf convaincant : j'applique la méthode que j'ai écrite plus haut, et moi aussi je peux me balader avec mon bout de fichier.

Tout attitude : "eh, regardez, j'ai réussi un truc, youhou, je suis le meilleur" fait plus penser à de la masturbation intellectuelle sans grande prétention qu'à autre chose...

@++

**Tofalu** · 19/02/2006, 19h26

Bon je vais essayer d'être objectif.

En gros pour protéger ton fichier, tu en distribues une partie en public (le don) et l'autre partie tu la gardes pour toi (le pos). Dans ce cas, ne serait t'il pas plus sûr de ne rien distribuer du tout ?

**pcaboche** · 19/02/2006, 20h04

Je vais te donner une nouvelle idée d'algo:

1) tu donnes à l'application un mot de passe
2) à partir de ce mot de passe, l'application génère un fichier de longueur au moins égale au fichier à crypter
3) l'application fait un XOR entre le fichier de départ et le fichier généré pour obtenir le fichier crypté

Voilà, c'est un procédé simple, fiable et quasi indéchiffrable (1 chance sur 2^(longueur du fichier) de déchiffrer)

C'est un procédé révolutionaire, je suis sûr que personne n'y a pensé avant...

J'ai eu cet "éclair de génie" alors que je surfais un dimanche sur un forum (note: cet "éclair de génie" m'a d'ailleurs complètement grillé le cerveau...)

**HanLee** · 19/02/2006, 20h17

Envoyé par Jedai

je pense qu'être un Normalien spécialisé en Informatique théorique

Whaaa bravo

**progfou** · 19/02/2006, 20h59

J'enfonce le clou, je reste objectif moi aussi : tu en es où dans les études ?
C'est pourtant pas dur comme question...
Je ne suis pas Normalien, mais masterien (lol), c'est à dire en Master Elec/info spécialisé dans le traitement du signal.

Ton histoire de multiplexage/démultiplexage m'a éclairé (moi aussi

), car il s'avère que je connais assez bien le principe, tu t'en doutes.
En relisant, tu dis que tu fournis le .don qui sont les données, et à un autre endroit, tu me dis que 9 n'est pas forcément A, 8, pas forcément B, etc.
Bon, ben c'est pas logique ça

.
Et puis, les positions, oui c'est important c'est évident, mais il suffit d'avoir UNE information à priori sur le fichier pour déjà éviter un certain nombre de probabilités (j'arrive pas à formuler ma phrase autrement, désolé).
Exemple ?
Un fichier wav (c'est simplissime comme exemple), tu sais qu'il a un header de 56 octets dont la moitié, en gros, est connue. Si (je dis bien si) on a le programme, on envoie un fichier wav dedans, puis un second qui n'a pas grand chose qui change (un octet typiquement), et on peut retrouver le header, donc ses positions.
Mais, bien évidement, ton algorithme est bien plus malin, car il attribue des positions pseudo-aléatoires (ta fameuse table de correspondance ?), et elles sont connues par le programme qui décode, car il les trouve dans le fichier .pos. Me trompes-je beaucoup ?

Ce serait bien de ne pas trop te prendre la tête, car avant d'avoir des éclairs de génie, encore faut-il prouver formellement (cherches ce que c'est si tu ne sais pas) que ce que l'on a produit est vraiment différent (...) et efficace.
Pour cela, il faut faire valider son algo, et pour ça il faut en montrer les parties critiques, à savoir les méthodes (pas forcément le code en lui-même, mais du pseudo-code ça peut suffire).

**guill663** · 19/02/2006, 21h13

Bon ok, vous avez gagné, jva être obligé de poster le code source de mon algorithme avec ratio 4:4 pour vous convaincre.

http://www.logementraide.com/interface/source.cpp

MAINTENANT,PROUVEZ MOI QUE MON ALGORITHME EST POURRIT ET NULL À "&&""&&"&"

DONNEZ MOI DES EXEMPLE :p

**guill663** · 19/02/2006, 21h17

Eh, moi je prends mon fichier, je le zip, et je copie les octets pairs dans un coin, et les impairs dans l'autre.
J'ai deux fichiers, impossible de retrouver les données initiales si on assemble pas les deux fichiers.

Fait moi rire.

Si tu copie les octets pairs dans un fichier .PAR et les octets impairs dans un fichier .IMP par exemple, comment va tu être capable de réassembler le fichier original ????? Il te faudra un fichier .POS pour savoir la position des octets pairs ou impairs.... Donc ça va prendre plus de place que le fichier non codé AHAHHAHAHAHAAH

Source:

00 02 04 05 06 05 02

.IMP
05 05

.PAR
00 02 04 06 02

.POS
?!?!?!? lol

ou bien ceci:

Fichier Source:
SALUT JE ME MARRE

.PAR
SLTJ EMRE

.IMP
AU EM AR

TU VOIS..... ON PEUX DEVINER LE MESSAGE

**Jedai** · 19/02/2006, 21h20

Envoyé par HanLee

Envoyé par Jedai

je pense qu'être un Normalien spécialisé en Informatique théorique

Whaaa bravo

Merci

Mais c'était juste pour dire que tant qu'il ne nous donne pas ses références, on ne peut avoir absolument aucune confiance en ses prétendus calculs (dont il n'est même pas sûr) vu qu'il ne donne pas l'algorithme, et que sans ces références, même la parole d'un non-expert (comme moi) ayant un peu de connaissances mathématiques (et en informatique) a plus de poids.
(je ne suis pas spécialiste du domaine, pas du tout, et je n'aurais pas la prétention de le prétendre ou de prétendre avoir inventé un nouvel algorithme sans l'avoir au moins soumis à un expert.

Mais bien sûr tout cela en admettant que cette méthode ait le moindre intérêt ce qui n'est pas le cas, pour les raisons évoquées par Hdd34.

--
Jedaï

**plegat** · 19/02/2006, 21h26

Envoyé par guill663

Source:

00 02 04 05 06 05 02

.IMP
05 05

.PAR
00 02 04 06 02

.POS
?!?!?!? lol

Par octet pair et impair, Hdd34 parlait des positions, pas des valeurs...
Donc:
.IMP: 00 04 06 02
.PAR: 02 05 05
Je te laisse les regrouper pour reformer le message de départ, c'est assez simple...

Envoyé par guill663

AU EM AR

TU VOIS..... ON PEUX DEVINER LE MESSAGE

Ouaip... je vois... quand on le connait c'est sûr que ça saute au yeux!

Faut arrêter la mauvaise foi...

**guill663** · 19/02/2006, 21h28

Par octet pair et impair, Hdd34 parlait des positions, pas des valeurs...
Donc:
.IMP: 00 04 06 02
.PAR: 02 05 05
Je te laisse les regrouper pour reformer le message de départ, c'est assez simple...

Ouiiiii mais SVP essaye de comprendre ceci.

Je ne sépare pas les octets pairs et impairs en les mettant SIMPLEMENT dans 2 fichiers différents....

Soit plus sérieux SVP je ne suis pas nouille !! HAHAAHHAAH

je sais que c pas sécuritaire ce que tu viens de me sortir là....

**progfou** · 19/02/2006, 21h29

Je survole le code, et je trouve ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
void creerBibli() //Permet de créer une bibliothèque aléatoirement 256^256 possibilités

J'ai gagné !
Trop fort, sans l'algo dis donc...
Bref...

Autre chose, tu as déjà programmé dans une école ?
Parceque ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
unsigned char lowBitsToChar(lowbit &hibit, lowbit &lowbit)
{
	return (hibit.low*16)+lowbit.low;
}

Et ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
void charToLowBits(unsigned char entree,lowbit &hibit, lowbit &lowbit)
{
	hibit.low=entree/16;
	lowbit.low=entree;
	return;
}

Ca me fait froid dans le dos

**guill663** · 19/02/2006, 21h30

Arrête de survoler et criquer ma technique de codage. ET ESSAYE DE COMPRENDRE LE CODE au complet avant de sauter aux conclusions

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

void creerBibli() //Permet de créer une bibliothèque aléatoirement 256^256 possibilités

Ce code est pour le .LIB C'EST SECONDAIRE

**Jedai** · 19/02/2006, 21h32

Envoyé par plegat

Envoyé par guill663

Source:

00 02 04 05 06 05 02

.IMP
05 05

.PAR
00 02 04 06 02

.POS
?!?!?!? lol

Par octet pair et impair, Hdd34 parlait des positions, pas des valeurs...
Donc:
.IMP: 00 04 06 02
.PAR: 02 05 05
Je te laisse les regrouper pour reformer le message de départ, c'est assez simple...

D'ailleurs son deuxième exemple suit ce principe... Mauvaise foi ?

Envoyé par plegat

Envoyé par guill663

AU EM AR

TU VOIS..... ON PEUX DEVINER LE MESSAGE

Ouaip... je vois... quand on le connait c'est sûr que ça saute au yeux!

Faut arrêter la mauvaise foi...

Sans parler du fait que hdd34 avait parlé de le zipper avant...

De toute façon, on ne le discute pas : on ne peut pas reconstituer le fichier original à partir de l'un des fichiers qu'il crée, c'est normal puisqu'on ne sait pas reconstituer l'information à partir du néant... Bien sûr c'est pareil pour la solution d'hdd34.

--
Jedaï

**progfou** · 19/02/2006, 21h34

Ton code est impossible à porter sur une autre archi, il est construit avec un wizard Microsoft et, en conséquence, bref...

Le temps que je comprenne le code (non commenté, ou presque !!), tu peux nous en dire un poil plus sur toi ?

Nouvel algorithme d'encryption (invention)

Traitement du signal

Discussions similaires

Partager

Partager