Chiffrement AES - Clé versus IV

Question

L'application sur laquelle je travaille permet à l'utilisateur de crypter des fichiers. Les fichiers peuvent être de n'importe quel format (feuille de calcul, document, présentation, etc.).

Pour le fichier d'entrée spécifié, je crée deux fichiers de sortie - un fichier de données cryptées et un fichier de clé. Vous avez besoin de ces deux fichiers pour obtenir vos données originales. Le fichier de clé doit fonctionner uniquement avec le fichier de données correspondant. Il ne doit pas fonctionner avec aucun autre fichier, que ce soit du même utilisateur ou de tout autre utilisateur.

L'algorithme AES nécessite deux paramètres différents pour le cryptage, une clé et un vecteur d'initialisation (IV).

Je vois trois choix pour créer le fichier de clé :

1. Intégrer l'IV codé en dur dans l'application et enregistrer la clé dans le fichier de clé.
2. Intégrer la clé codée en dur dans l'application et enregistrer l'IV dans le fichier de clé.
3. Enregistrer à la fois la clé et l'IV dans le fichier de clé.

Notez qu'il s'agit de la même application utilisée par différents clients.

Il semble que les trois choix atteindraient le même objectif final. Cependant, j'aimerais avoir vos commentaires sur la bonne approche à suivre.

Answer 1

Comme vous pouvez le voir des autres réponses, avoir un IV unique par fichier chiffré est crucial, mais pourquoi?

Tout d'abord - revoyons pourquoi un IV unique par fichier chiffré est important. (Wikipédia sur l'IV). L'IV ajoute de l'aléatoire au début de votre processus de chiffrement. Lorsque vous utilisez un mode de chiffrement de bloc enchaîné (où un bloc de données chiffrées intègre le bloc précédent de données chiffrées), nous sommes confrontés à un problème concernant le premier bloc, c'est là que l'IV entre en jeu.

Si vous n'aviez pas d'IV, et utilisiez un chiffrement de bloc enchaîné avec simplement votre clé, deux fichiers qui commencent par un texte identique produiraient des premiers blocs identiques. Si les fichiers d'entrée changeaient en cours de route, alors les deux fichiers chiffrés commenceraient à diverger à partir de ce point et jusqu'à la fin du fichier chiffré. Si quelqu'un remarquait la similitude au début, et savait par quoi commençait l'un des fichiers, il pourrait déduire par quoi commençait l'autre fichier. Savoir par quoi le fichier en clair commençait et quel est son chiffrement correspondant pourrait permettre à cette personne de déterminer la clé et puis de déchiffrer l'intégralité du fichier.

Ajoutez maintenant l'IV - si chaque fichier utilisait un IV aléatoire, leur premier bloc serait différent. Le scénario ci-dessus a été contrecarré.

Maintenant, qu'en est-il si l'IV était le même pour chaque fichier? Eh bien, nous aurions à nouveau le scénario problématique. Le premier bloc de chaque fichier chiffrera au même résultat. Pratiquement, cela ne diffère pas de ne pas utiliser l'IV du tout.

Alors maintenant parlons de vos options proposées:

Option 1. Incorporer un IV codé en dur à l'intérieur de l'application et enregistrer la clé dans le fichier de clé.

Option 2. Incorporer une clé codée en dur à l'intérieur de l'application et enregistrer l'IV dans le fichier de clé.

