Cryptage AES - clé contre IV
L'application sur laquelle je travaille permet à l'utilisateur de chiffrer 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é et un fichier de clé. Vous avez besoin de ces deux fichiers pour obtenir vos données d'origine. Le fichier de clé ne doit fonctionner que sur le fichier de données correspondant. Il ne devrait fonctionner sur aucun autre fichier, ni du même utilisateur ni 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é:
- Intégrez le code IV codé en dur dans l'application et enregistrez la clé dans le fichier de clés.
- Intégrez la clé codée en dur dans l'application et enregistrez le vecteur d'initialisation dans le fichier de clé.
- Enregistrez la clé et le vecteur IV dans le fichier de clé.
Notez que c'est la même application qui est utilisée par différents clients.
Il semble que les trois choix atteignent le même objectif final. Cependant, j'aimerais connaître votre avis sur la bonne approche.
Comme vous pouvez le constater dans les autres réponses, il est crucial d’avoir une IV unique par fichier crypté, mais pourquoi?
Premièrement, voyons pourquoi un IV unique par fichier crypté est important. ( Wikipedia sur IV ). Le IV ajoute aléatoire à votre début de votre processus de cryptage. Lorsque vous utilisez un mode de cryptage par bloc chaîné (où un bloc de données cryptées incorpore le bloc précédent de données cryptées), il nous reste un problème concernant le premier bloc, celui dans lequel l'IV entre en jeu.
Si vous n'aviez pas de système IV et utilisiez le cryptage de blocs chaînés avec uniquement votre clé, deux fichiers commençant par un texte identique produiront des premiers blocs identiques. Si les fichiers d'entrée changent en cours de route, les deux fichiers cryptés commenceront à avoir un aspect différent à partir de ce moment-là et jusqu'à la fin du fichier crypté. Si quelqu'un remarquait la similitude au début et savait par quoi un des fichiers avait commencé, il pourrait en déduire le nom de l'autre fichier. Le fait de savoir par quoi le fichier en texte brut a commencé et son texte chiffré correspondant pourrait permettre à cette personne de déterminer la clé, puis de déchiffrer le fichier entier.
Ajoutez maintenant le IV - si chaque fichier utilisait un IV aléatoire, leur premier bloc serait différent. Le scénario ci-dessus a été contrecarré.
Maintenant que se passe-t-il si l'IV était le même pour chaque fichier? Eh bien, nous avons à nouveau le scénario du problème. Le premier bloc de chaque fichier chiffrera le même résultat. En pratique, ce n’est pas différent de ne pas utiliser la perfusion du tout.
Alors maintenant, passons aux options proposées:
Option 1. Intégrez le code IV codé en dur dans l'application et enregistrez la clé dans le fichier de clés.
Option 2. Intégrez la clé codée en dur dans l'application et enregistrez le vecteur d'initialisation dans le fichier de clé.
Ces options sont à peu près identiques. Si deux fichiers commençant par le même texte produisent des fichiers chiffrés commençant par un texte chiffré identique, vous êtes bloqués. Cela se produirait dans les deux cas. (En supposant qu’une clé principale soit utilisée pour chiffrer tous les fichiers).
Option 3. Enregistrez la clé et le vecteur IV dans le fichier de clés.
Si vous utilisez un IV aléatoire pour chaque fichier de clé, vous êtes bon. Deux fichiers de clé ne seront jamais identiques et chaque fichier crypté doit avoir son fichier de clé. Un fichier de clé différent ne fonctionnera pas.
PS: Une fois que vous avez choisi l'option 3 et les IV aléatoires, commencez à regarder comment vous allez déterminer si le déchiffrement a réussi. Prenez un fichier de clé d'un fichier et essayez de l'utiliser pour déchiffrer un autre fichier de chiffrement. Vous découvrirez peut-être que le déchiffrement se poursuit et produit des résultats erronés. Si cela se produit, commencez la recherche sur cryptage authentifié .
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 assurer l'unicité, le hasard est moins important (mais c'est quand même une très bonne chose à avoir!). Il n’est pas nécessaire que le IV soit (et même en mode CBC ne peut pas être) secret.
En tant que tel, vous ne devriez pas enregistrer le IV à côté de la clé - cela impliquerait que vous utilisiez le même IV pour chaque message, ce qui irait à l'encontre du point de savoir si vous avez un IV. En règle générale, vous devez simplement ajouter le vecteur IV au fichier chiffré, en clair.
Si vous envisagez de lancer vos propres modes de chiffrement comme celui-ci, veuillez lire les normes correspondantes. Le NIST possède un bon document sur les modes de chiffrement ici: http://dx.doi.org/10.6028/NIST.SP.800-38A La génération IV est documentée à 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éez quelque chose qui semble plus sécurisé, mais en fait moins sécurisé.
Lorsque vous utilisez une intraveineuse, le plus important est que celle-ci soit aussi unique que possible. En pratique, vous devriez donc utiliser une intraveineuse aléatoire. Cela signifie que l’intégrer dans votre application n’est pas une option. Je voudrais enregistrer l'IV dans le fichier data , car il ne nuit pas à la sécurité tant que l'IV est aléatoire/unique .