Discussion :

[Happpy]

(Je suis désolé de poster ça encore une fois ici mais je n'avais vraiment pas vu qu'il y avait une section C++)

Bonjour tout le monde, j'ai crée deux crypteur, un Cesar et un pour le XOR.
Sur l'ASCII, soit, avec un char.

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, 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émenter 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.

C'est pourquoi j'aimerai savoir comment faire pour travailler dans le domaine de l'UNICODE (les 4095 caractères) en pouvant appliquer le Cesar et le XOR. Le char ne convient plus ici...
Bref, je dois pouvoir appliquer le Cesar et le XOR dans l'UNICODE (4095 caractères).

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.

[bacelar]

J'ai un peu tout lu en biais.

Primo : tes assertions sur la sécurité de ton code sont ridicule.
Tu ne pense qu'en attaque par brute-force, ce n'est que l'ultime moyen, mais la boite à outils d'un cryptanalyse est bien plus fournie que cela (cryptanalyse différentielle, attaque par rejet, man in the middle, sécurisation de clé secret ....)

Franchement, votre truc est un jouet qui ne résistera pas 5 minutes à un pro du domaine.

En plus c'est s'en compter sur l'attaque directe votre implémentation.

Pour le péquin moyen, une simple sauvegarde binaire fait l'affaire, pour le power-user, un Xor fixe (comme les vieux fichiers Office) suffi.

Si c'est pour des personnes au-dessus du power-user, développeur de base par exemple, c'est un rideau de fumer votre truc, pas plus (du vaporware). Un simple programme comme processExplorer permet de voir les fichiers ouverts par un programme et donc un programme résident n'aura aucun mal à trouvez la relation entre vos entrées, vos sorties, et ce fichier.

Vous dite qu'unicode à une taille de 4095 caractères, ce qui est totalement faux, et vous limitez aux caractères "imprimable" est un non-sens en cryptologie (mais c'est peut-être pour tromper l'ennemie ).

En résumé, votre truc est un jouet et pourquoi ce limiter à 4095 combinaisons quand le format UNICODE-16 permet 2^15 (32768) combinaisons pour la même taille.

[Happpy]

Quand je parlais de sécurité c'était dans le cas où le curieux ne s'y connaîtrait pas du tout en informatique. Ou pas assez du moins. Je suis pertinemment conscient qu'il existe des algorithmes beaucoup plus puissants comme l'AES ou le RSA.

Ensuite, je n'ai pas très bien compris les les deux derniers paragraphes...

[bacelar]

Quand je parlais de sécurité c'était dans le cas où le curieux ne s'y connaîtrait pas du tout en informatique

Alors la simple utilisation du binaire suffit largement.
Quand on fait du chiffrement, il faut prendre tout l'espace des valeurs possibles, dans un UNCODE encodé sur 2 octets, il 2^15 valeurs possibles, que le forum UNICODE l'ait attribué à un caractère chinois, japonais ou Klingon, on s'en fout.
Le but, n'est pas de l'affiché dans une police UNICODE mais de le crypté en utilisant le plus de valeur possible, car c'est dans cet entropie que la sécurité réside.

An clair, les tables UNICODE ne servent à rien en cryptologie. Vous avez un flux de données à convertir, qu'il soit UNICODE, ASCII, EBCDIC, cela ne change rien au problème.

Si vous voulez utilisés une clé de 10Moctects, commencez par utiliser toutes les valeurs possibles de 32Ko, c'est bien plus safe.

[Happpy]

D'accord.
Dans ce cas, j'utilise un char tout simplement ?
Sur lequel j'applique un XOR ? (je crypte caractère par caractère)

?

Pour le Chiffrement Cesar c'est pareil, un char suffira ?

Pour la génération de clés aléatoire, il faudra que je génère des caractères sur 4095 valeurs non?

[bacelar]

