Discussion :

[Happpy]

Bonjour tout le monde, je me suis penché sur un petit programme de chiffrement combinant XOR et César, le tout dans la table de caractère UNICODE.


J'avais déjà fait un Crypteur César et XOR (individuels) mais dans la table ASCII, ce qui est très petit.
J'utilisais un char vu que c'est exactement la bonne taille.


Donc j'aimerai savoir si c'est faisable en utilisant le type string car un char peut prendre une valeur comprise entre -128 à 127 alors que pour l'UNICODE il me faudrai de -4095 à 4095.
J'ai donc pense à le faire avec un string carrément.

Est-ce possible ?
J'ai essayé de faire ça mais ça ne fonctionne pas :

Code :

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

1
2
3
4
5
6
 
string s = "bonjour"
string x = "a"
 
s+=10;
s+=x;

Je vais poser mes questions ensuite.

Merci d'avance.

[Happpy]

Désolé du double poste mais il faut une séparation.


-------------------------------------------------------------------------

En faite, les crypteurs XOR et Cesar (crées individuellement) je les ais déjà codé et ils fonctionnent parfaitement.

Et oui je peux crypter tout type de fichiers, texte, musique, image, vidéo, ou n'importe quel autre..., aucune dégradation de données, on retrouve bien le fichier d'origine. On est super fier quand on fait un programme comme ça, je code par passe temps donc bon.

Au début, j'utilisais un unique char sur lequel j'appliquais le XOR ou ajoutais l'unique clé Cesar.

Après avoir réfléchi un peu pour le Cesar, je me suis dis qu'utiliser qu'une seule clé était trop simple... car il y aurai alors 256 cas à tester pour forcément retrouver le message original/fichier original.

J'ai donc décidé d'améliorer le programme de façon à ce que chaque caractère du fichier à crypter puisse avoir une clé qui lui soit propre.

Le cryptage s'effectue donc de la façon suivante :
Soit c_i le caractère ième du fichier à crypter et cle_i la clé du caractère i du fichier à crypter. On a :

c_1 + cle_1 ; c_2 + cle_2; c_3 + cle_3 ; c_4 + cle_1 ; c_5 + cle_2 ...
dans le cas où on aurait moins de clé que de caractères dans le message à crypter.

De là, j'ai amélioré le programme et il fonctionne.
Le comble du raffinement (je reprends ton expression que j'adore Mathéo :p ), j'ai donné la possibilité à l'utilisateur de générer un fichier de clés.
On peut donc crypter à partir de ce fichier clés où chaque clé Cesar est écrite sur une ligne.
Le fichier clé a la même extension que le fichier à crypter. Donc on pourrait voir un jpg alors que c'est un fichier clé en réalité (camouflage)

L'utilisateur a juste à taper combien de clés Cesar (dans l'ASCII une clé peut donc avoir une valeur comprise entre -127 et 127) il veut et le programme les génère de manière aléatoire et de façon très rapide.

De là, la puissance et les possibilités deviennent très grandes en fonction de la taille du message à crypter. Bien-sûr on va me dire qu'on peut obtenir toutes sortes de choses, oui et alors, il faut trouver la chose, l'unique, ça ne résout pas le problème de décryptage pour un curieux. Cela reviendrai à analyser toutes les phrases de x caractères qui ont un sens. Et rien ne dis que l'utilisateur a crypté quelque chose qui a un sens, un numéro par exemple, du binaire... bref, rien n'est résolu.


