Nouvel algorithme d'encryption (invention)

**Keihilin** · 20/02/2006, 06h20

Tu es vraiment assis sur une mine d'or avec une pareille découverte. J'espère sincèrement que le forum n'est pas suivi par quelques méchants terroristes, sinon les cryptographes de la NSA n'ont plus qu'à aller pointer au chômage ou à laver leur déshonneur dans le sang en s'ouvrant le ventre...

Bon, sérieusement :

Ta méthode permet effectivement de protéger un fichier. Je ne suis pas le premier à le reconnaître et on va dire que ce point est acquis.

Ta méthode n'a rien, mais alors rien de révolutionnaire. Je trouve simplement hallucinant que tu puisses croire que tu es le premier à avoir l'idée de couper des bytes en 2. Même la stéganographie utilise ce principe (souvent en 3, 3, 2).

Le cryptage XOR est 100 fois plus simple à implémenter et peut être INFAILLIBLE si la clé est aussi longue que le message.

Cela a déjà été dit, mais ton orthographe limitée, ton emploi abusif des majuscules et d'un pseudo-langage SMS ainsi que cette propention "à ne pas se prendre pour de la merde", t'a décrédibilisé dès le début et commence à énerver tout le monde.

En conclusion, si tu es tellement sûr d'être un génie, dépêche-toi d'aller déposer un brevet et revient nous narguer quand tu seras milliardaire.

En attendant, je pense qu'on a fait le tour. Le sujet est clos.

**milka007** · 20/02/2006, 14h56

Bonjour

Tout d'abord, je tiens à me présenter. Ceci est ma première visite sur les forums de developpez.com (trés bons forums au passage).

Je travaille actuellement sur un projet de recherche en sécurité informatique pour les réseaux télécoms de Belgique. Sans cesse en quête de nouvelles idées, je suis pour le moins surpris par cette nouvelle methode de crytage de l'information. Je n'arrive pas bien à saisir encore quels pourrait en être les applications commerciales mais je suis persuadé (sans toutefois parler de révolution) que ce projet est une mine dort.

Je pense notamment que ce procédé peut être implémanté dans nos réséaux d'échange de fichiers ici en Belgique. Même s'il est vrai qu'il faut reconnaitre que les temps de cryptage, sont trés longs, j'aimerais toutefois en connaître d'avantage sur vos projets et vos ambitions ainsi que les éventuelles améliorations que vous pourriez procéder à votre technologie. Le temps de cryptage n'est pas vraiment un fléau pour nous belges car comme vous le dites si bien amis français, nous ne sommes pas préssés

Bonne continuation. Hate de vous lire d'avantage une fois

**guill663** · 20/02/2006, 16h41

Ta méthode permet effectivement de protéger un fichier. Je ne suis pas le premier à le reconnaître et on va dire que ce point est acquis.

Merci de l'avouer

Ta méthode n'a rien, mais alors rien de révolutionnaire. Je trouve simplement hallucinant que tu puisses croire que tu es le premier à avoir l'idée de couper des bytes en 2. Même la stéganographie utilise ce principe (souvent en 3, 3, 2).

Je ne prétend pas avoir découvert comment couper un octet en 2. Je propose seulement une application à la stéganographie en cryptographie avec un bibliothèque de cryptage/décryptage et probabilité. Merci de m'avoir donné cet information. Je ne connaissais pas le mot STÉGANOGRAPHIE

Le cryptage XOR est 100 fois plus simple à implémenter et peut être INFAILLIBLE si la clé est aussi longue que le message.

La pire FAILLE du cryptage XOR est celle-ci. Toutes les données du fichier original sont protégées par une clef de X bits. Si on découvre la clef; on découvre TOUTES l'intégralité du message en même temps. Moi ce que je propose avec mon document théorique; c'est une méthode qui utilise les probabilités et la cryptographie et qui n'a possède pas cette FAILLE MAJEURE. En plus d'être révolutionnaire; cette méthode permet d'en venir à cette conclusion: "Les chances de NE PAS décoder le fichier sont exponentielle à sa taille"

Lorsque l'on parle de CLEF on parle de PUISSANCE DE CALCUL
Toute clef se fera dévoiler un jour ou l'autre. La puissance de calcul augmente d'année en années

Quand on parle de PROBABILITÉ exponentielle selon la taille du fichier; là ça se corse,

**@drien** · 20/02/2006, 16h43

Heu là faudrait arrêter ok?

