Question:
Si quelqu'un casse le cryptage, comment sait-il qu'il réussit?
M. Evans
2011-01-18 09:56:38 UTC
view on stackexchange narkive permalink

Disons que j'ai un fichier contenant un tas de bits aléatoires, puis je le crypte en utilisant un algorithme moderne (Blowfish, AES, ou autre). Si quelqu'un capture le fichier et monte une attaque par force brute dessus, comment saura-t-il qu'il l'a déchiffré avec succès? Il serait évident que l'entrée d'origine était significative, mais dans ce cas, l'entrée d'origine n'était qu'un tas d'octets aléatoires. Comment sauraient-ils, voire pas du tout, que c'était le bon groupe d'octets aléatoires?

Votre prémisse est extrêmement irréaliste. En pratique, ce n'est presque jamais comme ça: le fichier chiffré a presque toujours une structure. Les réponses à la question que vous avez posée sont susceptibles d'induire en erreur sur le monde réel. Par conséquent, la meilleure réponse à cette question pourrait bien être de ne pas poser la question et d'en poser une autre.
Je pense que la question est plutôt légitime. Prenez un fichier binaire chiffré, comment un logiciel de forçage brutal sait-il qu'il a fini de le déchiffrer? Je me demande en fait pourquoi cacher des documents dans des binaires qui les impriment n'est pas fait plus souvent, cela ne tromperait-il pas le pirate?
@L. De: Un fichier exécutable binaire a encore une certaine structure - presque tous les fichiers aléatoires ne sont pas exécutables avec succès.
@D.W. - Je viens de regarder le format de fichier Truecrypt: http://www.truecrypt.org/docs/?s=volume-format-specification il semble que tous les fiels sauf le SALT sont cryptés.
Huit réponses:
#1
+30
PulpSpy
2011-01-18 10:02:48 UTC
view on stackexchange narkive permalink

Ils ne le feraient pas. Le problème que vous avez décrit est bien traité dans l'article de Wikipédia sur Unicity Distance. Cet article renvoie également à un article de Bruce Schneier qui pourrait être plus accessible.

#2
+12
Giacomo Verticale
2011-01-18 14:59:04 UTC
view on stackexchange narkive permalink

En général, les gens ne chiffrent pas les ordures au hasard. En supposant qu'ils le fassent, une attaque de texte chiffré uniquement serait impossible.

Cependant, considérez que les schémas cryptographiques courants ajoutent au message des données non aléatoires, telles que les données de remplissage et codes d'authentification de message. Dans certains schémas, ceux-ci peuvent être utilisés pour vérifier si une clé devinée est correcte.

#3
+5
Am1rr3zA
2011-01-18 15:15:03 UTC
view on stackexchange narkive permalink

D'une manière générale, ils ne peuvent pas casser le cryptage (si vous cryptez un fichier aléatoire (par exemple une clé secrète) ou même compressez un fichier) mais si le sniffer a un autre accès au système émetteur ou récepteur, il peut faire un autre type d'attaque, et peut casser le cryptage aléatoire des fichiers. vous en lirez plus ici:

une force brute peut briser le cryptage. Le problème soulevé par l'OP est que si les données cryptées étaient aléatoires en texte clair, vous ne saurez pas quand la force brute a fonctionné avec succès, par opposition au texte clair lisible.
@Rory Je le comprends, peut-être que je ne peux pas l'expliquer clairement, je veux dire l'attaquant pour comprendre qu'il / elle brise le message crypté (message aléatoire) correctement a besoin d'informations supplémentaires qu'il / elle obtient du texte en clair choisi et ....
#4
+3
bahamat
2011-01-18 14:36:50 UTC
view on stackexchange narkive permalink

Si le texte clair est aléatoire, ils ne le sauront pas. Cependant, la plupart des types de fichiers ont une sorte de structure reconnaissable. Passer le blob A à l'algorithme B avec la clé C donnera une sortie. Si cette sortie a une structure, vous avez un gagnant.

#5
+2
Rushyo
2011-01-18 22:32:04 UTC
view on stackexchange narkive permalink

Ils ne le font pas. TrueCrypt profite de ce fait même pour offrir un déni plausible à travers des «volumes cachés»: http://www.truecrypt.org/docs/?s=hidden-volume

Le déni plausible provient du fait que les données cryptées semblent aléatoires, cela ne change pas les données cryptées avant le cryptage.
Ce qui n'affecte en aucun cas ce que j'ai écrit? Le fait est que vous ne savez pas à quoi les données cryptées sont censées ressembler, il est donc impossible de savoir à quoi elles sont censées ressembler. Les volumes cachés sont un cas pratique de l'application de ce concept.
Le déni plausible n'utilise pas le double cryptage (volume crypté à l'intérieur du volume crypté), il met deux volumes côte à côte dans le même fichier. C'est pourquoi si vous écrivez trop de données sur le volume "for-cops", vous pouvez écraser votre volume "secret".
... et je n'ai jamais rien mentionné sur le double cryptage. Vous discutez d'un homme de paille.
Ensuite, vous n'avez pas répondu à la question posée par OP. Un déni plausible ne déchiffre pas les mêmes données avec des clés différentes pour obtenir des résultats différents. Il décrypte différentes données à l'aide de différentes clés. Donc, juste parce que dans un fichier, vous avez deux volumes, il n'est pas nécessaire de vérifier si la clé trouvée est correcte, les deux volumes auront des données très organisées à l'intérieur (le système de fichiers). Cela ne change pas non plus la façon dont l'attaque par force brute (ou par dictionnaire) sur le chiffrement est effectuée.
"Si quelqu'un casse le cryptage, comment sait-il qu'il réussit?" "Non." Là, réponse à la question. La référence TrueCrypt vient d'ajouter un peu de saveur et de contexte. La méthodologie de cela et la façon dont elle affecte une méthode particulière de rupture de tout cryptage n'est pas pertinente / muette
#6
+2
freddyb
2011-03-24 03:20:18 UTC
view on stackexchange narkive permalink

