Crypto IV/salt

Crypto IV/salt - Algo - Programmation

Marsh Posté le 25-02-2010 à 17:39:31    

Bonjour,
 
je me pose quelques questions sur les systèmes de crypto (je n'y connais pas grand chose)... je code en C# (framework 2) et j'ai besoin de générer des fichiers cryptés qui seront décryptés et réutilisés ultérieurement dans une autre session de l'appli.
 

Code :
  1. byte[] salt = new byte[] { 2, 0, 0, 0, 0, 0, 0, 0 };
  2. byte[] iv = new byte[] { 0, 0, 0, 0, 0, 0, 0, 0 };
  3. PasswordDeriveBytes cdk = new PasswordDeriveBytes("P@$$w0rd", salt);
  4. byte[] key = cdk.CryptDeriveKey("RC2", "SHA1", 128, iv);
  5. RC2CryptoServiceProvider rc2 = new RC2CryptoServiceProvider();
  6. rc2.Key = key;
  7. rc2.IV = new byte[] { 21, 22, 23, 24, 25, 26, 27, 28 };


Le tout étant utilisé dans un cryptostream.
 
Etant donné qu'il faut que l'appli soit capable de décrypter utlérieurement j'imagine que le salt et le IV doivent être figés n'est ce pas ?
Si c'est bien vrai, est-ce bien utile de les définir ?
Est-ce bien sécure de laisser le password, le IV, le salt en dur dans le code ?
Si non comment procéder ?
 
Merci d'avance pour votre aide. :jap:

Reply

Marsh Posté le 25-02-2010 à 17:39:31   

Reply

Marsh Posté le 16-03-2010 à 15:57:44    

Le vecteur d'initialisation découle du mode d'opération de l'algorithme qui assure avec davantage de certitude qu'une même valeur ne sera pas chiffrée deux fois de la même façon, en combinant chaque texte chiffré avec le texte précédent. Le vecteur d'initialisation permet de définir l'état précédant le premier texte à chiffrer. Si tu le laisses à zéro, le premier texte chiffré sera facilement détectable, et compromet la sécurité de tous les textes suivants. Et si tu le mets en clair, c'est pire. Le secret du vecteur d'initialisation est au moins aussi important que la clé.
 
Le salt est un truc ajouté au chiffrement pour complexifier la chose. En supposant que tu rajoutes une valeur comprise entre 0 et 9 à chaque message que tu chiffres, ça multiplie le nombre de possibilités par 10. Par conséquent, ça multiplie la complexité d'une attaque bruteforce par 10. Dans le cas d'un nombre de 64 bits, ça la multiplie par 18 446 744 073 709 551 616. Donc en laissant le salt à 0, où en le laissant en clair de telle façon qu'un attaquant pourra facilement le trouver, ça diminue grandement la sécurité. Le secret du salt est au moins aussi important que celui de la clé.
 
Et si tu laisses le mot de passe, le vecteur d'initialisation, et le salt en dur dans le code... pourquoi chiffrer les données ?
 
Après, tout dépend de l'utilisation que tu en auras. Chaque solution nécessite une mise en oeuvre différente, et il serait nécessaire de savoir ce que tu cherches exactement à faire avant de voir si ta méthode est la bonne.

Reply

Marsh Posté le 16-03-2010 à 23:02:26    

Merci pour la réponse.
 
Au final je cherche surtout à savoir comment coder correctement une fonction de cryptage/décryptage dans une appli sans laisser quoi que ce soit en dur dans le code. Peut-être existe t'il un tuto ou une adresse assez complète sur le sujet ?

Reply

Marsh Posté le 17-03-2010 à 09:59:22    

Ben ça dépend de ce que tu cherches à faire avec ta fonction de chiffrement ensuite.
 
La cryptologie se repose UNIQUEMENT sur le secret de la méthode utilisée pour chiffrer et déchiffrer, ce qui comprend l'algorithme, la clé, le salt, l'IV, les tables de substitution s'il y en a, les sous-clés, l'état du PRNG... bref, tout ce qui entre dans les procédés de chiffrement et de déchiffrement.
Si tous sont laissés en clair, la sécurité est nulle.
 
Par conséquent, ces différentes valeurs sont soit stockées en clair, généralement non pas dans le code, mais dans un fichier de configuration à côté de façon à pouvoir éventuellement les modifier sans avoir à modifier le programme, voire les supprimer pour des raisons de sécurité, soit pour la plupart générées en direct, et échangées entre les interlocuteurs par un maximum de moyens différents, de façon à ce que la probabilité d'interception de toutes ces valeurs soit la plus basse possible. Cela permet également d'avoir des valeurs qui changent tout le temps, et de limiter les attaques, car si elles sont découvertes, elles changeront de toute façon à la prochaine opération. Et évidemment, seule une trace en mémoire est conservée, et celle-ci ne tient que tant que l'application est toujours lancée.
 
Reste ensuite à savoir où peut se trouver l'attaquant.
S'il s'agit de sécuriser une communication, alors il faut échanger les clés par un autre moyen que par cette communication. S'il s'agit de protéger un système par un mot de passe, il faut que ce mot de passe soit uniquement connu de ceux qui y ont accès, et que le système ne garde que des traces minimales permettant tout au plus d'effectuer une corrélation, mais sans conserver le mot de passe en clair de façon à empêcher quiconque de le récupérer. S'il s'agit de chiffrer un fichier, tous les moyens de déchiffrement doivent être uniquement connus du propriétaire du fichier et absolument aucune trace, hormis l'algorithme évidemment, ne doit rester.
 
Apparemment tu veux chiffrer des fichiers, mais reste à savoir pourquoi tu veux le faire, qui est susceptible de casser le chiffrement, quelle est l'importance des données chiffrées... car chaque méthode correspond à un but bien précis, et il ne suffit pas d'appliquer un algorithme pour que ce soit sécurisé ;)

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed