Algo pour crypter.

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