Avec XOR si tu trouve la clé tu trouve le fichier original? oui.
Et avec ta méthode si tu trouves les différents morceaux du fichier? pareil

**guill663** · 20/02/2006, 16h58

milka007:

Supposons les 4 fichiers suivants:
.POS -> POSITION dans l'adresse de la biblio où se trouve la donnée
.DON -> ADRESSE dans la biblio où se trouve la donnée
.PAR -> Si le fichier n'est pas un multiple de X alors indique le nombre de blocs de 4 bits à soustraire lors de l'encryption pour avoir la bonne taille pour le fichier final. (PAR pour PARITÉ)
.LIB -> Bibliothèque d'encryption/désencryption de 256octets,16 octets, 4 octets selon la variante.

Bonjour, voici les possibilités qu'offre les variantes de mon algorithme.
Mode 4bits DON/4bits POS:
Fichier .POS est 1/2 du fichier original et probabilité de 16^[longFichier]
Fichier .DON est 1/2 du fichier original et probabilité de 16^[longFichier]
Fichier .LIB est de 256 octets ou 2048 bits

Mode 7bits DON/1bits POS:
Fichier .POS est 1/8 du fichier original et probabilité de 128^[longFichier]
Fichier .DON est 7/8 du fichier original et probabilité de 2^[longFichier]
Fichier .LIB est de 256 octets ou 2048 bits

Mode 2bits DON/2bits POS:
Fichier .POS est 1/2 du fichier original et probabilité de 4^[longFichier*2]
Fichier .DON est 1/2 du fichier original et probabilité de 4^[longFichier*2]
Fichier .LIB est de 16 octets ou 128 bits

Mode 3bits DON/1bits POS:
Fichier .POS est 1/3 du fichier original et probabilité de 8^[longFichier*2]
Fichier .DON est 2/3 du fichier original et probabilité de 2^[longFichier*2]
Fichier .LIB est de 16 octets ou 128 bits

Mode 1bits DON/1bits POS:
Fichier .POS est 1/2 du fichier original et probabilité de 2^[longFichier*4]
Fichier .DON est 1/2 du fichier original et probabilité de 2^[longFichier*4]
Fichier .LIB est de 4 octets ou 16 bits

Ce sont les seuls applications possible de ma méthode.

On doit rester dans la partie FRACTIONNAIRE d'un octet sinon tout redevient vulnérable.

**@drien** · 20/02/2006, 17h02

Lis mon post

et oublie pas de chercher un argument valable contre ce que j'avance (d'ailleurs tout le monde ici dit la même chose : écoute et arrête de poster inutilement

)

**guill663** · 20/02/2006, 17h02

Heu là faudrait arrêter ok?

Avec XOR si tu trouve la clé tu trouve le fichier original? oui.
Et avec ta méthode si tu trouves les différents morceaux du fichier? pareil

Ma méthode est infaillible si cette condition est remplie:
Le fichier .DON et le .POS ne sont pas ensemble. Ils sont dans 2 ordinateurs différents et distants.

C'est comme avoir un message ABSTRAIT contenu dans 2 ordinateurs CONCRETS. Le seul moyen de reconstituer le message est d'avoir les 2 fichiers réunis.

**@drien** · 20/02/2006, 17h09

C'est bien ce qu'on dit tous : lit bien ça :

Ton principe n'arrivera jamais à la hauteur d'un simple XOR et on retrouvera le message d'origine si on a tes deux parties de fichiers, tout comme pour le XOR si on a la clé et le fichier crypté

**guill663** · 20/02/2006, 17h14

C'est bien ce qu'on dit tous : lit bien ça :

Ton principe n'arrivera jamais à la hauteur d'un simple XOR et on retrouvera le message d'origine si on a tes deux parties de fichiers, tout comme pour le XOR si on a la clé et le fichier crypté

Au début, j'utilisais le principe PAREIL / PAS PAREIL pour encoder mes blocs de 4 bits. J'ai évolué ma méthode avec une bibliothèque. C'est encore mieux.

PAREIL, PAS PAREIL = XOR

Et puis je ne répondrai plus à tes posts car tu es de mauvaise foi et je te conseil de relire ce forum au complet. Il répondra à tes questions. Je suis écoeuré de toujours répondre aux mêmes questions.

Bonne journée

**@drien** · 20/02/2006, 17h18

Bon je suis de mauvaise fois alors

Je me suis pourtant beaucoup retenu avant de poster

Moi remarque je préferre toi qui tente ça que les gars du forum C qui demandent qu'est-ce qu'un pointeur ou ceux qui veulent code un OS et demandent s'ils doivent savoir programmer

