J'essaye de développer un petit algorithme pour crypter/décrypter un
fichier de n'importe quel type. C'est plus ou moins clair dans ma tête (une
partie oui, une partie non). J'essaye de mettre ça en forme avec TURBO
PASCAL, mais j'ai des gros problèmes pour programmer (en raison de la
compatibilité des fichiers entre MS-DOS et WINDOWS).
En gros, je voulais vous expliquer un peu mon idée, et voir votre avis
là-dessus.
Ce que je veux faire : un programme (et donc un algo :) qui permette de
crypter un fichier de n'importe quel nature, s'il n'est pas trop gros
(maximum 1 à 5 Mo). En raison des contraintes imposées par le langage, on ne
peut crypter qu'un fichier à la fois. J'ai déjà fait des petits programmes
de cryptage, mais c'était des petits trucs de bricolage. Là, sans avoir
envie de pondre du DES ou quoi, j'ai quand même envie de faire quelque chose
de 'sérieux', je veux dire quelque chose qui soit vraiment dur à casser.
Il y a deux parties dans l'algorithme.
1. L'encodage.
On décompose le fichier en blocs de 8 octets (ça tombe toujours juste,
c'est arrangé...), ça nous donne un tableau 8x8 rempli de 0 ou de 1 (plus
précisément, chaque ligne comporte le code binaire d'un octet). On répète 10
fois l'ensemble suivant :
- on retourne chaque tableau individuellement ;
- on déplace les octets d'un tableau à un autre. Le résultat est assez
complexe (si on cherche à voir où les octets atterrissent).
Après l'encodage, les bits sont complètement mélangés, et on a reformé
un fichier de caractères.
2. Le cryptage.
Là, c'est un peu moins clair dans mon esprit. Je pense prendre une clef
de 16 caractères (donc en gros 255 possibilités par caractère de la clef,
moins une vingtaine (entrée, supprimer, etc.) inutilisables, donc en gros
220^16 clefs possibles). Avec cette clef, on génère une liste de nombre
pseudo-aléatoires longue (probablement 1024 octets). On code le résultat de
l'encodage avec cette clef au moyen d'un XOR. Certes, il y a répétition,
mais d'une part, la chaîne est très longue, et d'autre part, l'encodage a
complètement brouillé les bits. Je ne pense pas qu'une telle répétition
porte préjudice à la sécurité du code.
Voilà. Le principe de cryptage est très simple, en lui-même, mais il est
assez solide, je pense, du fait que la chaîne avec laquelle on code est
longue (on peut encore la rallonger), et d'autre part du fait du grand
nombre de clefs possibles qui rend très difficile le cassage par force
brute. D'autre part, l'extrême simplicité de ce procédé garantit au moins
une chose : il n'y a pas de trappe dans l'algorithme (volontaire ou
involontaire).
Alors, deux questions :
1. Est-ce que l'encodage est absolument nécessaire ? S'il est là, après
avoir testé X clefs (attaque par force brute), on reste obligé de décoder,
ça fait perdre du temps.
2. Quelle sécurité offre un algorithme de ce genre ? Les calculs ne sont
pas compliqués (donc pas longs), mais il y a un grand nombre de clefs
possibles. C'est un cryptage à combien de bits, il faudrait combien de temps
à un ordinateur classique pour casser ça par la force brute (une idée ?) ?
3. Est-ce qu'il ne vaudrait pas mieux mêler l'encodage et le cryptage,
c'est-à-dire crypter au fur et à mesure qu'on encode. Je pense que la
sécurité en serait améliorée (plus de calculs à effectuer pour un cassage
par force brute).
Merci à vous si vous prenez un peu de votre temps pour me répondre...
J'essaye de développer un petit algorithme pour crypter/décrypter un fichier de n'importe quel type. C'est plus ou moins clair dans ma tête (une partie oui, une partie non). J'essaye de mettre ça en forme avec TURBO PASCAL,
Ca existe encore? :-)
mais j'ai des gros problèmes pour programmer (en raison de la compatibilité des fichiers entre MS-DOS et WINDOWS).
Uh?
Ce que je veux faire : un programme (et donc un algo :) qui permette de crypter un fichier de n'importe quel nature, s'il n'est pas trop gros (maximum 1 à 5 Mo).
Pourquoi imposer une limite quelconque?
En raison des contraintes imposées par le langage, on ne peut crypter qu'un fichier à la fois.
Je ne suis vraiment pas convaincu...
Là, sans avoir envie de pondre du DES ou quoi, j'ai quand même envie de faire quelque chose de 'sérieux', je veux dire quelque chose qui soit vraiment dur à casser.
Pourquoi ne pas utiliser une librairie toute faite qui assurera les fonctions de chiffrement/déchiffrement? C'est la seule chose qui sera "sérieuse" sans réimplémenter soi-même des algos existants. Parce que si on n'a pas de vraies bonnes bases en crypto, inventer un algo dans la cuisine, ça ne donne en général pas de bons résultats...
On décompose le fichier en blocs de 8 octets (ça tombe toujours juste, c'est arrangé...)
Ben dans ce cas c'est pas "un fichier de n'importe quelle nature". Il vaut mieux prévoir le cas où le fichier n'a pas une longueur multiple de 8, et décider de ce qu'on fait dans ce cas (padding...). Il faut bien entendu aussi stocker quelque part des informations qui permettent de savoir ce qu'il faut "couper" au déchiffrement...
Après l'encodage, les bits sont complètement mélangés, et on a reformé un fichier de caractères.
Un fichier d'octets, plutôt.
2. Le cryptage. Là, c'est un peu moins clair dans mon esprit. Je pense prendre une clef de 16 caractères (donc en gros 255 possibilités par caractère de la clef,
Un octet a 256 valeurs possibles, pas 255.
moins une vingtaine (entrée, supprimer, etc.) inutilisables
Tout dépend du mode de saisie... Si la clef est saisie en hexa, toutes les valeurs sont utilisables. Si la clef n'est pas saisie en hexa, le nombre de valeurs "saisissables" est largement inférieur, et je ne parle même pas de ceux qui ont une vague chance d'être saisis.
donc en gros 220^16 clefs possibles). Avec cette clef, on génère une liste de nombre pseudo-aléatoires longue (probablement 1024 octets). On code le résultat de l'encodage avec cette clef au moyen d'un XOR. Certes, il y a répétition, mais d'une part, la chaîne est très longue, et d'autre part, l'encodage a complètement brouillé les bits. Je ne pense pas qu'une telle répétition porte préjudice à la sécurité du code.
Vous pensez mal. S'il y a des éléments relativement constants dans le clair (un en-tête de fichier, par exemple), on pourrait les utiliser pour retrouver au moins une partie de la clef, et à partir de là, on retrouvera le reste. Et compter sur le secret de l'algo d'encodage est une illusion qui ne tiendra pas longtemps, en plus d'être une mauvaise idée.
Au minimum, il conviendrait de faire en sorte que la "clef" de chaque bloc soit différente, par exemple calculée à partir de la clef précédente, voire à partir des données chiffrées dans le bloc précédent...
2. Quelle sécurité offre un algorithme de ce genre?
Tout dépend de qui vous tentez de vous protéger, mais ça tend vers 0...
Sérieusement, soit vous voulez inventer un nouvel algo de chiffrement, et dans ce cas vous avez vraiment beaucoup de travail (et de lecture), soit vous voulez juste implémenter quelque chose, et dans ce cas il y a des algos déjà existants qui ont fait leurs preuves, eux (parmi de nombreux autres qui ne les ont pas faites), et des librairies (et des applications) qui les implémentent déjà.
Bon courage!
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On Tue, 10 Aug 2004 13:57:04 +0200, Horace <ERROR@ERROR.fr> wrote:
J'essaye de développer un petit algorithme pour crypter/décrypter un
fichier de n'importe quel type. C'est plus ou moins clair dans ma tête
(une partie oui, une partie non). J'essaye de mettre ça en forme avec
TURBO
PASCAL,
Ca existe encore? :-)
mais j'ai des gros problèmes pour programmer (en raison de la
compatibilité des fichiers entre MS-DOS et WINDOWS).
Uh?
Ce que je veux faire : un programme (et donc un algo :) qui permette de
crypter un fichier de n'importe quel nature, s'il n'est pas trop gros
(maximum 1 à 5 Mo).
Pourquoi imposer une limite quelconque?
En raison des contraintes imposées par le langage, on ne
peut crypter qu'un fichier à la fois.
Je ne suis vraiment pas convaincu...
Là, sans avoir envie de pondre du DES ou quoi, j'ai quand même envie de
faire quelque chose de 'sérieux', je veux dire quelque chose qui soit
vraiment dur à casser.
Pourquoi ne pas utiliser une librairie toute faite qui assurera les
fonctions de chiffrement/déchiffrement? C'est la seule chose qui sera
"sérieuse" sans réimplémenter soi-même des algos existants. Parce que si
on n'a pas de vraies bonnes bases en crypto, inventer un algo dans la
cuisine, ça ne donne en général pas de bons résultats...
On décompose le fichier en blocs de 8 octets (ça tombe toujours juste,
c'est arrangé...)
Ben dans ce cas c'est pas "un fichier de n'importe quelle nature". Il vaut
mieux prévoir le cas où le fichier n'a pas une longueur multiple de 8, et
décider de ce qu'on fait dans ce cas (padding...). Il faut bien entendu
aussi stocker quelque part des informations qui permettent de savoir ce
qu'il faut "couper" au déchiffrement...
Après l'encodage, les bits sont complètement mélangés, et on a reformé
un fichier de caractères.
Un fichier d'octets, plutôt.
2. Le cryptage.
Là, c'est un peu moins clair dans mon esprit. Je pense prendre une clef
de 16 caractères (donc en gros 255 possibilités par caractère de la clef,
Un octet a 256 valeurs possibles, pas 255.
moins une vingtaine (entrée, supprimer, etc.) inutilisables
Tout dépend du mode de saisie... Si la clef est saisie en hexa, toutes les
valeurs sont utilisables. Si la clef n'est pas saisie en hexa, le nombre
de valeurs "saisissables" est largement inférieur, et je ne parle même pas
de ceux qui ont une vague chance d'être saisis.
donc en gros
220^16 clefs possibles). Avec cette clef, on génère une liste de nombre
pseudo-aléatoires longue (probablement 1024 octets). On code le résultat
de l'encodage avec cette clef au moyen d'un XOR. Certes, il y a
répétition, mais d'une part, la chaîne est très longue, et d'autre part,
l'encodage a complètement brouillé les bits. Je ne pense pas qu'une telle
répétition porte préjudice à la sécurité du code.
Vous pensez mal. S'il y a des éléments relativement constants dans le
clair (un en-tête de fichier, par exemple), on pourrait les utiliser pour
retrouver au moins une partie de la clef, et à partir de là, on retrouvera
le reste. Et compter sur le secret de l'algo d'encodage est une illusion
qui ne tiendra pas longtemps, en plus d'être une mauvaise idée.
Au minimum, il conviendrait de faire en sorte que la "clef" de chaque bloc
soit différente, par exemple calculée à partir de la clef précédente,
voire à partir des données chiffrées dans le bloc précédent...
2. Quelle sécurité offre un algorithme de ce genre?
Tout dépend de qui vous tentez de vous protéger, mais ça tend vers 0...
Sérieusement, soit vous voulez inventer un nouvel algo de chiffrement, et
dans ce cas vous avez vraiment beaucoup de travail (et de lecture), soit
vous voulez juste implémenter quelque chose, et dans ce cas il y a des
algos déjà existants qui ont fait leurs preuves, eux (parmi de nombreux
autres qui ne les ont pas faites), et des librairies (et des applications)
qui les implémentent déjà.
Bon courage!
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
J'essaye de développer un petit algorithme pour crypter/décrypter un fichier de n'importe quel type. C'est plus ou moins clair dans ma tête (une partie oui, une partie non). J'essaye de mettre ça en forme avec TURBO PASCAL,
Ca existe encore? :-)
mais j'ai des gros problèmes pour programmer (en raison de la compatibilité des fichiers entre MS-DOS et WINDOWS).
Uh?
Ce que je veux faire : un programme (et donc un algo :) qui permette de crypter un fichier de n'importe quel nature, s'il n'est pas trop gros (maximum 1 à 5 Mo).
Pourquoi imposer une limite quelconque?
En raison des contraintes imposées par le langage, on ne peut crypter qu'un fichier à la fois.
Je ne suis vraiment pas convaincu...
Là, sans avoir envie de pondre du DES ou quoi, j'ai quand même envie de faire quelque chose de 'sérieux', je veux dire quelque chose qui soit vraiment dur à casser.
Pourquoi ne pas utiliser une librairie toute faite qui assurera les fonctions de chiffrement/déchiffrement? C'est la seule chose qui sera "sérieuse" sans réimplémenter soi-même des algos existants. Parce que si on n'a pas de vraies bonnes bases en crypto, inventer un algo dans la cuisine, ça ne donne en général pas de bons résultats...
On décompose le fichier en blocs de 8 octets (ça tombe toujours juste, c'est arrangé...)
Ben dans ce cas c'est pas "un fichier de n'importe quelle nature". Il vaut mieux prévoir le cas où le fichier n'a pas une longueur multiple de 8, et décider de ce qu'on fait dans ce cas (padding...). Il faut bien entendu aussi stocker quelque part des informations qui permettent de savoir ce qu'il faut "couper" au déchiffrement...
Après l'encodage, les bits sont complètement mélangés, et on a reformé un fichier de caractères.
Un fichier d'octets, plutôt.
2. Le cryptage. Là, c'est un peu moins clair dans mon esprit. Je pense prendre une clef de 16 caractères (donc en gros 255 possibilités par caractère de la clef,
Un octet a 256 valeurs possibles, pas 255.
moins une vingtaine (entrée, supprimer, etc.) inutilisables
Tout dépend du mode de saisie... Si la clef est saisie en hexa, toutes les valeurs sont utilisables. Si la clef n'est pas saisie en hexa, le nombre de valeurs "saisissables" est largement inférieur, et je ne parle même pas de ceux qui ont une vague chance d'être saisis.
donc en gros 220^16 clefs possibles). Avec cette clef, on génère une liste de nombre pseudo-aléatoires longue (probablement 1024 octets). On code le résultat de l'encodage avec cette clef au moyen d'un XOR. Certes, il y a répétition, mais d'une part, la chaîne est très longue, et d'autre part, l'encodage a complètement brouillé les bits. Je ne pense pas qu'une telle répétition porte préjudice à la sécurité du code.
Vous pensez mal. S'il y a des éléments relativement constants dans le clair (un en-tête de fichier, par exemple), on pourrait les utiliser pour retrouver au moins une partie de la clef, et à partir de là, on retrouvera le reste. Et compter sur le secret de l'algo d'encodage est une illusion qui ne tiendra pas longtemps, en plus d'être une mauvaise idée.
Au minimum, il conviendrait de faire en sorte que la "clef" de chaque bloc soit différente, par exemple calculée à partir de la clef précédente, voire à partir des données chiffrées dans le bloc précédent...
2. Quelle sécurité offre un algorithme de ce genre?
Tout dépend de qui vous tentez de vous protéger, mais ça tend vers 0...
Sérieusement, soit vous voulez inventer un nouvel algo de chiffrement, et dans ce cas vous avez vraiment beaucoup de travail (et de lecture), soit vous voulez juste implémenter quelque chose, et dans ce cas il y a des algos déjà existants qui ont fait leurs preuves, eux (parmi de nombreux autres qui ne les ont pas faites), et des librairies (et des applications) qui les implémentent déjà.
Bon courage!
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Jeff
Ca ressemble donc, si j'ai bien compris, a un code de Vernam sauf que la clef est généré a partir d'une séquence pseudo aléatoire dont la vraie clef est la graine.
Ce genre de systeme est pathétique. D'une part, le brute force est tres facile étant donné que 220^16 c'est presque rien (on est au XXI eme siècle)
D'autre part, ton "encodage" est tres simple a décoder par un processus d'analyse.
Sans compter que ton algo sera completement dépendant du systeme sur lequel il tourne, a moins de coder en dure ton generateur pseudo aléatoire (ce que je te conseil)
Alors bien évidemment, si c'est juste pour eviter que ta maman voit tes photos de Q c'est bon, mais ca ne resistera pas longtemps aux services de la dgse
Le Tue, 10 Aug 2004 13:57:04 +0200, Horace a écrit :
Bonjour...
J'essaye de développer un petit algorithme pour crypter/décrypter un fichier de n'importe quel type. C'est plus ou moins clair dans ma tête (une partie oui, une partie non). J'essaye de mettre ça en forme avec TURBO PASCAL, mais j'ai des gros problèmes pour programmer (en raison de la compatibilité des fichiers entre MS-DOS et WINDOWS). En gros, je voulais vous expliquer un peu mon idée, et voir votre avis là-dessus.
Ce que je veux faire : un programme (et donc un algo :) qui permette de crypter un fichier de n'importe quel nature, s'il n'est pas trop gros (maximum 1 à 5 Mo). En raison des contraintes imposées par le langage, on ne peut crypter qu'un fichier à la fois. J'ai déjà fait des petits programmes de cryptage, mais c'était des petits trucs de bricolage. Là, sans avoir envie de pondre du DES ou quoi, j'ai quand même envie de faire quelque chose de 'sérieux', je veux dire quelque chose qui soit vraiment dur à casser.
Il y a deux parties dans l'algorithme. 1. L'encodage. On décompose le fichier en blocs de 8 octets (ça tombe toujours juste, c'est arrangé...), ça nous donne un tableau 8x8 rempli de 0 ou de 1 (plus précisément, chaque ligne comporte le code binaire d'un octet). On répète 10 fois l'ensemble suivant : - on retourne chaque tableau individuellement ; - on déplace les octets d'un tableau à un autre. Le résultat est assez complexe (si on cherche à voir où les octets atterrissent). Après l'encodage, les bits sont complètement mélangés, et on a reformé un fichier de caractères. 2. Le cryptage. Là, c'est un peu moins clair dans mon esprit. Je pense prendre une clef de 16 caractères (donc en gros 255 possibilités par caractère de la clef, moins une vingtaine (entrée, supprimer, etc.) inutilisables, donc en gros 220^16 clefs possibles). Avec cette clef, on génère une liste de nombre pseudo-aléatoires longue (probablement 1024 octets). On code le résultat de l'encodage avec cette clef au moyen d'un XOR. Certes, il y a répétition, mais d'une part, la chaîne est très longue, et d'autre part, l'encodage a complètement brouillé les bits. Je ne pense pas qu'une telle répétition porte préjudice à la sécurité du code.
Voilà. Le principe de cryptage est très simple, en lui-même, mais il est assez solide, je pense, du fait que la chaîne avec laquelle on code est longue (on peut encore la rallonger), et d'autre part du fait du grand nombre de clefs possibles qui rend très difficile le cassage par force brute. D'autre part, l'extrême simplicité de ce procédé garantit au moins une chose : il n'y a pas de trappe dans l'algorithme (volontaire ou involontaire).
Alors, deux questions : 1. Est-ce que l'encodage est absolument nécessaire ? S'il est là, après avoir testé X clefs (attaque par force brute), on reste obligé de décoder, ça fait perdre du temps. 2. Quelle sécurité offre un algorithme de ce genre ? Les calculs ne sont pas compliqués (donc pas longs), mais il y a un grand nombre de clefs possibles. C'est un cryptage à combien de bits, il faudrait combien de temps à un ordinateur classique pour casser ça par la force brute (une idée ?) ? 3. Est-ce qu'il ne vaudrait pas mieux mêler l'encodage et le cryptage, c'est-à-dire crypter au fur et à mesure qu'on encode. Je pense que la sécurité en serait améliorée (plus de calculs à effectuer pour un cassage par force brute).
Merci à vous si vous prenez un peu de votre temps pour me répondre...
Cordialement, Christophe
Ca ressemble donc, si j'ai bien compris, a un code
de Vernam sauf que la clef est généré a partir d'une séquence
pseudo aléatoire dont la vraie clef est la graine.
Ce genre de systeme est pathétique.
D'une part, le brute force est tres facile étant
donné que 220^16 c'est presque rien (on est au XXI eme siècle)
D'autre part, ton "encodage" est tres simple a décoder par un processus
d'analyse.
Sans compter que ton algo sera completement dépendant du systeme sur
lequel il tourne, a moins de coder en dure ton generateur pseudo
aléatoire (ce que je te conseil)
Alors bien évidemment, si c'est juste pour eviter que ta maman voit
tes photos de Q c'est bon, mais ca ne resistera pas longtemps aux services
de la dgse
Le Tue, 10 Aug 2004 13:57:04 +0200, Horace a écrit :
Bonjour...
J'essaye de développer un petit algorithme pour crypter/décrypter un
fichier de n'importe quel type. C'est plus ou moins clair dans ma tête (une
partie oui, une partie non). J'essaye de mettre ça en forme avec TURBO
PASCAL, mais j'ai des gros problèmes pour programmer (en raison de la
compatibilité des fichiers entre MS-DOS et WINDOWS).
En gros, je voulais vous expliquer un peu mon idée, et voir votre avis
là-dessus.
Ce que je veux faire : un programme (et donc un algo :) qui permette de
crypter un fichier de n'importe quel nature, s'il n'est pas trop gros
(maximum 1 à 5 Mo). En raison des contraintes imposées par le langage, on ne
peut crypter qu'un fichier à la fois. J'ai déjà fait des petits programmes
de cryptage, mais c'était des petits trucs de bricolage. Là, sans avoir
envie de pondre du DES ou quoi, j'ai quand même envie de faire quelque chose
de 'sérieux', je veux dire quelque chose qui soit vraiment dur à casser.
Il y a deux parties dans l'algorithme.
1. L'encodage.
On décompose le fichier en blocs de 8 octets (ça tombe toujours juste,
c'est arrangé...), ça nous donne un tableau 8x8 rempli de 0 ou de 1 (plus
précisément, chaque ligne comporte le code binaire d'un octet). On répète 10
fois l'ensemble suivant :
- on retourne chaque tableau individuellement ;
- on déplace les octets d'un tableau à un autre. Le résultat est assez
complexe (si on cherche à voir où les octets atterrissent).
Après l'encodage, les bits sont complètement mélangés, et on a reformé
un fichier de caractères.
2. Le cryptage.
Là, c'est un peu moins clair dans mon esprit. Je pense prendre une clef
de 16 caractères (donc en gros 255 possibilités par caractère de la clef,
moins une vingtaine (entrée, supprimer, etc.) inutilisables, donc en gros
220^16 clefs possibles). Avec cette clef, on génère une liste de nombre
pseudo-aléatoires longue (probablement 1024 octets). On code le résultat de
l'encodage avec cette clef au moyen d'un XOR. Certes, il y a répétition,
mais d'une part, la chaîne est très longue, et d'autre part, l'encodage a
complètement brouillé les bits. Je ne pense pas qu'une telle répétition
porte préjudice à la sécurité du code.
Voilà. Le principe de cryptage est très simple, en lui-même, mais il est
assez solide, je pense, du fait que la chaîne avec laquelle on code est
longue (on peut encore la rallonger), et d'autre part du fait du grand
nombre de clefs possibles qui rend très difficile le cassage par force
brute. D'autre part, l'extrême simplicité de ce procédé garantit au moins
une chose : il n'y a pas de trappe dans l'algorithme (volontaire ou
involontaire).
Alors, deux questions :
1. Est-ce que l'encodage est absolument nécessaire ? S'il est là, après
avoir testé X clefs (attaque par force brute), on reste obligé de décoder,
ça fait perdre du temps.
2. Quelle sécurité offre un algorithme de ce genre ? Les calculs ne sont
pas compliqués (donc pas longs), mais il y a un grand nombre de clefs
possibles. C'est un cryptage à combien de bits, il faudrait combien de temps
à un ordinateur classique pour casser ça par la force brute (une idée ?) ?
3. Est-ce qu'il ne vaudrait pas mieux mêler l'encodage et le cryptage,
c'est-à-dire crypter au fur et à mesure qu'on encode. Je pense que la
sécurité en serait améliorée (plus de calculs à effectuer pour un cassage
par force brute).
Merci à vous si vous prenez un peu de votre temps pour me répondre...
Ca ressemble donc, si j'ai bien compris, a un code de Vernam sauf que la clef est généré a partir d'une séquence pseudo aléatoire dont la vraie clef est la graine.
Ce genre de systeme est pathétique. D'une part, le brute force est tres facile étant donné que 220^16 c'est presque rien (on est au XXI eme siècle)
D'autre part, ton "encodage" est tres simple a décoder par un processus d'analyse.
Sans compter que ton algo sera completement dépendant du systeme sur lequel il tourne, a moins de coder en dure ton generateur pseudo aléatoire (ce que je te conseil)
Alors bien évidemment, si c'est juste pour eviter que ta maman voit tes photos de Q c'est bon, mais ca ne resistera pas longtemps aux services de la dgse
Le Tue, 10 Aug 2004 13:57:04 +0200, Horace a écrit :
Bonjour...
J'essaye de développer un petit algorithme pour crypter/décrypter un fichier de n'importe quel type. C'est plus ou moins clair dans ma tête (une partie oui, une partie non). J'essaye de mettre ça en forme avec TURBO PASCAL, mais j'ai des gros problèmes pour programmer (en raison de la compatibilité des fichiers entre MS-DOS et WINDOWS). En gros, je voulais vous expliquer un peu mon idée, et voir votre avis là-dessus.
Ce que je veux faire : un programme (et donc un algo :) qui permette de crypter un fichier de n'importe quel nature, s'il n'est pas trop gros (maximum 1 à 5 Mo). En raison des contraintes imposées par le langage, on ne peut crypter qu'un fichier à la fois. J'ai déjà fait des petits programmes de cryptage, mais c'était des petits trucs de bricolage. Là, sans avoir envie de pondre du DES ou quoi, j'ai quand même envie de faire quelque chose de 'sérieux', je veux dire quelque chose qui soit vraiment dur à casser.
Il y a deux parties dans l'algorithme. 1. L'encodage. On décompose le fichier en blocs de 8 octets (ça tombe toujours juste, c'est arrangé...), ça nous donne un tableau 8x8 rempli de 0 ou de 1 (plus précisément, chaque ligne comporte le code binaire d'un octet). On répète 10 fois l'ensemble suivant : - on retourne chaque tableau individuellement ; - on déplace les octets d'un tableau à un autre. Le résultat est assez complexe (si on cherche à voir où les octets atterrissent). Après l'encodage, les bits sont complètement mélangés, et on a reformé un fichier de caractères. 2. Le cryptage. Là, c'est un peu moins clair dans mon esprit. Je pense prendre une clef de 16 caractères (donc en gros 255 possibilités par caractère de la clef, moins une vingtaine (entrée, supprimer, etc.) inutilisables, donc en gros 220^16 clefs possibles). Avec cette clef, on génère une liste de nombre pseudo-aléatoires longue (probablement 1024 octets). On code le résultat de l'encodage avec cette clef au moyen d'un XOR. Certes, il y a répétition, mais d'une part, la chaîne est très longue, et d'autre part, l'encodage a complètement brouillé les bits. Je ne pense pas qu'une telle répétition porte préjudice à la sécurité du code.
Voilà. Le principe de cryptage est très simple, en lui-même, mais il est assez solide, je pense, du fait que la chaîne avec laquelle on code est longue (on peut encore la rallonger), et d'autre part du fait du grand nombre de clefs possibles qui rend très difficile le cassage par force brute. D'autre part, l'extrême simplicité de ce procédé garantit au moins une chose : il n'y a pas de trappe dans l'algorithme (volontaire ou involontaire).
Alors, deux questions : 1. Est-ce que l'encodage est absolument nécessaire ? S'il est là, après avoir testé X clefs (attaque par force brute), on reste obligé de décoder, ça fait perdre du temps. 2. Quelle sécurité offre un algorithme de ce genre ? Les calculs ne sont pas compliqués (donc pas longs), mais il y a un grand nombre de clefs possibles. C'est un cryptage à combien de bits, il faudrait combien de temps à un ordinateur classique pour casser ça par la force brute (une idée ?) ? 3. Est-ce qu'il ne vaudrait pas mieux mêler l'encodage et le cryptage, c'est-à-dire crypter au fur et à mesure qu'on encode. Je pense que la sécurité en serait améliorée (plus de calculs à effectuer pour un cassage par force brute).
Merci à vous si vous prenez un peu de votre temps pour me répondre...
Cordialement, Christophe
Marc Lasson
Jeff wrote:
Ce genre de systeme est pathétique.
... "Celui qu'il dit, c'est c'lui qu'il l'est".
D'une part, le brute force est tres facile étant donné que 220^16 c'est presque rien (on est au XXI eme siècle)
N'importe quoi.
Alors bien évidemment, si c'est juste pour eviter que ta maman voit tes photos de Q c'est bon, mais ca ne resistera pas longtemps aux services de la dgse.
Super drôle.
-- Marc.
Jeff wrote:
Ce genre de systeme est pathétique.
... "Celui qu'il dit, c'est c'lui qu'il l'est".
D'une part, le brute force est tres facile étant
donné que 220^16 c'est presque rien (on est au XXI eme siècle)
N'importe quoi.
Alors bien évidemment, si c'est juste pour eviter que ta maman voit
tes photos de Q c'est bon, mais ca ne resistera pas longtemps aux services
de la dgse.
D'une part, le brute force est tres facile étant donné que 220^16 c'est presque rien (on est au XXI eme siècle)
N'importe quoi.
Alors bien évidemment, si c'est juste pour eviter que ta maman voit tes photos de Q c'est bon, mais ca ne resistera pas longtemps aux services de la dgse.
Super drôle.
-- Marc.
Horace
Marc...
Bonsoir.
Je n'ai pas vu la réponse qui précédait la votre propre (de Jeff ?), je crois qu'il l'a supprimée... Il a du avoir honte, je comprends. Merci en tout cas de faire preuve d'un peu de sérieux, je sais qu'on a tendance à s'en prendre assez vite aux gens qui proposent des algos ici, j'ai eu vent de quelques histoires... Merci tout de même, et tant pis si les gens sur ce forum ne sont pas très constructifs...
Bien à vous, Christophe
Marc...
Bonsoir.
Je n'ai pas vu la réponse qui précédait la votre propre (de Jeff ?), je
crois qu'il l'a supprimée... Il a du avoir honte, je comprends. Merci en
tout cas de faire preuve d'un peu de sérieux, je sais qu'on a tendance à
s'en prendre assez vite aux gens qui proposent des algos ici, j'ai eu vent
de quelques histoires...
Merci tout de même, et tant pis si les gens sur ce forum ne sont pas
très constructifs...
Je n'ai pas vu la réponse qui précédait la votre propre (de Jeff ?), je crois qu'il l'a supprimée... Il a du avoir honte, je comprends. Merci en tout cas de faire preuve d'un peu de sérieux, je sais qu'on a tendance à s'en prendre assez vite aux gens qui proposent des algos ici, j'ai eu vent de quelques histoires... Merci tout de même, et tant pis si les gens sur ce forum ne sont pas très constructifs...
Bien à vous, Christophe
Michel Arboi
On Tue Aug 10 2004 at 23:08, Jeff wrote:
220^16 c'est presque rien (on est au XXI eme siècle)
220^16 ~ 2^124 C'est presque beaucoup. On peut discuter le 220. Je viserais plutôt 64 au grand maxi. Ce qui amène quand même à 96 bits d'entropie, encore beaucoup.
C'est bizarre, mais le SEUL point qui me paraîsse difficilement attaquable, c'est justement la longueur de la clé. Tout le reste est à jeter :-]
-- http://arboi.da.ru FAQNOPI de fr.comp.securite http://faqnopi.da.ru/ NASL2 reference manual http://michel.arboi.free.fr/nasl2ref/
On Tue Aug 10 2004 at 23:08, Jeff wrote:
220^16 c'est presque rien (on est au XXI eme siècle)
220^16 ~ 2^124
C'est presque beaucoup.
On peut discuter le 220. Je viserais plutôt 64 au grand maxi. Ce
qui amène quand même à 96 bits d'entropie, encore beaucoup.
C'est bizarre, mais le SEUL point qui me paraîsse difficilement
attaquable, c'est justement la longueur de la clé. Tout le reste est à
jeter :-]
220^16 c'est presque rien (on est au XXI eme siècle)
220^16 ~ 2^124 C'est presque beaucoup. On peut discuter le 220. Je viserais plutôt 64 au grand maxi. Ce qui amène quand même à 96 bits d'entropie, encore beaucoup.
C'est bizarre, mais le SEUL point qui me paraîsse difficilement attaquable, c'est justement la longueur de la clé. Tout le reste est à jeter :-]
-- http://arboi.da.ru FAQNOPI de fr.comp.securite http://faqnopi.da.ru/ NASL2 reference manual http://michel.arboi.free.fr/nasl2ref/
Michel Arboi
On Tue Aug 10 2004 at 13:57, Horace wrote:
pour crypter/décrypter un fichier de n'importe quel type.
Encore heureux.
C'est plus ou moins clair dans ma tête (une partie oui, une partie non)
Et si vous reveniez quand ce sera clair ?
J'essaye de mettre ça en forme avec TURBO PASCAL, mais j'ai des gros problèmes pour programmer (en raison de la compatibilité des fichiers entre MS-DOS et WINDOWS).
En principe, la programmation n'est pas la partie la plus difficile dans la mise au point d'un algo de chiffrement.
crypter un fichier de n'importe quel nature, s'il n'est pas trop gros (maximum 1 à 5 Mo)
J'ai du mal à voir pourquoi l'algo serait limité par la taille des données...
En raison des contraintes imposées par le langage, on ne peut crypter qu'un fichier à la fois.
Vous parlez algo ou programme ? Si c'est un algo de chiffrement, on se fout de combien on va en faire tourner en parallèle, en série ou en quinconce.
J'ai déjà fait des petits programmes de cryptage, mais c'était des petits trucs de bricolage.
C'est bien parti pour continuer.
1. L'encodage.
Phase totalement inutile, AMHA.
2. Le cryptage. Là, c'est un peu moins clair dans mon esprit.
Dommage, c'était le seul endroit où on aurait pu parler d'algo.
Avec cette clef, on génère une liste de nombre pseudo-aléatoires longue
Avec quel algo, justement ?
Je ne pense pas qu'une telle répétition porte préjudice à la sécurité du code.
Si. Mais là n'est pas le plus gros problème.
Voilà. Le principe de cryptage est très simple
Ah ? Je n'ai pas vu le principe.
Question idiote : quel est le but recherché ?
-- http://arboi.da.ru FAQNOPI de fr.comp.securite http://faqnopi.da.ru/ NASL2 reference manual http://michel.arboi.free.fr/nasl2ref/
On Tue Aug 10 2004 at 13:57, Horace wrote:
pour crypter/décrypter un fichier de n'importe quel type.
Encore heureux.
C'est plus ou moins clair dans ma tête (une partie oui, une partie
non)
Et si vous reveniez quand ce sera clair ?
J'essaye de mettre ça en forme avec TURBO PASCAL, mais j'ai des gros
problèmes pour programmer (en raison de la compatibilité des
fichiers entre MS-DOS et WINDOWS).
En principe, la programmation n'est pas la partie la plus difficile
dans la mise au point d'un algo de chiffrement.
crypter un fichier de n'importe quel nature, s'il n'est pas trop gros
(maximum 1 à 5 Mo)
J'ai du mal à voir pourquoi l'algo serait limité par la taille des
données...
En raison des contraintes imposées par le langage, on ne
peut crypter qu'un fichier à la fois.
Vous parlez algo ou programme ? Si c'est un algo de chiffrement, on se
fout de combien on va en faire tourner en parallèle, en série ou en
quinconce.
J'ai déjà fait des petits programmes de cryptage, mais c'était des
petits trucs de bricolage.
C'est bien parti pour continuer.
1. L'encodage.
Phase totalement inutile, AMHA.
2. Le cryptage.
Là, c'est un peu moins clair dans mon esprit.
Dommage, c'était le seul endroit où on aurait pu parler d'algo.
Avec cette clef, on génère une liste de nombre pseudo-aléatoires
longue
Avec quel algo, justement ?
Je ne pense pas qu'une telle répétition porte préjudice à la
sécurité du code.
pour crypter/décrypter un fichier de n'importe quel type.
Encore heureux.
C'est plus ou moins clair dans ma tête (une partie oui, une partie non)
Et si vous reveniez quand ce sera clair ?
J'essaye de mettre ça en forme avec TURBO PASCAL, mais j'ai des gros problèmes pour programmer (en raison de la compatibilité des fichiers entre MS-DOS et WINDOWS).
En principe, la programmation n'est pas la partie la plus difficile dans la mise au point d'un algo de chiffrement.
crypter un fichier de n'importe quel nature, s'il n'est pas trop gros (maximum 1 à 5 Mo)
J'ai du mal à voir pourquoi l'algo serait limité par la taille des données...
En raison des contraintes imposées par le langage, on ne peut crypter qu'un fichier à la fois.
Vous parlez algo ou programme ? Si c'est un algo de chiffrement, on se fout de combien on va en faire tourner en parallèle, en série ou en quinconce.
J'ai déjà fait des petits programmes de cryptage, mais c'était des petits trucs de bricolage.
C'est bien parti pour continuer.
1. L'encodage.
Phase totalement inutile, AMHA.
2. Le cryptage. Là, c'est un peu moins clair dans mon esprit.
Dommage, c'était le seul endroit où on aurait pu parler d'algo.
Avec cette clef, on génère une liste de nombre pseudo-aléatoires longue
Avec quel algo, justement ?
Je ne pense pas qu'une telle répétition porte préjudice à la sécurité du code.
Si. Mais là n'est pas le plus gros problème.
Voilà. Le principe de cryptage est très simple
Ah ? Je n'ai pas vu le principe.
Question idiote : quel est le but recherché ?
-- http://arboi.da.ru FAQNOPI de fr.comp.securite http://faqnopi.da.ru/ NASL2 reference manual http://michel.arboi.free.fr/nasl2ref/
Michel Arboi
On Wed Aug 11 2004 at 20:02, Horace wrote:
je sais qu'on a tendance à s'en prendre assez vite aux gens qui proposent des algos ici, j'ai eu vent de quelques histoires...
Zappy n'est pas une référence.
Merci tout de même, et tant pis si les gens sur ce forum ne sont pas très constructifs...
Ils ne sont pas tous aussi bêtes et aussi méchants que moi. Il ne fallait pas m'invoquer.
-- http://arboi.da.ru FAQNOPI de fr.comp.securite http://faqnopi.da.ru/ NASL2 reference manual http://michel.arboi.free.fr/nasl2ref/
On Wed Aug 11 2004 at 20:02, Horace wrote:
je sais qu'on a tendance à s'en prendre assez vite aux gens qui
proposent des algos ici, j'ai eu vent de quelques histoires...
Zappy n'est pas une référence.
Merci tout de même, et tant pis si les gens sur ce forum ne sont pas
très constructifs...
Ils ne sont pas tous aussi bêtes et aussi méchants que moi. Il ne
fallait pas m'invoquer.
C'est plus ou moins clair dans ma tête (une partie oui, une partie non)
Et si vous reveniez quand ce sera clair ?
L'OP ne m'a pas parru arrogant, il a le droit ne pas être compétent. Il ne prétends pas avoir découvert un super nouveaux système de chiffrement qui va rendre AES inutile. Je ne comprends pas la nécéssité d'être désagréable.
crypter un fichier de n'importe quel nature, s'il n'est pas trop gros (maximum 1 à 5 Mo)
J'ai du mal à voir pourquoi l'algo serait limité par la taille des données...
Bien je pense qu'il veut que la clef reste suffisament grande par rapport à la taille des données à crypter.
1. L'encodage. Phase totalement inutile, AMHA.
Je pense qu'il veut faire cela afin de d'empecher les attaques sur la forme du clair (frequences, entetes ...). Je doute également que ça ait une quelquonque utilité, mais je ne suis pas capable de le prouver.
Le but recherché, c'est peut-être comme bien d'autres il s'ennuie à la plage et préfère rester chez lui à codouiller des trucs pour passer le temps.
-- Marc.
Michel Arboi wrote:
C'est plus ou moins clair dans ma tête (une partie oui, une partie
non)
Et si vous reveniez quand ce sera clair ?
L'OP ne m'a pas parru arrogant, il a le droit ne pas être compétent.
Il ne prétends pas avoir découvert un super nouveaux système de
chiffrement qui va rendre AES inutile. Je ne comprends pas la nécéssité
d'être désagréable.
crypter un fichier de n'importe quel nature, s'il n'est pas trop gros
(maximum 1 à 5 Mo)
J'ai du mal à voir pourquoi l'algo serait limité par la taille des
données...
Bien je pense qu'il veut que la clef reste suffisament grande par
rapport à la taille des données à crypter.
1. L'encodage.
Phase totalement inutile, AMHA.
Je pense qu'il veut faire cela afin de d'empecher les attaques sur
la forme du clair (frequences, entetes ...). Je doute également que
ça ait une quelquonque utilité, mais je ne suis pas capable de le
prouver.
Le but recherché, c'est peut-être comme bien d'autres il s'ennuie à la
plage et préfère rester chez lui à codouiller des trucs pour passer le
temps.
C'est plus ou moins clair dans ma tête (une partie oui, une partie non)
Et si vous reveniez quand ce sera clair ?
L'OP ne m'a pas parru arrogant, il a le droit ne pas être compétent. Il ne prétends pas avoir découvert un super nouveaux système de chiffrement qui va rendre AES inutile. Je ne comprends pas la nécéssité d'être désagréable.
crypter un fichier de n'importe quel nature, s'il n'est pas trop gros (maximum 1 à 5 Mo)
J'ai du mal à voir pourquoi l'algo serait limité par la taille des données...
Bien je pense qu'il veut que la clef reste suffisament grande par rapport à la taille des données à crypter.
1. L'encodage. Phase totalement inutile, AMHA.
Je pense qu'il veut faire cela afin de d'empecher les attaques sur la forme du clair (frequences, entetes ...). Je doute également que ça ait une quelquonque utilité, mais je ne suis pas capable de le prouver.
Le but recherché, c'est peut-être comme bien d'autres il s'ennuie à la plage et préfère rester chez lui à codouiller des trucs pour passer le temps.
-- Marc.
Michel Arboi
On Wed Aug 11 2004 at 22:50, shen wrote:
La plupart des failles que l'on trouve dans les programmes de chiffrement sont justement dû à de mauvaises implémentations de l'algo.
Mmhhh... Je dirais plutôt le cryptosystème dans son ensemble (génération des clés, par exemple). La partie algo de chiffrement pur est rarement en cause. Non ?
On Wed Aug 11 2004 at 22:50, shen wrote:
La plupart des failles que l'on trouve dans les programmes de
chiffrement sont justement dû à de mauvaises implémentations de
l'algo.
Mmhhh... Je dirais plutôt le cryptosystème dans son ensemble
(génération des clés, par exemple). La partie algo de chiffrement pur
est rarement en cause.
Non ?
La plupart des failles que l'on trouve dans les programmes de chiffrement sont justement dû à de mauvaises implémentations de l'algo.
Mmhhh... Je dirais plutôt le cryptosystème dans son ensemble (génération des clés, par exemple). La partie algo de chiffrement pur est rarement en cause. Non ?