La sécurité n'est pas dans la taille du masque du XOR où dans la taille de l'opération d'addition, elle dans la taille de votre clé (la taille ne nombre de valeur possible, pas en taille d'octets, si vous n'utilisez pas toutes les valeurs possible d'un octect.
Le fait de faire octet par octet va être un problème de performance, pas de sécurité.
Faire un XOR octet par octet ou 2 octets par 2 octets, c'est la même chose.
Ca va juste 2 fois plus vite.

Pour le Chiffrement Cesar c'est pareil, un char suffira ?

J'ai une clé de 2 octets de 8 bits = possibilités de sortie (entropie du système): 256 * 256 = 65536 possibilités à attaquer en brut force.

Une clé de 1 fois 16 bits = possibilités de sortie (entropie du système): 65536 possibilités à attaquer en brut force (j'avais oublié les nombre négatifs ).
C'est donc pareil, ce qui compte c'est la taille
de la clé

Pour la génération de clés aléatoire, il faudra que je génère des caractères sur 4095 valeurs non?

NON, vos clés non pas à être imprimables.
Si votre clé fait 128bits de longs (16 octets).
Générer 16 valeurs entre 0 et 255 ou 8 valeurs entre 0 et 65535, c'est pareil.
La force de la clé = 2^128 = 3,4028236692093846346337460743177e+38

avec votre approche : 4095 ^ 8 = 790735521710712805518128906252

Moralité, votre espace de cryptage est ~4303365128 plus faible que celui qui utilise toutes les valeurs possible, et cela, avec une simple clé 128bits.

Si vous voulez rendre vos clés imprimable, utilisez un encodage aussi simple que du Base64, c'est pas beaucoup plus long que le binaire mais toutes les valeurs des octets y sont possibles.

[Happpy]

Si votre clé fait 128bits de longs (16 octets).
Générer 16 valeurs entre 0 et 255 ou 8 valeurs entre 0 et 65535, c'est pareil.

D'accord !
Je comprend mieux.
Je peux donc continuer à utiliser mes char tranquillement alors. Je m'en fiche donc du reste sachant que le fichier est ouvert en binaire.

128 bit c'est rien je trouve, dans le cas du XOR je veux dire.
Si la clé fait la même taille que le message.

Si on a un message de 200 octet on aura donc une clé de 1600 bit
soit de la puissance 602 cas à attaquer en force brute ?
On a f la fonction qui a x associe le nombre de cas à attaquer en force brute :
f(x) = 2^(8x) où x est la taille en octet du message à crypter, qui est aussi la taille en octet de la clé XOR.

Est-ce bien ça ?

Ça devient très grand car 200 octet c'est très petit encore...

Par contre, ça me semble fou que vous dites que le XOR est un "jouet", les technique de décryptage d'aujourd'hui doivent vraiment être très avancées...
Si on a 10MO à crypter avec une clé XOR de la même taille vous voulez dire que ça sera "facile" malgré tout à casser pour des spécialistes ? Sachant que pour 415 octet à crypter on a du 3^999 cas à analyser par force brute.
Étonnant ! Comme je n'y connais pas plus que ça donc je veux bien le croire.

[bacelar]

128 bit c'est rien je trouve, dans le cas du XOR je veux dire.
Si la clé fait la même taille que le message.

La clé du DES c'est 56 bits, donc 128bits ce n'est pas négligeable.

LE XOR, c'est du vaporware, si l'attaquant arrive à te faire chiffrer une seule fois un texte qu'il connait, il a toute la clé en clair en au coup, quelques soir la taille de la clé (si son texte est assez long).
La taille de la clé d'un XOR, c'est pas vraiment important si vous êtes vulnérable aux attaques par textes choisis.

Et quand on cherche, on trouve toujours un moyen pour introduit une entré plus ou moins contrôlé vers le système de cryptage.

[Happpy]

Dans ce cas ci, mais si on ne force pas un cryptage d'un texte connu.
Est-ce convenable comme système de cryptage ?

[bacelar]

Ce n'est pas vous qui choisissez le type d'attaque, c'est la manière dont est utilisé votre système et sur quel type de données.

Donc dans l'absolue, votre chiffrement est plus que vulnérable.
Pour qu'il soit utile, il faut absolument mettre en place dans un périmètre très réduit et de manières très ponctuelles.

En fait, tellement ponctuel, que je ne vois pas de cadre autre que le fureteur désinvolte (mais là, pourquoi chiffrer, l'encodage binaire ferait largement l'affaire).

Je ne suis pas en spécialiste en analyse de sécurité et en profile de menace non plus.

[Happpy]

Oui j'imagine bien mais ce crypteur n'a pas de rôle particulier.
Je n'ai rien à cacher donc je ne vois pas pourquoi un hackeur chercherai personnellement à casser le message crypté.

J'ai fait ce crypteur juste pour que je me dise "ouai je peux crypter quelque chose", mais je n'ai rien à cacher.

C'est pour voir la "beauté" de l'information cryptée.
Voila

Pour un non spécialiste en informatique (la personne commune) ça serai difficile à décrypter.

[bacelar]

Je ne comprends pas l'intérêt du système, "madame Michu" elle, dés que ce n'est pas imprimable, elle est hors jeu, et pour l'ado de 12-14 un peu débrouillard cassera votre système en 5 min (et sans exagération).
Il reste qui ?

[Happpy]

Si vous le dites, je ne m'y connais pas.

Mais, comment un ado de 12-14 ans cassera-t-il le code ?

Désolé d'être pénible.

[bacelar]

Il fait chiffrer par votre système une entré qu'avec des "0", il a une empreinte de la clé.
Il fait chiffrer par votre système une entré qu'avec des "1", il a une empreinte inverse la clé.
Il remarquera rapidement qu'elles sont complémentaires donc que ce n'est qu'un simple XOR.

Le truc, c'est que ces 2 entrées sont les cas usuels de toute cryptanalyse par texte choisi.

S'il n'a pas accès à l'entré du système, il commencera à voir la clé quand il vera les textes chiffrés qui commencent très souvent pas les même séquences, et comme votre algorithme n'est pas "salé", ils seront chiffrés avec les mêmes valeurs et en fonction de la nature des données chiffrés (texte, image, vidéo, flux réseau) qui commencent toujours pareil, il trouvera le "bruit" qui correspond à la clé de chiffrement.

...

[Happpy]

Oui, mais je ne comprends pas car le message est crypté par une clé XOR de même taille où chaque caractère de cette clé est ALEATOIRE(de valeur du char entre -128 et 127).
Il ne peut donc pas avoir de similitudes car la clé XOR fait la même taille que le message à crypter et est aléatoire qui plus est ?

De plus, j'ai du le dire (je ne me rappelle pas) mais avant d'appliquer le XOR, j'applique un Cesar à CHAQUE caractère du message à crypter.
Chaque caractère à donc sa clé Cesar qui est elle aussi ALEATOIRE.
Ces clés Cesar sont indépendantes de la volonté de l'utilisateur (contrairement à la clé XOR que l'utilisateur peut entrer lui-même ou dire au programme de la générer automatiquement et aléatoirement pour qu'elle fasse la même taille que le message à crypter mais on se place ici dans le cas où l'utilisateur a choisi que la clé XOR soit aléatoire et de même taille que le message à crypter)