Votre question me paraît double: tout d'abord, un bon algorithme de chiffrement ne se distingue pas de l'aléatoire, donc personne ne distinguera même votre texte chiffré des données aléatoires. De plus, un texte chiffré faussement déchiffré le fera Par conséquent, vous ne pourrez pas trouver les données aléatoires initialement introduites dans le chiffrement avec une recherche par clé exhaustive.

Deuxièmement, le fait est que les gens ne fournissent généralement pas de données aléatoires dans le chiffrement Les normes de cryptage actuelles ne couvrent pas seulement l'algorithme mais aussi les données utilisées.Les gens pré- et suffixent généralement vos données toujours avec un certain remplissage et certaines métadonnées (les schémas de cryptage ont une longueur fixe. Vous devez en quelque sorte spécifier la durée de votre texte) . Connaître ces bits standard facilitera évidemment la décision entre la bonne et la mauvaise clé:) Si le remplissage sert principalement à des fins pratiques, il peut également améliorer ou même garantir des fonctionnalités de sécurité (cf. attaque en texte brut choisie sur RSA de manuel).

#7
  0
jokoon
2011-01-18 22:41:02 UTC
view on stackexchange narkive permalink

Si le fichier est unicode / ansi / etc, vous pouvez créer un algorithme pour analyser quelque chose comme les 200 premiers caractères d'un fichier et voir s'il y a plus de caractères latins que d'autres caractères.

Je me souviens J'étais assez ennuyé quand j'ai essayé l'attaque par force brute XOR sur un simple exercice de projet euler, mais c'était facile et je devais juste chercher des mots anglais courants.

J'ai lu quelque part cela dans un logiciel de cryptage, la mise en œuvre est très importante, parfois plus importante que les alorithmes. Quand je lis cela, je me demande encore si on parle de sujets évidents comme les générateurs pseudo aléatoires, ou de détails plutôt moins évidents comme comment cacher le format du fichier que vous cryptez.

Par exemple, si vous cryptez un fichier, s'il s'agit d'un fichier PNG ou GIF, assurez-vous de supprimer le numéro / chaîne magique que ces formats de fichier contiennent, et s'il s'agit d'un fichier texte, n'utilisez pas de table ASCII: utilisez votre propre table de caractères, par exemple il suffit de mettre tous les caractères latins à 0, les nombres à 245-255, et ainsi de suite. vous pouvez également permutation, ou rot13, ou autre.

Les algorithmes tels que AES ou Blowfish / TwoFish sont "mathématiquement" sécurisés, car il a été prouvé qu'aucune attaque AUTRE QUE BRUTEFORCE n'a été testée comme suffisamment efficace: vous ne peut déchiffrer le texte qu'en trouvant la clé réelle.

Mais ces algorithmes ne sont efficaces que théoriquement, vous DEVEZ les implémenter en tenant compte d'autres facteurs pratiques tels que la taille du fichier, l'utilisation de la compression, l'encodage de texte, etc.

Par exemple, sachez qu'il serait tout simplement stupide de stocker le nom de fichier en texte brut à côté de votre fichier crypté.

En fait, les chiffrements symétriques modernes (dans des modes de fonctionnement sécurisés) devraient laisser le reste du document secret même si le début est un en-tête connu. (Ceci est connu comme une attaque en clair.)
La sécurité des chiffrements réside dans le fait que personne (comme dans beaucoup de gens) n'a montré comment les briser, le * seul * algorithme qui est mathématiquement sécurisé est un tampon ponctuel.
#8
  0
user6373
2011-12-27 17:58:46 UTC
view on stackexchange narkive permalink

Outre l'approche théoriquement ignorante de certains "pros" dans le domaine, il y a une réponse assez simple à votre question: en comparant les "résultats de décryptage par force brute" avec des éléments évidents à des fins de catégorisation.

Laissez-moi vous donner des exemples pratiques: les fichiers texte contiendront très probablement des "mots vides" ( http://en.wikipedia.org/wiki/Stop_words). Trouvez plus d'un mot d'arrêt après le décryptage et vous avez probablement décodé du texte avec succès.

Les fichiers multimédias comme les images et la plupart des autres types de fichiers (audio, vidéo, etc.) ont tous des en-têtes spécifiques, ce qui facilite l'identification du type de données. Vous pensez avoir décrypté un jpeg parce que vous avez détecté un en-tête similaire? Vérifiez le format de fichier. On dirait que c'est correct? Ensuite, vous avez probablement décrypté avec succès un fichier multimédia jpeg.

Je pourrais vous fournir des livres d'exemples ... mais vous savez ce que je veux dire maintenant, n'est-ce pas? ;)

Le reste dépend d'une petite "vérification humaine" pour que vous sachiez quand arrêter de forcer brutalement tout ce que vous essayez de déchiffrer.

Est-ce pratique? Non, mais cela peut être fait lorsque codé correctement et cela facilite le travail. Je l'ai vu en action plusieurs fois; pas seulement dans un environnement d'entreprise.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 2.0 sous laquelle il est distribué.
Loading...