Bonjour,
Je génère des données dans un fichier texte.
Je voudrais savoir comment crypter et décryper ces données en C++ quand je génère le fichier texte ?
Merci,
Christophe
Version imprimable
Bonjour,
Je génère des données dans un fichier texte.
Je voudrais savoir comment crypter et décryper ces données en C++ quand je génère le fichier texte ?
Merci,
Christophe
Bonjour
Déjà on ne dit pas "crypter" mais "chiffrer". Il y a le verbe "chiffrer" (transformer un texte clair en texte inintelligible via une clef), le verbe "déchiffrer" (opération inverse) et le verbe "décrypter" (technologie d'attaque qui permet de retrouver le message d'origine sans avoir la clef). Mais comme ce dernier verbe n'accepte pas d'antonyme (on ne peut pas chiffrer un message sans avoir de clef) le verbe "crypter" ne peut pas s'employer.
Sinon ben il existe divers algorithmes. Depuis le chiffre de César (décaler les lettres de "n" positions) jusqu'à RSA (chiffrer sur une clef publique asymétrique ce qui donne un texte ne pouvant être déchiffré que depuis la clef privée). Tout dépend donc du but à atteindre.
En C/C++, un des trucs de bases est de passer par le XOR. En effet, si CLAIR xor CHIFFRE = SECRET alors SECRET xor CHIFFRE = CLAIR (et CLAIR xor SECRET = CHIFFRE).
Il existe un bon article d'introduction à la crypographie sur Developpez : http://ram-0000.developpez.com/tutoriels/cryptographie/. La section 2 est d'ailleurs consacré à des rappels terminologiques similaires à ceux de Sve@r ^^
Pour savoir quelle technique de chiffrement utiliser, il faut savoir ce que tu souhaites obtenir : quelque chose qu'un mec lambda ne comprendra pas avec notepad, quelque chose d'un peu plus sécurisé mais pas forcément inviolable, quelque chose d'inviolable (à savoir si cela existe vraiment).
Ca existe. C'est le "one time pad" de Gilbert Vernam. Il s'agit de chiffrer un message via un simple Vigenère mais avec une clef totalement aléatoire aussi longue que le message à chiffrer, clef qu'on jette après usage. Avec une clef de ce type, on ne peut plus découper le texte chiffré polyalphabétique en "n" textes monoalphabétiques qui offriraient ensuite des points d'appui au travers de l'analyse des fréquences.Citation:
Envoyé par Bktero
Mais tout autant ce système est totalement inviolable, tout autant il ne pourra jamais être employé à grande échelle. Déjà sur la façon d'obtenir le "totalement aléatoire" et ensuite vu qu'il serait tout aussi difficile de faire passer la clef que le message d'origine. Toutefois ça existe déjà dans certains systèmes comme le téléphone rouge entre Washington et Moscou qui utilise une technologie basée sur ce principe (un même trousseau de clefs déposé d'un côté et de l'autre et à chaque appel la clef utilisée disparait)...
Ce qui me hérisse le poil, c'est que cette terminologie, si stricte soit-elle, n'a pas de sens étymologiquement parlant (Edit: et intuitivement non plus, d'ailleurs). Car la notion de dissimulation, elle est dans la racine grèque κρυπτ (crypt), et non pas dans le mot "chiffre"...Citation:
Envoyé par Sve@r
Si je remplace "bonjour" par 98 111 110 106 111 117 114, j'ai remplacé par des chiffres et pourtant ce n'est pas un "chiffrement"...
Non, c'est un "cryptage" des données :) Le verbe "crypter" reste marqué comme étant un néologisme dans le Larousse même si j'avoue l'utiliser régulièrement, de même que "encrypter" ou "encryption"...
Enfin... On pinaille et ça ne fait pas avancer la résolution du problème de cjacquel :aie:
L'exemple d'école de "chiffrement":roll: à clé, c'est le XOR.
Ça tombe bien, car à moins de prendre des précautions spéciales, c'est l’algorithme celui qui met en évidence le plus facilement (et fiablement) un problème inhérent au chiffrement en C: le résultat d'un chiffrement qui agit directement sur les octets du message (plutôt qu'agir sur le texte lui-même, comme le bon vieux chiffre de César) entre deux "chaînes de caractères C" n'est plus une "chaîne de caractères C" mais un tableau d'octets bruts: En effet, il peut contenir des octets nuls, des caractères non-imprimables ou des séquences invalides dans l'encodage utilisé.
Conclusion: À moins d'utiliser un chiffrement basé sur la manipulation du texte, le résultat du chiffrement n'est plus du texte (du moins, jusqu'à ce qu'il soit déchiffré). Il faut toujours garder ça en tête, et être prêt:
- soit à stocker les données sous une forme autre que du texte (fichier binaire)
- soit à convertir les données brutes obtenues vers un format texte permettant de les exprimer (séquences d'échappement, hexadécimal, base64...)
Edit: Au passage, à propos de cet article, je dois dire que je n'ai jamais vu "Alice and Bernard" en Anglais, je pense qu'il y a une petite erreur dans ce tableau.
Pour moi si. Parce que ce texte sera imbittable pour qui ne possède pas la clef de déchiffrement (le code ASCII).Citation:
Envoyé par Médinoc
Et pour la terminologie, quand j'étais ado je lisais des livres des aventures d'un agent secret nommé "Langelot" (créé en 1962 par Vladimir Volkoff, un authentique espion qui prenait le pseudo "Lieutenant X" pour ses bouquins). Ben dans ses livres, chaque fois que le héro devait transmettre un message, il employait le verbe "chiffrer" (et parfois "surchiffrer" pour indiquer qu'il le faisait deux fois parce que là c'était vraiment sérieux). Et ce terme était donc déjà employé ainsi à cette époque bien avant les premiers ordinateurs de bureau (et même avant que Diffie, Hellman et Merckle aient trouvé leur algo en 1976 !!!).
Quant à cjacquel, ben s'il veut que son problème avance il serait bien qu'il s'investisse un peu dans son topic quoi...
En l'occurence, chiffrer ne signifie pas "traduire en chiffres" mais "appliquer un chiffre", qui est un algorithme réversible de transformation de texte.
le chiffrement est le nom de cette opération.
Et la différence entre déchiffrement et décryptage, c'est le fait d'avoir ou non les connaissances du chiffre: la méthode et ses paramètres.