Une fois le cryptage effectué, toutes les clés (XOR + toutes les clés Cesar respectives de chaque caractère du fichier qui a été crypté) sont notées dans un txt qui pourra être utilisé pour décrypter le message.

Je ne comprends pas que ça soit aussi facile de décrypter ça quand même car s'il trouve le mot de passe XOR, ok, mais il n'aura pas un message décrypté claire pour autant car il faudra qu'il trouve toutes les clés Cesar (de 0 à 255) de chaque caractères une fois le XOR appliqué....

Encore un autre argument : comme je l'ai dit j'ai pensé à ce système
Admettons que le fichier à crypter fasse 10 octet, l'utilisateur peut, lors du cryptage, indiquer au crypteur de considérer que le fichier à crypter fait 3 MO (par exemple) au lieu de sa taille réelle.
A ce moment, le crypteur va considérer qu'il "rajoute" (le fichier réel n'est pas modifié) autant de caractères ESPACE que nécessaire pour que le fichier à crypter fasse les 3 MO choisis.
De là le cryptage commence, à chaque caractère il va générer une clé Cesar aléatoirement qu'il appliquera sur ce caractère, puis cryptera ce caractère par le caractère correspondant de la clé XOR générée aléatoirement et faisant 3 MO et ainsi de suite.
Finalement, on se retrouve avec un fichier crypté de 3 MO alors que le fichier d'origine fait 10 octet.
Et c'est lors du décryptage (si les clés sont correctes) que le crypteur va "retirer" tous les ESPACES qu'il avait ajouté lors du cryptage (car il va se rendre compte qu'il n'y a que des espaces à la fin du fichier obtenu, il pourra donc les retirer)
Ainsi on se retrouvera bien avec les 10 octet de départ.