Je te souhaite donc bonne chance pour la commercialisation de ton algorithme, et ne posterais plus ici

**bigboomshakala** · 20/02/2006, 17h36

Envoyé par guill663

Ma méthode est infaillible si cette condition est remplie:
Le fichier .DON et le .POS ne sont pas ensemble. Ils sont dans 2 ordinateurs différents et distants.

C'est comme avoir un message ABSTRAIT contenu dans 2 ordinateurs CONCRETS. Le seul moyen de reconstituer le message est d'avoir les 2 fichiers réunis.

c'est bien joli de couper un fichier en 2 et d'avoir chaque partie sur un ordinateur différent, mais à un moment où à un autre il faudra bien les réunir pour exploiter les données ? (sinon je vois pas bien l'intérêt)

à ce moment là les 2 fichiers doivent être envoyés sur la même machine. ils peuvent être interceptés et ton algo cassé en moins de 2 d'après ce qui a été dit avant ...

**guill663** · 20/02/2006, 17h43

c'est bien joli de couper un fichier en 2 et d'avoir chaque partie sur un ordinateur différent, mais à un moment où à un autre il faudra bien les réunir pour exploiter les données ? (sinon je vois pas bien l'intérêt)

à ce moment là les 2 fichiers doivent être envoyés sur la même machine. ils peuvent être interceptés et ton algo cassé en moins de 2 d'après ce qui a été dit avant ...

Soit: ORDI A et ORDI B

L'ordinateur A possède déjà LE .DON
L'ordinateur B possède déjà LE .POS

La seule interception possible c'est 1 seul fichier qui passera par internet.
Avec un seul fichier c'est sécuritaire à 100%

L'ordinateur A reçoit le .POS et est capable de recréer le fichier original.
L'intercepteur a seulement reçu le .POS et ne sais pas quoi faire avec.

Imaginons maintenant que le message que possèdent l'ordinateur A et le B ensemble. contienne leur protocole de communication. et que chaque ordinateur envoient seulement un octet de position sur leur moitié de ficheir pour communiquer. Alors nous avons quelquechose de fiable

**Jedai** · 20/02/2006, 18h02

Envoyé par milka007

Bonjour

Tout d'abord, je tiens à me présenter. Ceci est ma première visite sur les forums de developpez.com (trés bons forums au passage).

Je travaille actuellement sur un projet de recherche en sécurité informatique pour les réseaux télécoms de Belgique. Sans cesse en quête de nouvelles idées, je suis pour le moins surpris par cette nouvelle methode de crytage de l'information. Je n'arrive pas bien à saisir encore quels pourrait en être les applications commerciales mais je suis persuadé (sans toutefois parler de révolution) que ce projet est une mine dort.

Je pense notamment que ce procédé peut être implémanté dans nos réséaux d'échange de fichiers ici en Belgique. Même s'il est vrai qu'il faut reconnaitre que les temps de cryptage, sont trés longs, j'aimerais toutefois en connaître d'avantage sur vos projets et vos ambitions ainsi que les éventuelles améliorations que vous pourriez procéder à votre technologie. Le temps de cryptage n'est pas vraiment un fléau pour nous belges car comme vous le dites si bien amis français, nous ne sommes pas préssés

Bonne continuation. Hate de vous lire d'avantage une fois

milka007, relis l'intégralité des messages et tu comprendras que cette soi-disant 'invention' est inutilisable pour le transfert sécurisé (guill663 l'as lui-même admis et vu combien il est difficile de lui faire admettre quoi que ce soit qui n'aille pas dans son sens...), et de toute façon loin d'être réellement innovante : pas du tout adapté à une application commerciale.

Je le redis encore une fois puisque ça ne semble pas s'être enregistré du côté de guill663 : avec la méthode XOR et la moitié du fichier comme clé pour l'autre moitié du fichier, on obtient un résultat encore plus sécurisé que quoique ce soit que tu proposes... (le tout beaucoup plus vite, même si je trouve très étrange que tu mettes autant de temps à appliquer un algorithme aussi simple que le tien : ça doit vraiment être codé avec les pieds)

--
Jedaï

**Jedai** · 20/02/2006, 18h04

Envoyé par guill663

c'est bien joli de couper un fichier en 2 et d'avoir chaque partie sur un ordinateur différent, mais à un moment où à un autre il faudra bien les réunir pour exploiter les données ? (sinon je vois pas bien l'intérêt)

à ce moment là les 2 fichiers doivent être envoyés sur la même machine. ils peuvent être interceptés et ton algo cassé en moins de 2 d'après ce qui a été dit avant ...

Soit: ORDI A et ORDI B

L'ordinateur A possède déjà LE .DON
L'ordinateur B possède déjà LE .POS

La seule interception possible c'est 1 seul fichier qui passera par internet.
Avec un seul fichier c'est sécuritaire à 100%

L'ordinateur A reçoit le .POS et est capable de recréer le fichier original.
L'intercepteur a seulement reçu le .POS et ne sais pas quoi faire avec.

Imaginons maintenant que le message que possèdent l'ordinateur A et le B ensemble. contienne leur protocole de communication. et que chaque ordinateur envoient seulement un octet de position sur leur moitié de ficheir pour communiquer. Alors nous avons quelquechose de fiable

Ah bon... donc d'après toi un fichier présent sur un ordinateur connecté au réseau est en parfaite sécurité tant qu'on ne l'envoie pas sur le réseau ? Mais à quoi bon s'ennuyer à le crypter dans ce cas ?

--
Jedaï

**bigboomshakala** · 20/02/2006, 18h05

Envoyé par guill663

Soit: ORDI A et ORDI B

L'ordinateur A possède déjà LE .DON
L'ordinateur B possède déjà LE .POS

Au début était l'Ordinateur A.
Dans l'Ordinateur A naquit le Fichier.
De la scission du Fichier vinrent le .Don et le .Pos.
Pour assurer leur sécurité, le .Pos quitta l'Ordinateur A.
Cependant, un Spy malintentionné créa une image du .Pos.
Le .Pos se crut en sécurité dans l'Ordinateur B.
Vint un jour où le .Don, s'ennuya du .Pos.
Aussi décida-t-il de rejoindre ce dernier.
Le Spy toujours aux aguet, créa une image du .Don.
Depuis ce jour, le Spy acquit la connaissance du Fichier.

Là tu vas me dire "le .Pos a été envoyé sur l'ordi B. et lorsqu'on a besoin à nouveau du fichier, c'est le .pos qui revient sur A et pas le .don qui va sur B".

je dis OK

mais dans ce cas... à quoi ça sert ? si c'est juste protéger des infos sur le même pc, si ce n'est pas pour communiquer avec d'autres machines, alors il y a beaucoup plus simple.

- déconnecter le pc du réseau
- graver les données et les mettre sous clés

par contre si c'est censé servir pour la transmission de données, alors c'est pas top.

**guill663** · 20/02/2006, 18h07

Ok comme vous le voulez. Moi je vais continuer à perfectionner mon protocole de communication/encryption. Dans ma tête il fonctionne #1 et il est inviolable. J'ai meme fait les calculs.

Sur ce, je clos le sujet de discussion.

Il y a trop de thomas dans la salle.

**guill663** · 20/02/2006, 18h12

Citation:
Au début était l'Ordinateur A.
Dans l'Ordinateur A naquit le Fichier.
De la scission du Fichier vinrent le .Don et le .Pos.
Pour assurer leur sécurité, le .Pos quitta l'Ordinateur A.
Cependant, un Spy malintentionné créa une image du .Pos.
Le .Pos se crut en sécurité dans l'Ordinateur B.
Vint un jour où le .Don, s'ennuya du .Pos.
Aussi décida-t-il de rejoindre ce dernier.
Le Spy toujours aux aguet, créa une image du .Don.
Depuis ce jour, le Spy acquit la connaissance du Fichier.

Je n'enverrai jamais le CONTENU de ces fichiers.

J'enverrai seulement la POSITION de ces demi fichiers..

JE NE RÉPOND PLUS. PAS PARCE QUE JE SUIS BOUCHÉ; PARCE QUE JAI AUTE CHOSE A FAIRE QUA VOUS LE PROUVER.

AMEN

**Tofalu** · 20/02/2006, 18h20

.POS -> POSITION dans l'adresse de la biblio où se trouve la donnée
.DON -> ADRESSE dans la biblio où se trouve la donnée
.PAR -> Si le fichier n'est pas un multiple de X alors indique le nombre de blocs de 4 bits à soustraire lors de l'encryption pour avoir la bonne taille pour le fichier final. (PAR pour PARITÉ)
.LIB -> Bibliothèque d'encryption/désencryption de 256octets,16 octets, 4 octets selon la variante.

On part d'un fichier qui tenait sur un Cd et on en arrive à une panoplie de 4 fichiers qui tiendront pas sur un DVD