CHIFFREMENT XOR PLUS ROBUSTE
NHenry
Messages postés
15113
Date d'inscription
vendredi 14 mars 2003
Statut
Modérateur
Dernière intervention
22 avril 2024
-
26 août 2011 à 12:45
The Meteorologist Messages postés 232 Date d'inscription jeudi 18 janvier 2007 Statut Membre Dernière intervention 3 novembre 2011 - 30 août 2011 à 15:57
The Meteorologist Messages postés 232 Date d'inscription jeudi 18 janvier 2007 Statut Membre Dernière intervention 3 novembre 2011 - 30 août 2011 à 15:57
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/53512-chiffrement-xor-plus-robuste
https://codes-sources.commentcamarche.net/source/53512-chiffrement-xor-plus-robuste
30 août 2011 à 15:57
Lorsqu'on demande un nombre aléatoire au générateur, il effectue une opération mathématique sur la graine afin de la rendre "aléatoire". Mais cette opération mathématique est réversible ! Autrement dit, on est en mesure de retrouver la graine si on connait le premier nombre pseudo-aléatoire généré.
Donc prenons un exemple :
Ton algorithme chiffres un fichier avec une en-tête (un fichier .exe par exemple). Les 6 premiers octets d'un fichier .exe sont totalement prévisibles ("MZ" + Poids mod 512 + Poids/512). On connait donc les modifications effectuées sur les 4 premiers octets. Etant donné que tu utilises un seul et unique entier 32 bits comme clé, on est ensuite capable de retrouver la clé originale et donc de décrypter la totalité du fichier !
Simon
29 août 2011 à 16:19
Oui, mais mon propos était d'ordre tout autre. Une simple idée que j'ai voulu mettre en application sans plus. Peut-être que j'aurais dû le préciser dans ma présentation.
Merci de votre attention.
Remarque: une faille de sécurité a très récemment été mise en évidence dans AES (je vais rechercher ma source ...)
29 août 2011 à 14:41
A la moindre évolution de technologie, que ce soit au niveau des prérequis logiciel, ou du système d'exploitation et pourquoi pas même au niveau matériel dont le processeur, il existe un risque non négligeable qu'il soit impossible un jour de pouvoir décrypter, et ainsi perdre toutes les données cryptées.
Autant utiliser les classes de cryptages AES Rijndael réputées solides.
26 août 2011 à 20:20
Didier HEROUX
26 août 2011 à 18:37
Enfin, bon, voilà.
26 août 2011 à 15:28
Merci pour ces conseils.
Toutefois, lors de votre première remarque à savoir: Sache que M$ ne garanti pas .... etc... je voudrais simplement faire remarquer que la variable 'Germe' peut prendre n'importe quelle valeur autre que NumericUpDown1.value (donc l'algorithme de génération des nombres aléatoires importe peu s'il était modifié)
L'essentiel est que cette valeur soit identique dans le chiffrement et le déchiffrement.
Bonne fin de journée
26 août 2011 à 12:45
A la place d'utiliser Rnd, regardes la classe Random.
Sache que M$ ne garanti pas que l'algorithme de génération des nombre aléatoire soit le même tout le temps, donc risque que le décryptage ne fonctionne plus après une mise à jour.
Je te conseil plutôt de travailler sur le tableau d'octet extrait de la chaine source pour permettre de crypter autre chose que du texte.
L'idéal serait que tu fasse un module à part, pour faciliter la réutilisabilité de ton code.
Concernant le code :
MessageBox.Show(Err.Description, "", MessageBoxButtons.OK, MessageBoxIcon.Error)
On n'utilise pas Err dans un code VB.NET, mais l'exception retournée.
A la place de mettre seulement :
Catch
Mets :
Catch ex as Exception
Dim Germe As Integer = NumericUpDown1.Value
Je pense que Option Strict n'est pas activé, pense à le faire.
Evite de conserver les noms par défaut de tes contrôles, ça ne facilite pas la relecture du code.
Button1 est moins clair que BtnDecrypt par exemple.