Discussion :

[Happpy]

Bonjour tout le monde, j'ai implémenté un chiffreur XOR en C++ pour m'amuser et il fonctionne bien, avec générateur de clé "aléatoires" avec un RAND de façon à ce que cette clé fasse la même taille que le message à chiffrer.

Mais j'ai pensé à autre chose.
On a un fichier entré qu'on veut chiffrer.
L'utilisateur crée un fichier qui va en faite représenter le fichier d'entré chiffré.
Dans ce fichier il met ce qu'il veut, par exemple : "ceanqoidO?CUcn FNIZONVR 515V15RV 51RCZ1ACARDC XEFAc raze5c1xd 0v5rz15..."

Alors soit X un caractère du fichier d'entré
soit Y le caractère correspondant du fichier de sortie
soit Z le caractère correspondant de la clé de chiffrement

Le chiffreur va chercher Z de façon à ce que X XOR Z = Y
Il faudra donc tester au plus les 256 possibilités de la table ASCII étendu.

Je pense en faite que l'aspect "aléatoire" de la clé est plus net car c'est l'utilisateur lui-même qui tape son fichier de sortie, ce qui est aléatoire car il n'a même pas besoin de regarder le clavier pour cela.
Logiquement, la clé obtenue sera elle aussi "aléatoire".

Evidemment, on aura toujours une clé de la même taille que le message à chiffrer.
Si le message à obtenir (que l'utilisateur à tapé sans regarder le clavier) est plus petit que le message à chiffrer, on va considérer que le message tappé par l'utilisateur à autant d'espace que nécessaire (à la fin) pour qu'il ait la même taille que le message à chiffrer.
Réciproquement, s'il est trop long, on ne considérera que le nombre de caractère égal à la taille du message à chiffrer


Que pensez-vous de cela ?
Je rappelle que je n'ai pas de notions particulière en cryptographie, c'est juste pour m'amuser
Est-ce correcte au niveau de la complexité temporelle ?
Discutons ^^


Merci d'avance.

[Médinoc]

En gros, c'est un one-time pad.
Son unique problème, c'est que maintenant tu as une clé de la même taille que ton fichier, et que tu dois également transporter de manière sécurisée.

Donc en gros, tu n'as fait que déplacer le problème, sans même entamer sa résolution.

Pour être viable, un one-time pad est généralement énorme et préparé à l'avance: On le transmet d'avance sur un support physique (par exemple sur clé USB ou DD externe, en rendant personnellement visite à ton correspondant), en le jetant s'il y a un soupçon de chance qu'il soit compromis.
Ensuite, il n'y a plus qu'à l'utiliser octet par octet, en mémorisant où on s'était arrêté lors du dernier message.

Avec un OTP de plusieurs GO, tu peux échanger de nombreuses données avant de devoir transmettre une nouvelle clé.

PS: Normalement pour générer la clé, on utilise un Générateur pseudo-aléatoire de qualité cryptographique qui prend diverses informations non-prévisibles en entrée ("bruits" électroniques, mouvements de souris, etc.) pour éviter d'être "cassé" (prédit)

[Happpy]

Waw, j'ai oublié de préciser, les questions de transmission de clé ou autre on ne S'EN OCCUPE PAS.
Je ne suis pas un professionnel, je veux juste coder pour m'amuser.


Ah d'accord, dans ce cas ma méthode n'est pas correcte ?
Alors le générateur pseudo-aléatoire est vraiment "incassable" ?


Il y a-t-il une librairie particulière pour le C++ ?

[Médinoc]

J'ignore s'il y a une bibliothèque particulière, mais je sais que:

• Sous *n*x, tu peut avoir des octets aléatoires de qualité cryptographique en lisant le flux /dev/random
• Sous Windows, tu peux utiliser RtlGenRandom pour ça.

À ma connaissance, avec la technologie actuelle, une source aléatoire matérielle est "suffisamment" imprévisible, donc incassable: On n'arrive pas à déterminer et reproduire l'état complet de la machine qui génère les données aléatoires.

Et en tout cas, un one-time pad est absolument incassable (enfin, "aussi sûr que sa clé") vu que la clé n'a pas de répétition.