Y a-t-il des conséquences réelles des attaques d'oracle de remplissage?
J'écris un programme qui crypte des données en Python et j'ai entendu parler d' attaques d'oracle de remplissage , mais je pense qu'elles sont surestimées (je veux dire, quelles sont les utilisations dans le monde réel?) Même pour les anciennes implémentations qui sont vulnérables (celles qui disent si le remplissage est correct ou faux comme SSLv3).
Car:
- Si tout ce dont j'ai besoin, ce sont deux textes chiffrés $c(n-1)$, $c(n)$ qui sont les deux derniers blocs de messages chiffrés, et un serveur pour me dire si le remplissage de déchiffré $c(n)$est correct ou autre, cela ne signifie pas que le serveur décrypte simplement tout ce que vous lui envoyez (je veux dire, envoyez simplement le message crypté entier tel que vous l'avez reçu et lisez la sortie). Je veux dire, c'est le bogue du serveur qui ne prend pas de clé en premier lieu et vérifie si c'est correct.
- Supposons que tout ce que nous avons à faire est d'envoyer ces deux messages chiffrés pour connaître et déchiffrer le dernier bloc (le bloc de remplissage). Cela ne fonctionne que car le texte brut de remplissage est connu ou du moins pas aléatoire ou pour une raison quelconque.
Mais qu'en est-il, disons, c2 et c3 qui sont au milieu de tout le message? Nous connaissons c3 et c2, mais nous ne savons pas et nous ne connaîtrons jamais ni p3 ni p2 (texte clair), ni l'état intermédiaire IS3 ; c'est-à-dire que nous ne pouvons pas XOR c2 avec is3 pour obtenir p3 , donc cette attaque, je pense, nous permet seulement de décrypter le bloc de remplissage avec la seule nouvelle chose que nous connaissions réellement est un état intermédiaire du bloc de remplissage.
Je demande à savoir si cette attaque est juste une attaque sans implication dans le monde réel et sans réelles capacités de décryptage de données (données réelles).
Réponses
Je veux dire que c'est le bogue du serveur qui ne prend pas de clé en premier lieu et vérifie si c'est correct :)
Qu'est-ce que tu veux dire par là? La clé doit être la bonne, et les attaques d'oracle de remplissage modifient en fait le texte chiffré chiffré avec cette clé de l'autre côté pour effectuer l'attaque.
mais qu'en est-il de dire c2, c3 qui sont au milieu du message entier, nous connaissons c3 et c2 mais nous ne savons pas et nous ne connaîtrons jamais ni p3 (texte clair bien sûr) ni état intermédiaire IS3
Non, une attaque d'oracle de remplissage est capable de décrypter complètement un message. C'est précisément parce que le XOR influence le bloc suivant.
Notez que les attaques d'oracle de remplissage ne sont qu'une forme d'attaque d'oracle en texte brut . Par exemple, vous pouvez également effectuer des attaques oracle en texte brut sur XML-enc, même sans utiliser le remplissage lui-même.
Je demande à savoir si cette attaque est juste une attaque sans implication dans le monde réel et sans réelles capacités de décryptage de données (données réelles).
Oui, c'est complètement et complètement faux. Une attaque d'oracle de remplissage peut décrypter tout le message en utilisant 128 essais par octet, et d'autres oracles en texte clair peuvent en fait être encore plus efficaces.
De plus, faire accepter par le destinataire un texte brut modifié est peut-être aussi dangereux que de perdre la confidentialité. Pour cette raison, vous devez utiliser un cryptage authentifié - ou plutôt un protocole qui utilise un cryptage authentifié au lieu d'un CBC non authentifié.
Je demande à savoir si cette attaque est juste une attaque sans implication dans le monde réel et sans réelles capacités de décryptage de données (données réelles).
L' attaque Lucky Thirteen est une attaque du monde réel contre TLS. C'était une attaque sérieuse pour les versions alors actuelles du protocole TLS (TLS 1.0 à l'époque - TLS 1.1 et 1.2 existaient mais avaient très peu d'adoption). Donc non, les attaques d'oracle de remplissage fonctionnent absolument dans le monde réel.
(ceux qui indiquent si le remplissage est correct ou faux comme sslv3).
Lucky Thirteen affecte les versions jusqu'à TLS 1.2, qui est la version utilisée pour la majorité des communications sécurisées aujourd'hui. Cela n'affecte que les suites de chiffrement qui utilisent CBC, qui sont obsolètes précisément à cause de cette attaque, mais la plupart des points de terminaison l'autorisent toujours, même s'ils préfèrent les suites de chiffrement AEAD. Beaucoup d'implémentations TLS populaires, mais pas toutes, ont un code qui empêche l'attaque de Lucky Thirteen (au détriment des performances). Donc non, les attaques d'oracle de remplissage sont pertinentes pour les protocoles qui sont encore largement utilisés.
J'écris un programme qui crypte les données en python et j'ai entendu parler des attaques oracle de remplissage, mais je pense qu'elles sont surestimées
Eh bien, il est vrai que vous ne devriez pas vous soucier du remplissage des attaques d'oracle. Mais la raison pour laquelle vous ne devriez pas vous inquiéter, c'est que puisqu'ils sont bien connus, nous savons comment nous défendre contre eux: n'utilisez pas de rembourrage. Et aucun mode moderne de cryptage n'utilise le remplissage. Utilisez simplement n'importe quel mode AEAD courant, tel que GCM, CCM ou ChaCha20 + Poly1305. Ou mieux encore, utilisez une bibliothèque de haut niveau telle que NaCl / libsodium ( PyNaCl en Python): si vous tapez les lettres AES dans votre code, vous le faites mal .