Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Patrick Coilland
a écrit dans le message de news: 418e8b23$0$284$
Bonjour. Si je fais un codage avec l'opération XOR sur 128 bits, cela est -il facile de trouver le code ?
On utilise le XOR pour remplacer une donnée A par A XOR B où B est un "mot de passe". L'avantage est la simplicité du "codage" et évidemment du "décodage" puisque A = (A XOR B) XOR B.
Cependant, on a aussi (A XOR B) XOR A = B. Donc, si une partie du texte A est a priori connue, il suffit de faire l'opération indiquée pour retrouver une partie de la "clé" B.
Exemple (réel): Dans un équipement réseau, les mots de passe (16c max) étaient stockés en mémoire (protection des DUMP) "protégés" par un XOR avec un mot secret du constructeur. Comme beaucoup de mots de passe font moins de 16c, voire parfois moins de 6, il y a en général un grand nombre d'espaces à la fin des mots de passe. En faisant alors un XOR de la zone stockée avec 16 espaces ASCII, on trouve la fin (pouvant aller jusqu'à 10 caractères) du mot secret constructeur, et il est alors souvent facile d'en déduire la totalité.
Le XOR pour "protéger" une donnée n'a un soupçon de sens que si celle-ci ne présente pas de structure connue, ou de zones connues à emplacements fixes..
Le XOR n'est en général pas admis comme concept cryptographique. Ou alors, la solidité doit être dans la clé : celle-ci doit être très longue, voire dynamique. c'était le choix qui avait été fait dans le chiffrement WEP utilisé en WIFI : usage du XOR car simple à implémenter, mais clé longue (ce que l'on appelle la clé WEP n'étant en fait que la racine permettant de générer une clé plus longue). La faiblesse du XOR était théoriquement compensée par la génération de la clé. Dans la pratique, bien sûr, cette génération n'était pas fiable.
<huchette.andre@numericable.fr> a écrit dans le message de news:
418e8b23$0$284$a3f2974a@nnrp1.numericable.fr...
Bonjour.
Si je fais un codage avec l'opération XOR sur 128 bits,
cela est -il facile de trouver le code ?
On utilise le XOR pour remplacer une donnée A par A XOR B où B est un "mot
de passe".
L'avantage est la simplicité du "codage" et évidemment du "décodage" puisque
A = (A XOR B) XOR B.
Cependant, on a aussi (A XOR B) XOR A = B.
Donc, si une partie du texte A est a priori connue, il suffit de faire
l'opération indiquée pour retrouver une partie de la "clé" B.
Exemple (réel):
Dans un équipement réseau, les mots de passe (16c max) étaient stockés en
mémoire (protection des DUMP) "protégés" par un XOR avec un mot secret du
constructeur.
Comme beaucoup de mots de passe font moins de 16c, voire parfois moins de
6, il y a en général un grand nombre d'espaces à la fin des mots de passe.
En faisant alors un XOR de la zone stockée avec 16 espaces ASCII, on trouve
la fin (pouvant aller jusqu'à 10 caractères) du mot secret constructeur, et
il est alors souvent facile d'en déduire la totalité.
Le XOR pour "protéger" une donnée n'a un soupçon de sens que si celle-ci ne
présente pas de structure connue, ou de zones connues à emplacements fixes..
Le XOR n'est en général pas admis comme concept cryptographique. Ou alors,
la solidité doit être dans la clé : celle-ci doit être très longue, voire
dynamique. c'était le choix qui avait été fait dans le chiffrement WEP
utilisé en WIFI : usage du XOR car simple à implémenter, mais clé longue (ce
que l'on appelle la clé WEP n'étant en fait que la racine permettant de
générer une clé plus longue). La faiblesse du XOR était théoriquement
compensée par la génération de la clé. Dans la pratique, bien sûr, cette
génération n'était pas fiable.
Bonjour. Si je fais un codage avec l'opération XOR sur 128 bits, cela est -il facile de trouver le code ?
On utilise le XOR pour remplacer une donnée A par A XOR B où B est un "mot de passe". L'avantage est la simplicité du "codage" et évidemment du "décodage" puisque A = (A XOR B) XOR B.
Cependant, on a aussi (A XOR B) XOR A = B. Donc, si une partie du texte A est a priori connue, il suffit de faire l'opération indiquée pour retrouver une partie de la "clé" B.
Exemple (réel): Dans un équipement réseau, les mots de passe (16c max) étaient stockés en mémoire (protection des DUMP) "protégés" par un XOR avec un mot secret du constructeur. Comme beaucoup de mots de passe font moins de 16c, voire parfois moins de 6, il y a en général un grand nombre d'espaces à la fin des mots de passe. En faisant alors un XOR de la zone stockée avec 16 espaces ASCII, on trouve la fin (pouvant aller jusqu'à 10 caractères) du mot secret constructeur, et il est alors souvent facile d'en déduire la totalité.
Le XOR pour "protéger" une donnée n'a un soupçon de sens que si celle-ci ne présente pas de structure connue, ou de zones connues à emplacements fixes..
Le XOR n'est en général pas admis comme concept cryptographique. Ou alors, la solidité doit être dans la clé : celle-ci doit être très longue, voire dynamique. c'était le choix qui avait été fait dans le chiffrement WEP utilisé en WIFI : usage du XOR car simple à implémenter, mais clé longue (ce que l'on appelle la clé WEP n'étant en fait que la racine permettant de générer une clé plus longue). La faiblesse du XOR était théoriquement compensée par la génération de la clé. Dans la pratique, bien sûr, cette génération n'était pas fiable.
chaton
wrote in message news:<418e8b23$0$284$...
Bonjour. Si je fais un codage avec l'opération XOR sur 128 bits, cela est -il facile de trouver le code ?
Ta question est beaucoup trop vague, donc je vais te donner une réponse bateau: "tout dépends du contexte".
Les caractéristiques de xor semblent parfaites pour la cryptographie, mais elles sont également parfaites pour la cryptanalyse. Il faut garder à l'esprit que xor est un opérateur et donc qu'il doit être _intégré_ dans un méchanisme de chiffrement et non pas utilisé _comme_ méchanisme de chiffrement.
Si tu utilises une clef aléatoire de 128 bits et qu'elle n'est utilisée qu'une fois, il ne sera pas possible de trouver le message à partir de l'équivalent chiffré (ou plutot, il sera éventuellement possible de le trouver, mais pas de déterminer si c'est le bon), c'est le principe du masque jetable. Cependant, la sécurité ici n'est pas du tout liée au xor, mais au contexte (les contraintes de la clef).
Dans tous les autres cas, il pourra être difficile de trouver le message mais ce sera toujours faisable, et plus tu chiffreras de message avec la même clef, plus tu donneras d'informations directement utilisables grace aux propriétés du xor.
<huchette.andre@numericable.fr> wrote in message news:<418e8b23$0$284$a3f2974a@nnrp1.numericable.fr>...
Bonjour.
Si je fais un codage avec l'opération XOR sur 128 bits,
cela est -il facile de trouver le code ?
Ta question est beaucoup trop vague, donc je vais te donner une
réponse bateau:
"tout dépends du contexte".
Les caractéristiques de xor semblent parfaites pour la cryptographie,
mais elles sont également parfaites pour la cryptanalyse. Il faut
garder à l'esprit que xor est un opérateur et donc qu'il doit être
_intégré_ dans un méchanisme de chiffrement et non pas utilisé _comme_
méchanisme de chiffrement.
Si tu utilises une clef aléatoire de 128 bits et qu'elle n'est
utilisée qu'une fois, il ne sera pas possible de trouver le message à
partir de l'équivalent chiffré (ou plutot, il sera éventuellement
possible de le trouver, mais pas de déterminer si c'est le bon), c'est
le principe du masque jetable. Cependant, la sécurité ici n'est pas du
tout liée au xor, mais au contexte (les contraintes de la clef).
Dans tous les autres cas, il pourra être difficile de trouver le
message mais ce sera toujours faisable, et plus tu chiffreras de
message avec la même clef, plus tu donneras d'informations directement
utilisables grace aux propriétés du xor.
Bonjour. Si je fais un codage avec l'opération XOR sur 128 bits, cela est -il facile de trouver le code ?
Ta question est beaucoup trop vague, donc je vais te donner une réponse bateau: "tout dépends du contexte".
Les caractéristiques de xor semblent parfaites pour la cryptographie, mais elles sont également parfaites pour la cryptanalyse. Il faut garder à l'esprit que xor est un opérateur et donc qu'il doit être _intégré_ dans un méchanisme de chiffrement et non pas utilisé _comme_ méchanisme de chiffrement.
Si tu utilises une clef aléatoire de 128 bits et qu'elle n'est utilisée qu'une fois, il ne sera pas possible de trouver le message à partir de l'équivalent chiffré (ou plutot, il sera éventuellement possible de le trouver, mais pas de déterminer si c'est le bon), c'est le principe du masque jetable. Cependant, la sécurité ici n'est pas du tout liée au xor, mais au contexte (les contraintes de la clef).
Dans tous les autres cas, il pourra être difficile de trouver le message mais ce sera toujours faisable, et plus tu chiffreras de message avec la même clef, plus tu donneras d'informations directement utilisables grace aux propriétés du xor.
Merci pour la réponse.... Je retiens : si on code un fichier WORD, son ascii contient environ 2 Ko toujours identique. Un EXE commence par MZ, un GIF a les octets GIF + 2 chiffres .... Un ZIP commence par PK , on trouve la taille du fichier, le mode de codage...
En fait, il suffit de rechercher un "header" pour déduire la clé.
Un texte pour ne contient que de l'ascii compris entre 30h et 7Ah 30= Zero 7A = lettre Z minuscule, sauf erreur.
Si je fais plusieurs codages successifs .... ca marche ? "Patrick Coilland" a écrit dans le message news: 418f1737$0$18870$
a écrit dans le message de news: 418e8b23$0$284$
Bonjour. Si je fais un codage avec l'opération XOR sur 128 bits, cela est -il facile de trouver le code ?
On utilise le XOR pour remplacer une donnée A par A XOR B où B est un "mot de passe". L'avantage est la simplicité du "codage" et évidemment du "décodage" puisque
A = (A XOR B) XOR B.
Cependant, on a aussi (A XOR B) XOR A = B. Donc, si une partie du texte A est a priori connue, il suffit de faire l'opération indiquée pour retrouver une partie de la "clé" B.
Exemple (réel): Dans un équipement réseau, les mots de passe (16c max) étaient stockés en
mémoire (protection des DUMP) "protégés" par un XOR avec un mot secret du constructeur. Comme beaucoup de mots de passe font moins de 16c, voire parfois moins de 6, il y a en général un grand nombre d'espaces à la fin des mots de passe. En faisant alors un XOR de la zone stockée avec 16 espaces ASCII, on trouve
la fin (pouvant aller jusqu'à 10 caractères) du mot secret constructeur, et
il est alors souvent facile d'en déduire la totalité.
Le XOR pour "protéger" une donnée n'a un soupçon de sens que si celle-ci ne
présente pas de structure connue, ou de zones connues à emplacements fixes..
Le XOR n'est en général pas admis comme concept cryptographique. Ou alors, la solidité doit être dans la clé : celle-ci doit être très longue, voire dynamique. c'était le choix qui avait été fait dans le chiffrement WEP utilisé en WIFI : usage du XOR car simple à implémenter, mais clé longue (ce
que l'on appelle la clé WEP n'étant en fait que la racine permettant de générer une clé plus longue). La faiblesse du XOR était théoriquement compensée par la génération de la clé. Dans la pratique, bien sûr, cette génération n'était pas fiable.
Merci pour la réponse....
Je retiens : si on code un fichier WORD, son ascii contient environ 2 Ko
toujours identique.
Un EXE commence par MZ, un GIF a les octets GIF + 2 chiffres ....
Un ZIP commence par PK , on trouve la taille du fichier, le mode de
codage...
En fait, il suffit de rechercher un "header" pour déduire la clé.
Un texte pour ne contient que de l'ascii compris entre 30h et 7Ah 30= Zero
7A = lettre Z minuscule, sauf erreur.
Si je fais plusieurs codages successifs .... ca marche ?
"Patrick Coilland" <pcoilland@pcc.fr> a écrit dans le message news:
418f1737$0$18870$8fcfb975@news.wanadoo.fr...
<huchette.andre@numericable.fr> a écrit dans le message de news:
418e8b23$0$284$a3f2974a@nnrp1.numericable.fr...
Bonjour.
Si je fais un codage avec l'opération XOR sur 128 bits,
cela est -il facile de trouver le code ?
On utilise le XOR pour remplacer une donnée A par A XOR B où B est un "mot
de passe".
L'avantage est la simplicité du "codage" et évidemment du "décodage"
puisque
A = (A XOR B) XOR B.
Cependant, on a aussi (A XOR B) XOR A = B.
Donc, si une partie du texte A est a priori connue, il suffit de faire
l'opération indiquée pour retrouver une partie de la "clé" B.
Exemple (réel):
Dans un équipement réseau, les mots de passe (16c max) étaient stockés
en
mémoire (protection des DUMP) "protégés" par un XOR avec un mot secret du
constructeur.
Comme beaucoup de mots de passe font moins de 16c, voire parfois moins de
6, il y a en général un grand nombre d'espaces à la fin des mots de passe.
En faisant alors un XOR de la zone stockée avec 16 espaces ASCII, on
trouve
la fin (pouvant aller jusqu'à 10 caractères) du mot secret constructeur,
et
il est alors souvent facile d'en déduire la totalité.
Le XOR pour "protéger" une donnée n'a un soupçon de sens que si celle-ci
ne
présente pas de structure connue, ou de zones connues à emplacements
fixes..
Le XOR n'est en général pas admis comme concept cryptographique. Ou alors,
la solidité doit être dans la clé : celle-ci doit être très longue, voire
dynamique. c'était le choix qui avait été fait dans le chiffrement WEP
utilisé en WIFI : usage du XOR car simple à implémenter, mais clé longue
(ce
que l'on appelle la clé WEP n'étant en fait que la racine permettant de
générer une clé plus longue). La faiblesse du XOR était théoriquement
compensée par la génération de la clé. Dans la pratique, bien sûr, cette
génération n'était pas fiable.
Merci pour la réponse.... Je retiens : si on code un fichier WORD, son ascii contient environ 2 Ko toujours identique. Un EXE commence par MZ, un GIF a les octets GIF + 2 chiffres .... Un ZIP commence par PK , on trouve la taille du fichier, le mode de codage...
En fait, il suffit de rechercher un "header" pour déduire la clé.
Un texte pour ne contient que de l'ascii compris entre 30h et 7Ah 30= Zero 7A = lettre Z minuscule, sauf erreur.
Si je fais plusieurs codages successifs .... ca marche ? "Patrick Coilland" a écrit dans le message news: 418f1737$0$18870$
a écrit dans le message de news: 418e8b23$0$284$
Bonjour. Si je fais un codage avec l'opération XOR sur 128 bits, cela est -il facile de trouver le code ?
On utilise le XOR pour remplacer une donnée A par A XOR B où B est un "mot de passe". L'avantage est la simplicité du "codage" et évidemment du "décodage" puisque
A = (A XOR B) XOR B.
Cependant, on a aussi (A XOR B) XOR A = B. Donc, si une partie du texte A est a priori connue, il suffit de faire l'opération indiquée pour retrouver une partie de la "clé" B.
Exemple (réel): Dans un équipement réseau, les mots de passe (16c max) étaient stockés en
mémoire (protection des DUMP) "protégés" par un XOR avec un mot secret du constructeur. Comme beaucoup de mots de passe font moins de 16c, voire parfois moins de 6, il y a en général un grand nombre d'espaces à la fin des mots de passe. En faisant alors un XOR de la zone stockée avec 16 espaces ASCII, on trouve
la fin (pouvant aller jusqu'à 10 caractères) du mot secret constructeur, et
il est alors souvent facile d'en déduire la totalité.
Le XOR pour "protéger" une donnée n'a un soupçon de sens que si celle-ci ne
présente pas de structure connue, ou de zones connues à emplacements fixes..
Le XOR n'est en général pas admis comme concept cryptographique. Ou alors, la solidité doit être dans la clé : celle-ci doit être très longue, voire dynamique. c'était le choix qui avait été fait dans le chiffrement WEP utilisé en WIFI : usage du XOR car simple à implémenter, mais clé longue (ce
que l'on appelle la clé WEP n'étant en fait que la racine permettant de générer une clé plus longue). La faiblesse du XOR était théoriquement compensée par la génération de la clé. Dans la pratique, bien sûr, cette génération n'était pas fiable.
Patrick 'Zener' Brunet
Bonjour.
a écrit dans le message de news: 418e8b23$0$284$
Bonjour. Si je fais un codage avec l'opération XOR sur 128 bits, cela est -il facile de trouver le code ?
Suite aux autres réponses, on peut facilement le voir ainsi :
Chaque bit du chiffré constitue une équation à deux inconnues :
Bchiffré = Bclair xor Bclé
Cette équation est inconditionnellement insoluble si (principe du chiffrement de Vernam) : - Bclair n'est pas déjà connu ou devinable - le même Bclé n'est pas réutilisé ailleurs du fait de la réapplication de la même clé à un autre message ou dans le même message, fournissant ainsi une seconde équation qui permet d'éliminer Bclé et de faire des déductions sur Bclair et Bclair'. On en déduit alors le Bclé et de proche en proche on reconstitue le tout. C'est la cryptanalyse.
Donc avec 128 bits : - la clé doit être non devinable (aléatoire pour chacun des 128 bits) - on ne doit rien savoir de manière certaine sur le contenu du clair (éléments de format fixes) - le clair doit mesurer exactement 128 bits (bourrer au besoin avec des bits aléatoires) - la clé ne doit servir qu'une fois Dans ces conditions, c'est définitivement incassable. Mais le problème est reporté sur la clé qui est aussi encombrante que le message. Avec un petit avantage : si la clé est compromise durant son transfert et qu'on s'en rend compte, alors on peut réessayer avec une autre clé et le message n'a pas été éventé. Tout le problème est donc de s'en rendre compte.
Cordialement,
--
/************************************************************** * Patrick BRUNET @ ZenerTopia * E-mail: lien sur http://zener131.free.fr/ContactMe **************************************************************/ <8#--X--< filtré par Avast! 4 Home
Bonjour.
<huchette.andre@numericable.fr> a écrit dans le message de news:
418e8b23$0$284$a3f2974a@nnrp1.numericable.fr...
Bonjour.
Si je fais un codage avec l'opération XOR sur 128 bits,
cela est -il facile de trouver le code ?
Suite aux autres réponses, on peut facilement le voir ainsi :
Chaque bit du chiffré constitue une équation à deux inconnues :
Bchiffré = Bclair xor Bclé
Cette équation est inconditionnellement insoluble si (principe du
chiffrement de Vernam) :
- Bclair n'est pas déjà connu ou devinable
- le même Bclé n'est pas réutilisé ailleurs du fait de la réapplication de
la même clé à un autre message ou dans le même message, fournissant ainsi
une seconde équation qui permet d'éliminer Bclé et de faire des déductions
sur Bclair et Bclair'. On en déduit alors le Bclé et de proche en proche on
reconstitue le tout. C'est la cryptanalyse.
Donc avec 128 bits :
- la clé doit être non devinable (aléatoire pour chacun des 128 bits)
- on ne doit rien savoir de manière certaine sur le contenu du clair
(éléments de format fixes)
- le clair doit mesurer exactement 128 bits (bourrer au besoin avec des bits
aléatoires)
- la clé ne doit servir qu'une fois
Dans ces conditions, c'est définitivement incassable. Mais le problème est
reporté sur la clé qui est aussi encombrante que le message. Avec un petit
avantage : si la clé est compromise durant son transfert et qu'on s'en rend
compte, alors on peut réessayer avec une autre clé et le message n'a pas été
éventé. Tout le problème est donc de s'en rendre compte.
Cordialement,
--
/**************************************************************
* Patrick BRUNET @ ZenerTopia
* E-mail: lien sur http://zener131.free.fr/ContactMe
**************************************************************/
<8#--X--< filtré par Avast! 4 Home
Bonjour. Si je fais un codage avec l'opération XOR sur 128 bits, cela est -il facile de trouver le code ?
Suite aux autres réponses, on peut facilement le voir ainsi :
Chaque bit du chiffré constitue une équation à deux inconnues :
Bchiffré = Bclair xor Bclé
Cette équation est inconditionnellement insoluble si (principe du chiffrement de Vernam) : - Bclair n'est pas déjà connu ou devinable - le même Bclé n'est pas réutilisé ailleurs du fait de la réapplication de la même clé à un autre message ou dans le même message, fournissant ainsi une seconde équation qui permet d'éliminer Bclé et de faire des déductions sur Bclair et Bclair'. On en déduit alors le Bclé et de proche en proche on reconstitue le tout. C'est la cryptanalyse.
Donc avec 128 bits : - la clé doit être non devinable (aléatoire pour chacun des 128 bits) - on ne doit rien savoir de manière certaine sur le contenu du clair (éléments de format fixes) - le clair doit mesurer exactement 128 bits (bourrer au besoin avec des bits aléatoires) - la clé ne doit servir qu'une fois Dans ces conditions, c'est définitivement incassable. Mais le problème est reporté sur la clé qui est aussi encombrante que le message. Avec un petit avantage : si la clé est compromise durant son transfert et qu'on s'en rend compte, alors on peut réessayer avec une autre clé et le message n'a pas été éventé. Tout le problème est donc de s'en rendre compte.
Cordialement,
--
/************************************************************** * Patrick BRUNET @ ZenerTopia * E-mail: lien sur http://zener131.free.fr/ContactMe **************************************************************/ <8#--X--< filtré par Avast! 4 Home