Soit x la taille du message à crypter et f la fonctions qui à x associe le nombre de cas que le curieux devra tester pour être sûr de trouver le message original (ou pas car il va trouver une infinité de phrases qui ont du sens, ou non, bref, rien n'est résolu pour le curieux je le répète )
On a alors f(x) = 254^x
Le curieux devra tester au plus 254 puissance x combinaisons pour trouver le message original (ou pas :p ). (sachant que 254 = 127 + 127...)

Il en est de même pour mon crypteur XOR, celui-ci peut générer une clé de y caractères notée dans un fichier clé avec lequel on pourra crypter n'importe quoi, l'utilisateur a juste a préciser la taille et chaque caractère sera généré de façon aléatoire.

Pour maximiser la sécurité, autant avoir autant de clé en César que de caractères dans le message/fichier à crypter.
Idem pour le XOR, autant avoir une clé de la même taille que le message/fichier à crypter.

Par soucis d'utilisation minimale de mémoire, le fichier à crypter est crypté caractère par caractère. Les clés sont notées individuellement dans le fichier clé pour le Cesar et caractère par caractère pour le XOR.

---------------------------------------------------------------------

De là, il y a quelques jour, j'ai découvert que la table de caractères ASCII n'était pas la plus grande... :-°
La plus grande étant l'UNICODE qui contient 4095 caractères.
En partant du même principe on aurait alors

f(x) = 4095^x
ce qui est déjà beaucoup plus grand non... ?

Ce qui n'est pas du tout négligeable car avec 276 octet à crypter on atteint 1 puissance 997 combinaisons possibles.
Ce n'est pas négligeable.


Pour corser le tout j'ai pensé (MAIS JE N'AI PAS ENCORE IMPLÉMENTÉ)à un truc tout bête mais qui a son importance.
Je l'ai appelé "COMPLÉTION".
On complète le fichier à crypter.
Par exemple on a un fichier de 200 octet à crypter.
L'utilisateur pourra dire au programme crypteur qu'il veut que le fichier à crypter fasse 10 MO (PAR EXEMPLE MAIS CA PEUT ETRE PLUS OU MOINS tant que c'est supérieure à la taille réelle du fichier, la variable utilisée sera un double donc le choix sera flexible) (le fichier à crypté n'est pas modifié physiquement, tout se fait dans le crypteur...)
De là, le crypteur va considérer qu'à la fin de ce fichier à crypter il y a autant d'espace que nécessaire pour que ce fichier à crypter fasse 10 MO (ce n'est pas le cas physiquement je rappelle !).

On a donc 4095 puissance (10 * 1024) cas qui devront être testés par le curieux pour retrouver ce message original en considérant que chaque caractère a une clé aléatoire qui lui est propre.

Une fois décrypté, le programme crypteur va supprimer les espaces en trop (tant qu'il y en a) à la fin du fichier crypté afin de le faire retrouver sa taille originale de 200 octet.

J'espère que vous comprenez ce que je fais avec ma "complétion"...
C'est pas mal je trouve... le curieux va perdre sont temps à relever toutes les phrases de (10 * 1024 = 10240) caractères qui ont un sens (ou pas) alors qu'en réalité le vrai message ne fais que 200 octet...
Et encore une fois le vrai message peut ne pas avoir de sens, d'où la puissance de ce système je trouve.


Mais je ne peux pas implémenté ma "complétion" tant que je crypte dans le domaine de l'ASCII.
D'où mon problème, j'utilise actuellement un char, donc valeur comprise entre -127 et 127, or il me faudrait l'intervalle -4095 à 4095.
Le char ne correspond plus, et le dépassement de mémoire ne serai pas du tout agréable.

D'où le fait que j'ai voulu utiliser une string.
Mais je ne sais pas si c'est correcte.
Bref, je dois pouvoir appliquer le Cesar et le XOR dans l'UNICODE.

J'espère avoir totalement expliqué comment je suis arrivé à la question que je vous pose.


Est-ce possible ?

P.S : J'aurai aimé que vous me dites ce que vous pensez de mes idées pour crypter ? Multiclés Cesar, mon idée de complétion... etc...
Après, je n'ai pas beaucoup d'expérience dans le domaine de la cryptographie , j'ai juste pensé à ça.
Je trouve que c'est vraiment très puissant.
Des spécialistes en cryptographie vont sûrement détruire mon algorithme en quelques secondes, certes, mais quelqu'un qui est "normal"(non ingénieur en informatique spécialité cryptographie ?) n'arrivera jamais à décoder un message crypté de cette simple façon.

Merci D'Avance.