OVH Cloud OVH Cloud

petite question bête

9 réponses
Avatar
Yves
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 ?

merci d'avance,

Y.

9 réponses

Avatar
Kevin Drapel
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 ?
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 ?


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.

http://www.apprendre-en-ligne.net/crypto/stat/ic.html

On peut aussi chercher des digrammes et des trigrammes présents dans la
langue, en français, on chercherait surtout "le", "de", "en", "an", etc.
La proportion de voyelles et de consonnes est aussi un bon indicateur.
Dans certaines languages, certaines lettres sont absentes ou très rares
(en italien, KJYWX).

Voici un site intéressant à ce sujet :

http://members.fortunecity.com/jpeschel/lesson7.htm

Avatar
mif
"Kevin Drapel" a écrit dans le message de news:

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...


Avatar
Kevin Drapel
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...


C'est une possibilité si les algos ne sont pas trop simples (si on
utilise deux algos monoalphabétiques, cela ne changera rien).

En général, les messages chiffrés sont au préalable compressés, ce qui
mise à part le gain de taille permet aussi de rendre plus difficile une
attaque.

Avatar
Kevin Drapel
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...


C'est une possibilité si les algos ne sont pas trop simples (si on
utilise deux algos monoalphabétiques, cela ne changera rien).

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.

Avatar
Jean-Marc Desperrier
Kevin Drapel wrote:
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é.

Et l'objectif d'une bonne sécurité est de ne pas avoir à reposer sur
l'obscurité pour se protéger.

La compression est un peu plus utile, pas parcequ'elle gène les tests
d'arrêt, il y a toujours un en-tête de compression et autres moyens de
vérifier si les données sont valides que l'on peut utiliser pour cela,
mais parcequ'elle rend les attaques à clair connu plus difficiles.

Il y a justement un exemple pratique le chiffrement du format zip qui
est cassé car sensible aux attaques à clair connu, mais il n'est pas
toujours évident de l'attaquer, car comme on compresse avant de
chiffrer, l'attaquant ne peut pas toujours deviner suffisament de clair
pour réaliser l'attaque.
Mais cela montre aussi que ça n'apporte pas grand chose en pratique. Il
vaut infiniment mieux un algo solide, qu'un algo sensible aux attaques à
clair connu avec lequelle comme pour le zip on prie à chaque message
signé pour que grâce au secours de la compression l'attaquant n'arrive
pas à trouver suffisament de clair pour attaquer.


Avatar
ECCO
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é.


Ce que je me demande aussi :

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.

Avatar
Jean-Marc Desperrier
ECCO wrote:
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.

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.


Et ? Il suffit de faire un test de magic number, etc.. Toujours de
l'obscurité.

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.

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.


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.

Par exemple, un truc de ce genre appliqué à un texte avant de le hasher
par un MD5 déjouerait les attaques connues.

Avatar
ECCO
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.


Tout est une question de temps d'implementation et de connaissance.
Si un algo symétrique suffit, que j'ai une journée (budget réduit) pour
crypter la chose,
et qu'en plus je code sur un hardware ou il n'existe aucun compilo C, C++
mais que je dois taper le code en assembleur,
je pense que je m'orienterais vers une solution maison.

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.


Tres bon exemple. Si j'ai de quoi me payer la Ferrari ca va. Si j'ai 250
euros je prends la paire de pompe


Ca prend un temps extrêmement négligeable par rapport au temps total de
la force brute.


Hummm... je n'ai pas du etre clair. Dans l'exercice de la brute force, il
faut à chaque clé, décoder le buffer entier avant de déduire si OUI ou NON,
c'était la bonne clé. Le test est a refaire A CHAQUE clé testé. Si il faut
150 cycles horloge pour faire une nouvelle clé (estimation toute
personnelle), il faut rajouter plusieurs dixaine milliers pour le buffer.


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.


Ca, c'est vrai !

Avatar
ECCO
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.


Ha bon ? De nulle part ? Les propritété statistiques de quoi déjà ? On les
connais d'où ces fameuses propritétés statistiques si l'on ne connais pas le
type de fichier. Surtout que PERSONNE n'utilise les documents en TXT brute.


[...]
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
[...]