Ces options sont pratiquement identiques. Si deux fichiers qui commencent par le même texte produisent des fichiers chiffrés qui commencent par un texte chiffré identique, vous êtes piégé. Cela se produirait dans ces deux options. (En supposant qu'il y ait une clé maîtresse utilisée pour chiffrer tous les fichiers).

Option 3. Enregistrer à la fois la clé et l'IV dans le fichier de clé.

Si vous utilisez un IV aléatoire pour chaque fichier de clé, vous êtes bon. Aucun deux fichiers de clé ne seront identiques, et chaque fichier chiffré doit avoir son fichier de clé. Un fichier de clé différent ne fonctionnera pas.

PS: une fois que vous optez pour l'option 3 et des IV aléatoires - commencez à réfléchir à la manière dont vous déterminerez si le déchiffrement a été réussi. Prenez un fichier de clé d'un fichier, et essayez de l'utiliser pour déchiffrer un autre fichier de chiffrement. Vous pourriez découvrir que le déchiffrement se poursuit et produit des résultats incorrects. Si cela se produit, commencez à vous renseigner sur le chiffrement authentifié.

Answer 2

La chose importante à propos d'un IV est vous ne devez jamais utiliser le même IV pour deux messages. Tout le reste est secondaire - si vous pouvez garantir l'unicité, le hasard est moins important (mais c'est quand même une très bonne chose à avoir!). L'IV n'a pas besoin d'être (et en effet, en mode CBC ne peut pas être) secret.

Par conséquent, vous ne devriez pas enregistrer l'IV aux côtés de la clé - cela impliquerait que vous utilisez le même IV pour chaque message, ce qui va à l'encontre de l'objectif d'avoir un IV. Typiquement, vous ajouteriez simplement l'IV au début du fichier crypté, en clair.

Si vous allez créer vos propres modes de chiffrement de cette façon, veuillez lire les normes pertinentes. Le NIST a un bon document sur les modes de chiffrement ici : http://dx.doi.org/10.6028/NIST.SP.800-38A La génération de l'IV est documentée dans l'Annexe C. La cryptographie est un art subtil. Ne soyez pas tenté de créer des variations sur les modes de chiffrement normaux; 99% du temps, vous créerez quelque chose qui semble plus sécurisé, mais qui est en fait moins sécurisé.

Answer 3

Lorsque vous utilisez un IV, la chose la plus importante est que l'IV soit aussi unique que possible, donc en pratique vous devriez utiliser un IV aléatoire. Cela signifie l'intégrer dans votre application n'est pas une option. Je sauvegarderais l'IV dans le fichier data, car cela ne nuit pas à la sécurité tant que l'IV est aléatoire/unique.

Answer 4

Paires de clés/Iv probablement les plus confuses dans le monde du cryptage. En termes simples, mot de passe = clé + iv. Cela signifie que vous avez besoin d'une clé et d'un iv correspondants pour décrypter un message crypté. Internet semble sous-entendre que vous avez seulement besoin de l'iv pour crypter et le jeter, mais il est également nécessaire pour décrypter. La raison de séparer les valeurs clé/iv est de permettre de crypter les mêmes messages avec la même clé mais en utilisant un iv différent pour obtenir des messages cryptés inégaux. Ainsi, Encrypt("message", clé, iv) != Encrypt("message", clé, ivDifférent). L'idée est d'utiliser une nouvelle valeur Iv aléatoire à chaque fois qu'un message est crypté. Mais comment gérez-vous une valeur Iv changeante? Il y a un million de possibilités, mais la manière la plus logique est d'intégrer les 16 octets de l'Iv dans le message crypté lui-même. Ainsi, crypté = Iv + messageCrypté. De cette manière, la valeur Iv en constante évolution peut être extraite et retirée du message crypté puis décryptée. Donc messageDécrypté = Decrypt("messageSansIv", clé, IvDuMessageCrypté). Alternativement, si vous stockez des messages cryptés dans une base de données, l'Iv peut être stocké dans un champ là-bas. Bien que l'Iv fasse partie du secret, il est minuscule en comparaison des 32 bits de la clé et n'est jamais réutilisé, il est donc pratiquement sûr de l'exposer publiquement. Gardez à l'esprit, l'iv n'a rien à voir avec le cryptage, il a à voir avec le masquage du cryptage de messages ayant le même contenu.

Answer 5

IV est utilisé pour augmenter la sécurité via aléatoire, mais cela ne signifie pas qu'il est utilisé par tous les algorithmes, c'est-à-dire

La chose astucieuse est de savoir quelle devrait être la longueur de l'IV? En général, il est de la même taille que la taille du bloc ou de la taille du chiffrement. Par exemple, AES aurait 16 octets pour l'IV. De plus, le type d'IV peut également être sélectionné, c'est-à-dire eseqiv, seqiv, chainiv ...