Y a-t-il une limite sur les couches de cryptage qu'un fichier peut avoir?
Envisagez le chiffrement GPG symétrique d'un fichier donné my_file.txt. Quelque chose comme (en ligne de commande)
gpg --symmetric --cipher-algo AES256 my_file.txt
Après avoir fourni l'invite avec le nouveau mot de passe, ce qui précède produit my_file.txt.gpg. Je pourrais alors chiffrer à nouveau:
gpg --symmetric --cipher-algo AES256 my_file.txt.gpg
(où vous souhaitez définir un mot de passe différent)
Etc. Y a-t-il une limite au nombre d'itérations de ce qui précède que je peux faire? Il me semble que non, car le chiffrement symétrique prend simplement un morceau de texte et le transforme en un autre, sans jamais se demander ce qu'est le morceau de texte en premier lieu. Est-ce vrai?
Théoriquement, il n'y a pas de limite au nombre de fois que vous pouvez crypter un fichier. La sortie d'un processus de cryptage est à nouveau un fichier, que vous pouvez à nouveau transmettre à un autre algorithme et obtenir une sortie.
Le problème est que, du côté du déchiffrement, il devra être déchiffré dans le style LIFO (dernier entré, premier sorti), avec les mots de passe appropriés.
Par exemple, si votre fichier a d'abord été chiffré avec algo1 avec le mot de passe abcde, puis il a été chiffré avec algo2 avec le mot de passe vwxyz, il devra d'abord être déchiffré avec algo2 (avec le mot de passe vwxyz), puis avec algo1 (avec mot de passe abcde).
Cette méthode est logique si vous envoyez les clés via différents supports ou canaux. Cette méthode serait peu utile si tous les mots de passe sont envoyés via le même canal.
- Donc, tôt ou tard, vous serez à court d'espace.
GnuPG utilise CFB mode de fonctionnement pour le chiffrement symétrique (défini dans rfc488 ). Le mode CFB nécessite un IV avec une taille de 128 bits pour le cryptage AES et il n'a pas besoin de remplissage.
Alors qu'en théorie il n'y a pas de limite comme l'a souligné l'autre réponse; il existe une limite pratique en raison de l'augmentation de la taille du fichier. Par exemple, j'ai chiffré un fichier de 163 octets puis le résultat était de 213 octets, après avoir rechiffré le précédent, le résultat devient 295 octets, 382 octets, 473 octets, ...
Ces octets incluent également paquet de GnuPG. Donc, tôt ou tard, vous serez à court d'espace.
Il est vrai qu'il n'y a pas de limite au nombre de fois que vous pouvez crypter un fichier, mais ce n'est pas nécessairement le cas que vous devez décrypter dans l'ordre LIFO.
Vous pouvez toujours être sûr que LIFO fonctionnera, mais certains fichiers cryptés à plusieurs reprises peuvent être décryptés dans le désordre sans affecter le résultat (selon les algorithmes utilisés pour le cryptage):
Pensez à chiffrer deux fois le même fichier à l'aide de 1 Time Pad (XOR) avec des clés différentes. Vous pouvez décrypter dans l'un ou l'autre ordre, car (A xor B) xor C == (A xor C) xor B pour chaque bit.
(Ce serait un commentaire si j'avais 50 représentants, n'hésitez pas à modifier l'autre réponse et à supprimer celle-ci.)
EDIT: Voir cette question pour plus de détails sur cette affaire Edge.
Comme beaucoup l'ont déjà observé, vous aurez une petite augmentation de la taille de votre fichier après chaque niveau de cryptage, en raison de l'IV qui doit être ajouté au fichier après chaque cryptage. Pas vraiment pertinent.
Je voudrais plutôt observer que votre motivation à le faire est évidemment d'augmenter la robustesse de votre texte chiffré contre les attaques, y compris les attaques par force brute. Si vous utilisez une clé de $ n $ bits pour chacun des niveaux de chiffrement $ h $, disons les clés $ k_1, k_2,\ldots, k_h $, vous pouvez vous attendre à obtenir la robustesse d'un chiffrement unique basé sur une clé plus longue de $ h\fois n $ bits. Théoriquement, il est possible de lancer l'attaque Meet-in-the-Middle , qui permet à un adversaire de réduire la taille de l'espace clé à moins de $ 2 ^ {h\times n} $. Un exemple pratique est le 2-DES, où le texte en clair $ P $ est d'abord chiffré par une clé DES (56 bits), obtenant ainsi un texte chiffré $ C '$, puis $ C' $ est à nouveau chiffré par une autre clé DES, obtenant ainsi le texte chiffré final $ C $. Cependant, l'attente d'avoir une taille d'espace de clé égale à $ 2 ^ 112 $ est fausse. La taille réelle sera $ 2 ^ 57 $ parce que l'attaque Meet-in-the-Middle, c'est-à-dire attaque en texte clair conn (ce qui signifie que l'adversaire connaît une paire $ (P, C) $), permettra à l'adversaire pour construire d'abord une table de tous les chiffrements possibles de $ 2 ^ 56 $ de $ P $ (un pour chaque clé potentielle) puis générer toutes les déchiffrements possibles de $ C $ (encore une fois pour chaque deuxième clé potentielle) et, pour chacun des eux, appelons-le $ C '' $, vérifions si $ C '' $ est égal à certains des textes chiffrés potentiels dans le tableau. En cas de correspondance, nous avons obtenu $ C '' = C '$ et nous avons découvert les deux DES clés. Le nombre total de chiffrements/déchiffrements sera $ 2 ^ 56\fois 2 = 2 ^ 57 $.
Pour des raisons similaires, -DES (trois niveaux de cryptage DES utilisant trois clés différentes) offre la sécurité d'une clé de 112 bits.