Discussion :

[Rekin85]

Ah ! D'accord, je reconnais un de mes bébés

Là, il s'agit d'un cryptage par clé de longueur N; (On peut imaginer une clé aussi longue que le fichier lui-même; mais trop longue, il faut l'archiver pour la retrouver ...)

Il n'y a donc plus de génération de pseudo aléatoires, mais une xorisation sur clé string fixe. L'inconvénient est que sur cryptage d'un bmp par exemple avec une clé courte, on va vite y remarquer une redondance.... Pour éviter cela, il faudrait y introduire un "triturage" de la clé à chaque tour; on retombe ainsi dans l'esprit des vedettes de la cryptologie (AES-DES)

J'aime bien mieux le procédé par génération de pseudo aléatoires. C'est rapide et ça résiste merveilleusement bien à la cryptanalyse.

[Gilbert Geyer]

Bonjour,

Rekin85 : Là, il s'agit d'un cryptage par clé de longueur N; (On peut imaginer une clé aussi longue que le fichier lui-même; mais trop longue, il faut l'archiver pour la retrouver )

A mon avis ce n'est pas une difficulté car quelle que soit la longueur de la clef il suffit de la sauver sur le disque sous le même nom que celui du fichier-crypté mais avec une extension spécifique aux clefs pour raccrocher les wagons lors du décryptage.
En plus ça évite d'avoir à apprendre les clefs par cœur. Ajoutons aussi à ceci que plus la clef est longue et plus ça complique la vie à une Hacker éventuel, puisque la création de Clefs de N caractères dont chacun peut prendre P valeurs ça permet de créer N^P clefs et pour par exemple N=26 et P=200 ça donne 9,87801301780E282 clefs possibles : de quoi occuper un Hacker pendant des années.

L'inconvénient est que sur cryptage d'un bmp par exemple avec une clé courte, on va vite y remarquer une redondance....

Reste à savoir si ces redondances signifient qu'il s'agit d'un Bmp, ou d'un texte, ou d'un tableau de chiffres car le fichier original à crypter peut contenir n'importe quoi : la seule chose dont le Hacker peut se douter c'est qu'il s'agit d'un fichier crypté : il est bien plus facile de créer des algos de cryptage qu'à un Hacker de créer un programme de cryptanalyse efficace car les questions qu'il peut se poser son plus nombreuses que les réponses.
Voici par exemple un message crypté que j'envoie à ma frangine : [ÿöù¦ µ
¼—›ùô«
ñü·]
Que signifie-t-il ? ( les crochets délimitent le message mais n'en font pas partie)

A+.

[Rekin85]

Bonjour à tous ceux qui suivent cette discussion

Le procédé de cryptage développé en coopération ici Gilbert et moi a abouti à la construction d'une DLL utilisable en Delphi ou autres (qui acceptent les chaînes windows) mise en pièce jointe pour qui voudra l'utiliser.

Pour l'utiliser à bon escient :

1/ mettre la library CryptoV64.dll dans le même répertoire que le programme appelant
2/ placer dans la partie implémentation du programme appelant la déclaration suivante

Code :

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

procedure CrypteV64(Tp: pointer; Key: ShortString; Size: longWord); stdCall; external'CryptoV64';

3/ charger les bytes-data à crypter dans un tampon mémoire de votre choix (le mieux étant un TMémoryStream)
4/ placer la clé de cryptage-décryptage alphanumérique obligatoirement dans une shortstring car il est impossible de passer une string delphi. Le nombre de chr de cette clé doit varier de 8 minimum à 255 maximum selon le besoin de sécurité voulu (attention le décryptage correspondant ne sera possible qu'avec absolument la même clé !)
5/ crypter-décrypter avec la commande :

Code :

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

CrypteV64(Tampon,Cle,Size);

Passer à cette procedure : l'adresse du tampon (MonStream.Memory), la clé définie en shortstring, et la taille du tampon (MonStream.Size).

Garantie rapide...

[Gilbert Geyer]

Bonjour,

Rekin85 : Le nombre de chr de cette clé doit varier de 8 minimum à 255 maximum selon le besoin de sécurité voulu" :

Tout Hacker saura donc qu'il lui faut au minimum 8 chr dont chacun peut prendre plus de 200 valeurs pour commencer à espérer pouvoir décrypter quelque-chose ce qui donne au bas mot 8^200 = 4,1495E180 clefs possibles à essayer, rien que pour commencer à espérer et si l'utilisateur a utilisé une clef de 16 chr c'est encore pire.

Un ordinateur essayant un million de clés par seconde (une année comptant 31 557 600 secondes) mettrait pour tester le minimum de 8^200 clefs possibles 4,1495E180 /(1E6*31 557 600) = 1,3149E167 années soit des Milliards de Milliards d'années, rien que pour espérer de décrypter sans y arriver : c'est l'enfer garanti pour un Hacker.

... et si l'utilisateur est un parano de sécurité et a en plus sur-crypté c'est l'enfer à perpétuité...

A+.

[Gilbert Geyer]

Bonjour,

Je tiens à rectifier l'erreur de calcul dans mon message précédent où je disais "au minimum 8 chr dont chacun peut prendre plus de 200 valeurs pour commencer à espérer pouvoir décrypter quelque-chose ce qui donne au bas mot 8^200 = 4,1495E180 clefs possibles" : ce n'est pas 8^200 mais 200^8 = 2,5600E18 ce qui fait qu'un ordinateur essayant 1 million de clefs par seconde ne mettrait que 81121 années pour les tester toutes mais ça reste suffisant pour dissuader un Hacker sans oublier qu'en utilisant la CryptoV64.dll de Kr85 avec une Clef de 73 caractères ça donne 200^73 = 9,4447E167 clefs possibles et on retrouve nos Milliards de Milliards d'années.

A+.