Bonjour,

Je travaille sur un module de chiffrement utilisant l’algorithme AES.

Dans un premier temps, je souhaite discuter sur les différents mode d’opérations.

Vu que le mode d’opération ECB n'est pas si sécurisé, je regarde les autres modes.

1) La plus simple est le mode CBC.

Ma question sur le vecteur d'initialisation. Il doit être généré aléatoirement (Je suppose que oui) ? Il doit être de quelle taille ?

Et surtout, le vecteur d'initialisation est-il nécessaire pour le déchiffrement ? Si oui, quand on chiffre un contenu A avec la clef K et qu'on souhaite l'envoyer par réseau. On envoie par exemple VI + AES_Encryption( A, K ) ?

Sur wikipedia je trouve:

"Decrypting with the incorrect IV causes the first block of plaintext to be corrupt but subsequent plaintext blocks will be correct."

Par conséquent, j'envoie également le VI.

Ou sinon, régénérer un nouveau IV pour le déchiffrement et rajouter un premier bloc de donnée inutile et le retirer après le déchiffrement, ceci est une solution également non ?

2) Il est intéressant d’implémenter un chiffrement/déchiffrement en parallèle, par conséquent le seul mode qui offre cette possibilité est le CTR.

Qui peut me clarifier sur le "nonce" et "counter" ?

Sont-ils générés aléatoirement ? Pour chaque bloc un nonce/counter qui dépend du précédent ? Comment ? Quelle taille ? 

Et la meme question que pour CBC. Le nonce/counter doit etre transmis également pour le déchiffrement ?

3) Maintenant une question plus generale sur le chiffrement. (AES ou n'importe).

Je souhaite écrire (pour but éducatif) un module de chiffrement/déchiffrement de fichiers avec AES.

Supposons que mon module en chiffrant remplace les octets du fichier original au fur et a mesure. 

Lors du déchiffrement avec une mauvaise clef, on perd pour toujours le contenu orignal du fichier.

L'idée est d'introduire lors du chiffrement (au début ou a la fin du fichier) un bloc. Ce bloc permettra par la suite de détecter lors du déchiffrement si la clef est correcte ou pas, et donc d’arrêter le processus de déchiffrement. Comment ? Par exemple, un bloc aléatoire A, puis un bloc B qui est le hash (md5 par exemple) du bloc A.

Comme ceci, au déchiffrement, le module se place a la position prédéfinie du bloc A (au début ou a la fin du fichier) déchiffre en mémoire avec la clef donnée les blocs A et B. Calcule le md5 du bloc A déchiffré et le compare avec celui qui est lu.

Bien évidement si le déchiffrement est un succès, les blocs A et B sont supprimes du fichier afin de retrouver exactement le contenu original.

Je souhaite recevoir vos commentaires sur cette approche..ces défauts, des améliorations possibles ?

Je peux lors du chiffrement du fichier texte.txt, au lieu de remplacer les octets, écrire le résultat dans text.aes et supprimer le fichier original une fois le chiffrement termine. Ceci est un plus sur surtout après une coupure du courant pendant l’opération de chiffrement...

De même le déchiffrement prend le text.aes en entrée et commence a écrire texte_dechiffre.txt.

Mais même dans ce cas, je souhaite pouvoir tester la validité de la clef avant le déchiffrement du fichier. Imaginez le cas de fichiers qui font plusieurs Go, on souhaite savoir si la clef est valide ou pas avant de commencer le déchiffrement.

Donc mon idée avec les blocs A et B (md5 de A) vous semblent-ils intéressants ?

Je vous remercie !

Je déplace

Bonne journée

1) l'IV doit être unique le générer aléatoirement est un moyen fiable de le rendre unique.

Sinon l'IV doit être de la même taille que les blocs à chiffrer.

2)En CBC tu n'as pas besoin de l'IV pour déchiffré, ni du résultat du bloc précédent.

Donc oui cela peut être fait en parallèle.

A noter une fois ce premier déchiffrage fait tu n'as pas le test en claire mais un XOR du test en claire avec celui du bloc précédent ou de l'IV dans le cadre du premier bloc.

Tu dois donc refaire des XOR pour récupérer le tests claire. Cette opération est par contre nécessairement séquentiel et nécessite l'IV. (Donc oui tu dois transmettre l'IV qui n'est de toutes façon pas secret et joue juste le rôle de sel).

3) "Supposons que mon module en chiffrant remplace les octets du fichier original au fur et a mesure. "

Si tu fais du CBC tu ne chiffre pas des octets mais des blocs de plusieurs octets.

Sinon remplacer au fur à mesure est une mauvaise idée et vaut mieux reconstitué le fichier à côté.

Pour savoir rapidement si la clé est correcte ou pas généralement se qu'on fait c'est qu'on insère une valeur magique connu au début du fichier qui sera le premier à être chiffré/déchiffré. Si elle n'est pas bonne on arrête le déchiffrement.