Une petite question que je me pose :
En pratique, sur le terrain, lors d'une attaque en force brute comment
fait-on pour savoir que l'on a trouvé le texte clair ?
Je présume qu'il faut en examiner un certain nombre en fonction des essais
successifs, les lire tous serait un travail de bénédictain !
Il existe vraisemblablement un moyen automatique de savoir qu'on a un texte
intelligible, lequel ?
stats alphabètiques sur la langue présumée du clair par exemple ?
Une petite question que je me pose :
En pratique, sur le terrain, lors d'une attaque en force brute comment
fait-on pour savoir que l'on a trouvé le texte clair ?
Je présume qu'il faut en examiner un certain nombre en fonction des essais
successifs, les lire tous serait un travail de bénédictain !
Il existe vraisemblablement un moyen automatique de savoir qu'on a un texte
intelligible, lequel ?
stats alphabètiques sur la langue présumée du clair par exemple ?
Une petite question que je me pose :
En pratique, sur le terrain, lors d'une attaque en force brute comment
fait-on pour savoir que l'on a trouvé le texte clair ?
Je présume qu'il faut en examiner un certain nombre en fonction des essais
successifs, les lire tous serait un travail de bénédictain !
Il existe vraisemblablement un moyen automatique de savoir qu'on a un texte
intelligible, lequel ?
stats alphabètiques sur la langue présumée du clair par exemple ?
Yves wrote:Une petite question que je me pose :
En pratique, sur le terrain, lors d'une attaque en force brute comment
fait-on pour savoir que l'on a trouvé le texte clair ?
(...)
Oui effectivement, on peut lancer plusieurs tests statistiques comme par
exemple l'indice de coincidence (probabilité que deux lettres tirées
aléatoirement soient identiques). Ce nombre varie selon la langue (0.065
pour l'anglais) et un contenu aléatoire aura un indice plus bas (qui tend
vers environ 0.038). L'avantage c'est que si une substitution
monoalphabétique a été faite au préalable ou que les lettres ont été
permutées, alors l'indice de coincidence ne changera pas.
(...)
Yves wrote:
Une petite question que je me pose :
En pratique, sur le terrain, lors d'une attaque en force brute comment
fait-on pour savoir que l'on a trouvé le texte clair ?
(...)
Oui effectivement, on peut lancer plusieurs tests statistiques comme par
exemple l'indice de coincidence (probabilité que deux lettres tirées
aléatoirement soient identiques). Ce nombre varie selon la langue (0.065
pour l'anglais) et un contenu aléatoire aura un indice plus bas (qui tend
vers environ 0.038). L'avantage c'est que si une substitution
monoalphabétique a été faite au préalable ou que les lettres ont été
permutées, alors l'indice de coincidence ne changera pas.
(...)
Yves wrote:Une petite question que je me pose :
En pratique, sur le terrain, lors d'une attaque en force brute comment
fait-on pour savoir que l'on a trouvé le texte clair ?
(...)
Oui effectivement, on peut lancer plusieurs tests statistiques comme par
exemple l'indice de coincidence (probabilité que deux lettres tirées
aléatoirement soient identiques). Ce nombre varie selon la langue (0.065
pour l'anglais) et un contenu aléatoire aura un indice plus bas (qui tend
vers environ 0.038). L'avantage c'est que si une substitution
monoalphabétique a été faite au préalable ou que les lettres ont été
permutées, alors l'indice de coincidence ne changera pas.
(...)
Doit-on en déduire qu'un double chiffrement du texte clair (avec 2
algos et 2 clés différentes) met à l'abri de l'attaque par force
brute ? En effet dans ce cas, impossible pour l'attaquant de savoir
si il a trouvé la première clé car l'étude statistique évoquée ici
serait inopérante...
Doit-on en déduire qu'un double chiffrement du texte clair (avec 2
algos et 2 clés différentes) met à l'abri de l'attaque par force
brute ? En effet dans ce cas, impossible pour l'attaquant de savoir
si il a trouvé la première clé car l'étude statistique évoquée ici
serait inopérante...
Doit-on en déduire qu'un double chiffrement du texte clair (avec 2
algos et 2 clés différentes) met à l'abri de l'attaque par force
brute ? En effet dans ce cas, impossible pour l'attaquant de savoir
si il a trouvé la première clé car l'étude statistique évoquée ici
serait inopérante...
Doit-on en déduire qu'un double chiffrement du texte clair (avec 2
algos et 2 clés différentes) met à l'abri de l'attaque par force
brute ? En effet dans ce cas, impossible pour l'attaquant de savoir
si il a trouvé la première clé car l'étude statistique évoquée ici
serait inopérante...
Doit-on en déduire qu'un double chiffrement du texte clair (avec 2
algos et 2 clés différentes) met à l'abri de l'attaque par force
brute ? En effet dans ce cas, impossible pour l'attaquant de savoir
si il a trouvé la première clé car l'étude statistique évoquée ici
serait inopérante...
Doit-on en déduire qu'un double chiffrement du texte clair (avec 2
algos et 2 clés différentes) met à l'abri de l'attaque par force
brute ? En effet dans ce cas, impossible pour l'attaquant de savoir
si il a trouvé la première clé car l'étude statistique évoquée ici
serait inopérante...
Doit-on en déduire qu'un double chiffrement du texte clair (avec 2
algos et 2 clés différentes) met à l'abri de l'attaque par force
brute ? [...]
En général, les messages chiffrés sont au préalable compressés, ce qui
mis à part le gain de taille permet aussi de rendre plus difficile une
attaque.
Doit-on en déduire qu'un double chiffrement du texte clair (avec 2
algos et 2 clés différentes) met à l'abri de l'attaque par force
brute ? [...]
En général, les messages chiffrés sont au préalable compressés, ce qui
mis à part le gain de taille permet aussi de rendre plus difficile une
attaque.
Doit-on en déduire qu'un double chiffrement du texte clair (avec 2
algos et 2 clés différentes) met à l'abri de l'attaque par force
brute ? [...]
En général, les messages chiffrés sont au préalable compressés, ce qui
mis à part le gain de taille permet aussi de rendre plus difficile une
attaque.
Globalement, cela consiste à introduire de la sécurité par l'obscurité
dans le chiffrement. L'attaquant ne doit pas savoir qu'il y a eu double
chiffrement, le destinataire si, sinon il ne peut pas récupérer son
message. Si l'attaquant l'apprend, il modifie son test d'arrêt pour un
double déchiffrement. Si les clé sont indépendantes, il peut avoir 2^n
fois plus de boulot, mais cela revient, au mieux, au même que d'avoir
doublé la longueur de clé.
Globalement, cela consiste à introduire de la sécurité par l'obscurité
dans le chiffrement. L'attaquant ne doit pas savoir qu'il y a eu double
chiffrement, le destinataire si, sinon il ne peut pas récupérer son
message. Si l'attaquant l'apprend, il modifie son test d'arrêt pour un
double déchiffrement. Si les clé sont indépendantes, il peut avoir 2^n
fois plus de boulot, mais cela revient, au mieux, au même que d'avoir
doublé la longueur de clé.
Globalement, cela consiste à introduire de la sécurité par l'obscurité
dans le chiffrement. L'attaquant ne doit pas savoir qu'il y a eu double
chiffrement, le destinataire si, sinon il ne peut pas récupérer son
message. Si l'attaquant l'apprend, il modifie son test d'arrêt pour un
double déchiffrement. Si les clé sont indépendantes, il peut avoir 2^n
fois plus de boulot, mais cela revient, au mieux, au même que d'avoir
doublé la longueur de clé.
D'où vient l'idée que seuls les fichier au format TXT ASCII, 8 BITS sans
entete ni rien seraient seuls a être encrypté ?
Si je cherche a décrypter un fichier dont je ne connais pas le format
(imaginons que même le nom du fichier soir crypté), je fais comment pour
l'attaque en "Brut Force" ? C'est un .doc ? un .exe ? un .dll ? .xls ? . zip
? .rar ? . lzh ? etc.
De même j'ai vu passé ici un programme de crypto qui en plus d'un algo de
chiffrage XORise le fichier d'entrée avec du bruit blanc.
La clé du généreateur se trouve à la fin de chaque bloc (1 ou 2 Ko quand
même!).
L'attaque en brut force est méchement ralenti, car a chaque test de clé, il
faut relire la seconde clé qui est a la fin du bloc faire des XOR sur
l'ensemble puis faire son analyse statistique pour espérer retrouver
quelquechose... infaisable.
D'où vient l'idée que seuls les fichier au format TXT ASCII, 8 BITS sans
entete ni rien seraient seuls a être encrypté ?
Si je cherche a décrypter un fichier dont je ne connais pas le format
(imaginons que même le nom du fichier soir crypté), je fais comment pour
l'attaque en "Brut Force" ? C'est un .doc ? un .exe ? un .dll ? .xls ? . zip
? .rar ? . lzh ? etc.
De même j'ai vu passé ici un programme de crypto qui en plus d'un algo de
chiffrage XORise le fichier d'entrée avec du bruit blanc.
La clé du généreateur se trouve à la fin de chaque bloc (1 ou 2 Ko quand
même!).
L'attaque en brut force est méchement ralenti, car a chaque test de clé, il
faut relire la seconde clé qui est a la fin du bloc faire des XOR sur
l'ensemble puis faire son analyse statistique pour espérer retrouver
quelquechose... infaisable.
D'où vient l'idée que seuls les fichier au format TXT ASCII, 8 BITS sans
entete ni rien seraient seuls a être encrypté ?
Si je cherche a décrypter un fichier dont je ne connais pas le format
(imaginons que même le nom du fichier soir crypté), je fais comment pour
l'attaque en "Brut Force" ? C'est un .doc ? un .exe ? un .dll ? .xls ? . zip
? .rar ? . lzh ? etc.
De même j'ai vu passé ici un programme de crypto qui en plus d'un algo de
chiffrage XORise le fichier d'entrée avec du bruit blanc.
La clé du généreateur se trouve à la fin de chaque bloc (1 ou 2 Ko quand
même!).
L'attaque en brut force est méchement ralenti, car a chaque test de clé, il
faut relire la seconde clé qui est a la fin du bloc faire des XOR sur
l'ensemble puis faire son analyse statistique pour espérer retrouver
quelquechose... infaisable.
Je crois que tu ne réalise pas à quel point il est ridicule d'essayer de
rendre plus difficile le déchiffrement en reposant sur le fait que
l'attaquant ne connaît pas le format de mon fichier par rapport à une
bonne solution de prendre un algorithme efficace.
Si je veux échapper à quelqu'un qui me poursuit, je prend une Ferrari,
et j'appuie sur l'accélérateur jusqu'au plancher, sur un circuit sans
limitations de vitesse (AES en mode 256 bits par exemple).
La solution d'échanger mes chaussure de ville contre des Nike Air est
chiante et inefficace. A bord de ma Ferrari, peu importe que j'appuie
sur l'accélérateur avec l'un ou avec l'autre.
Ca prend un temps extrêmement négligeable par rapport au temps total de
la force brute.
L'intérête de ce type de procédé n'est pas contre la force brute, mais
pour le cas où le chiffrement ne marche pas très bien, et les propriétés
statistiques du texte en entrée permettent d'une manière où d'une autre
de faciliter une attaque. Grâce au xor, on chiffre un texte dont les
statistique sont celle du bruit blanc, et on fait disparaître ce risque.
Je crois que tu ne réalise pas à quel point il est ridicule d'essayer de
rendre plus difficile le déchiffrement en reposant sur le fait que
l'attaquant ne connaît pas le format de mon fichier par rapport à une
bonne solution de prendre un algorithme efficace.
Si je veux échapper à quelqu'un qui me poursuit, je prend une Ferrari,
et j'appuie sur l'accélérateur jusqu'au plancher, sur un circuit sans
limitations de vitesse (AES en mode 256 bits par exemple).
La solution d'échanger mes chaussure de ville contre des Nike Air est
chiante et inefficace. A bord de ma Ferrari, peu importe que j'appuie
sur l'accélérateur avec l'un ou avec l'autre.
Ca prend un temps extrêmement négligeable par rapport au temps total de
la force brute.
L'intérête de ce type de procédé n'est pas contre la force brute, mais
pour le cas où le chiffrement ne marche pas très bien, et les propriétés
statistiques du texte en entrée permettent d'une manière où d'une autre
de faciliter une attaque. Grâce au xor, on chiffre un texte dont les
statistique sont celle du bruit blanc, et on fait disparaître ce risque.
Je crois que tu ne réalise pas à quel point il est ridicule d'essayer de
rendre plus difficile le déchiffrement en reposant sur le fait que
l'attaquant ne connaît pas le format de mon fichier par rapport à une
bonne solution de prendre un algorithme efficace.
Si je veux échapper à quelqu'un qui me poursuit, je prend une Ferrari,
et j'appuie sur l'accélérateur jusqu'au plancher, sur un circuit sans
limitations de vitesse (AES en mode 256 bits par exemple).
La solution d'échanger mes chaussure de ville contre des Nike Air est
chiante et inefficace. A bord de ma Ferrari, peu importe que j'appuie
sur l'accélérateur avec l'un ou avec l'autre.
Ca prend un temps extrêmement négligeable par rapport au temps total de
la force brute.
L'intérête de ce type de procédé n'est pas contre la force brute, mais
pour le cas où le chiffrement ne marche pas très bien, et les propriétés
statistiques du texte en entrée permettent d'une manière où d'une autre
de faciliter une attaque. Grâce au xor, on chiffre un texte dont les
statistique sont celle du bruit blanc, et on fait disparaître ce risque.
D'où vient l'idée que seuls les fichier au format TXT ASCII, 8 BITS sans
entete ni rien seraient seuls a être encrypté ?
De nulle part.
[...]
pour le cas où le chiffrement ne marche pas très bien, et les propriétés
statistiques du texte en entrée permettent d'une manière où d'une autre
[...]
D'où vient l'idée que seuls les fichier au format TXT ASCII, 8 BITS sans
entete ni rien seraient seuls a être encrypté ?
De nulle part.
[...]
pour le cas où le chiffrement ne marche pas très bien, et les propriétés
statistiques du texte en entrée permettent d'une manière où d'une autre
[...]
D'où vient l'idée que seuls les fichier au format TXT ASCII, 8 BITS sans
entete ni rien seraient seuls a être encrypté ?
De nulle part.
[...]
pour le cas où le chiffrement ne marche pas très bien, et les propriétés
statistiques du texte en entrée permettent d'une manière où d'une autre
[...]