(désolé si j'explique mal ma méthode de supposer que le fichier à crypter fait une taille supérieure à sa taille réelle, mais je pense que vous comprendrez)

Ainsi on le curieux pourrai avoir un fichier de 100 MO dont il devrai trouver la clé, l'information à trouver ne pourrai faire que 3 octet... Mais il devrai malgré tout trouver la clé XOR aléatoire de 100 MO et le paquet de clé Cesar de chaque caractère...

Je n'arrive pas à comprendre que ça soit si simple que ça... je dois être idiot... ?

[bacelar]

même taille

Ce n'est pas un motif répétitif dans le message crypté le problème, c'est que vous utilisez toujours la même clé 'brut". Une clé est de plus en plus vulnérable à chaque utilisation.

est aléatoire

C'est à la création (et sur un ordinateur, ce n'est pas vraiment aléatoire, c'est aussi un angle d'attaque d'ailleurs)
Après, si vous utilisez cette clé plusieurs fois, et bien votre clé est une constante.

De plus, j'ai du le dire (je ne me rappelle pas) mais avant d'appliquer le XOR, j'applique un Cesar à CHAQUE caractère du message à crypter.

C'est mieux, mais il faut bien voir que celui qui attaque n'a pas le même mode de pensé que vous. Il ne va pas chercher à dézinguer les protections une par une mais trouver un moyen pour deviner le texte en claire à partir du texte chiffré.
Intrinsèquement, la principale faiblesse du système, c'est, avec la même clé, un même caractère, au même offset du début, aura toujours le même résultat de chiffrement. L'attaquant n'a donc pas à comprendre comment le caractère A en clair donne B en crypté (via un nombre aussi grand que l'on veut d'opérations), il a juste à noter qu'à la position x du flux, si c'est A en clair, ça donne B en crypté...
Avec assez peu de texte choisi, il pourra facilement faire son dictionnaire, et décryptez tout texte crypté par la clé(qui n'a plus rien d'aléatoire, une fois générée). Les pros y arriveront avec très peu de texte car ils tenteront de détecter les corrélations (mais sans vouloir faire l'opération de décryptage), les amateurs, juste avec des textes comme "AAA" puis "BBB".

Si vous travaillez sur des octets, l'attaquant n'a besoin que de faire chiffré 255 textes pour avoir tout le dictionnaire, et cela quelque soit la taille de la clé (qui, dans votre cas peu être très longue).
Vous avez donc une très très longue clé, mais très très très très faible, car elle est cassé juste avec 255 essais (~clé d'une longueur 8bits en brute force).
Si vous travaillez sur du 16bits (pour l'addition césar), ce n'est pas beaucoup mieux, avec ~65000 possibilités.

Et sachant que l'attaquant n'a pas besoin de tout le dictionnaire pour commencer à décrypter partiellement les transmissions.

Sa "force" est constante, quelque soit sa taille, et là, c'est très très mauvais. Et encore, si le "texte" à chiffré utilise toutes les valeurs possibles. Ce qui est loin d'être courant.

Je ne comprends pas votre système de protection. A quel type de menace votre système est-il sensé servir de rempart.
Avoir, sur un système le résultat du cryptage et la "clé" dans un fichier à coté, c'est clairement pas bon.
Si c'est pour crypter la transmission, comment sécurisez-vous le transfert de la clé ?
Le fait de pouvoir supprimer arbitrairement des caractères à la fin de la transmission est très peu généralisable.
Mettre des valeurs identiques comme entré de votre cryptage va le rendre vulnérable aux attaques utilisant les statistiques car un caractère de variabilité disparait.

En résumé, toute votre analyse de sécurité ne tient que parce que vous dite que l'attaquant doit suivre votre raisonnement mais ce n'est pas le cas.

En ajoutant un état dans votre algorithme par exemple, cela complexifie bien plus la tâche de l'attaquant.
Un exemple : appliqué un XOR différent (même constant) si la somme des bits à 1 des X derniers octets cryptés est égale ou supérieur à une constante. Et si votre algorithme génère "aléatoirement" les X premiers octets. L'attaquant au texte choisi, il a bien plus de mal à faire sa besogne.

La force d'un algorithme n'est pas dans le secret ni dans la complexité des opérations mais dans son entropie du résultat.

[Happpy]

Quand j'ai parlé de clé XOR et César aléatoires, je n'ai pas du tout dit qu'une clé est générée aléatoirement et que c'est la même qui est utilisée à chaque fois.

A CHAQUE cryptage une clé est générée aléatoirement.
La clé CHANGE à chaque cryptage, que ça soit pour le XOR que pour le Cesar.
Ce n'est jamais la même.

Cela implique que si on crypte le même message X fois de suite, on n'obtiendra pas le même message chiffré.

Ensuite, pour transmission de la clé, comme je l'ai dit, c'est un crypteur pour moi tout seul donc je n'aurai pas à transmettre de fichier crypté et donc pas à transmettre de clé.
C'est pour mon utilité personnelle, pour m'amuser surtout car je n'ai rien à cacher.
C'est peut-être idiot de faire un système de chiffrement pour soit-même mais bon, je fais ça juste pour m'amuser un peu et voir que j'ai pu faire un truc d'assez bien

Consternant mon idée d'ajouter des espaces... il semblerai que ça sera inutile.
Je ne vais donc pas l'implémenter, ça me facilitera la tâche.


Par contre, ton idée d'appliquer un second XOR en testant la somme des bit des X derniers caractères du message m’intéresse.
Comment faire pour avoir accès à la valeur des bits d'un caractère ?

[bacelar]

Votre périmètre d'utilisation me laisse perplexe.
Si vous utilisez une clé à usage unique, une simple grille de Vigenère
(http://fr.wikipedia.org/wiki/Chiffre_de_Vigen%C3%A8re) est largement suffisant.

Vous avez simplement une énorme faiblesse, c'est que cette clé à usage unique est intransmettable et que vous en avez absolument besoin pour décrypter, il faut donc quel soit sur votre disque, et en claire.

Des programme aussi inoffensifs que process explorer permettent d'avoir la liste des fichiers ouverts par un programme donc d'identifier le conteneur de la clé, si c'est le programme qui décide de quel clé utilisée. Si c'est à l'utilisateur de donner la clé, c'est lourd, pas pratique (l'utilisateur en aura marre et utilisera toujours la même clé) et l'attaquant n'aura qu'à scanner votre disque pour avoir un nombre de clé possible très réduit.

Vous tentez de vous protégez de quoi comme menace là ?

Par contre, ton idée d'appliquer un second XOR en testant la somme des bit des X derniers caractères du message m’intéresse.
Comment faire pour avoir accès à la valeur des bits d'un caractère ?

Houlà, c'est le genre de question qui fait peur, venant d'un adepte du secret informatique.
Avec de simples opérateurs binaire "&","|"...

[Happpy]

D'accord merci pour ces réponses.

Je répète que je ne me protège de rien, je fais ça juste pour m'amuser et code un peu rien de plus.