2012-09-10 8 views
2

je l'application de test suivant:chiffrement et limite ByteString

import Codec.Crypto.AES 
import qualified Data.ByteString.Char8 as B 

key = B.pack "Thisismykey....." 

iv = B.pack "0000000000000001" 

main = do 
    let myenc = crypt' CTR key iv Encrypt (B.pack "1234567812345678") 
    print (B.unpack myenc) 

qui imprime le résultat suivant: "\ 250 \ DC4 \ DC4 \ 255 \ 223 \ 221C \ ETBx \ 239sF \ nuZu"

Si je change le texte clair "1234567812345678" dans "1234567812345688" je reçois "\ 250 \ DC4 \ DC4 \ 255 \ 223 \ 221C \ ETBx \ 239sF \ nuUu"

Si je change le texte clair à "1134567812345678" Je reçois la sortie "\ 250 \ ETB \ DC4 \ 255 \ 223 \ 221C \ ETBx \ 239sF \ nuZu "

Je suis maintenant très surpris car il y a clairement une corrélation prévisible entre l'entrée et la sortie que IMHO ne devrait pas se produire. Si je change quelque chose à l'avant du texte, alors seulement l'avant de la sortie est affectée, etc. Est-ce que cela peut être dû à des limites de 8 ou 16 octets de chaînes d'octets et comment pourrais-je résoudre ce problème? Est-ce que quelque chose m'égare ici?

Indépendamment du mode CTR, il convient de noter que AES fonctionne avec des baies 4x4 octets et la question concerne le cryptage d'un seul tableau. À mon sens, AES devrait effectuer quatre cycles de mélange et le changement d'un seul octet (sur 16) devrait entraîner au moins 50% de bits différents. Ainsi, à mon avis, il ne peut pas être que les changements à la fin d'un texte en clair de 16 octets changent exactement la fin du texte chiffré et les changements à l'avant changent le front etc. À ma compréhension, la IV entre en jeu comme un compteur lorsque plusieurs réseaux 4x4 sont impliqués.

Répondre

7

Cela n'a rien à voir avec haskell.

Lire http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Initialization_vector_.28IV.29

Puisque vous utilisez le même IV pour chiffrer le message deux fois en mode CTR il est pas sûr. Lisez des informations sur les algorithmes de cryptographie et essayez d'éviter d'écrire votre propre code crypto car il est plus susceptible d'avoir des failles de sécurité.

L'exigence du mode CTR est (clé, IV) paire doit être unique. La solution triviale générerait une nouvelle IV pour chaque nouveau message que vous crypteriez.

[explication de faille de sécurité du mode CTR] https://crypto.stackexchange.com/questions/2991/why-must-iv-key-pairs-not-be-reused-in-ctr-mode

En mode CTR F (IV + compteur, clé) XOR Plaintext = CIPHER .. donc si nonce et la clé restent même alors F est la même pour les deux la plaine texte .. donc, si $ C_1 $ est chiffré de $ et $ P 1 C_2 $ est chiffré de p_2 $ $, alors

xor($C_1$,$C_2$) = xor($P_1$,$P_2$) for same (key,IV) pair 

Code de soutien:

import Codec.Crypto.AES 
import qualified Data.ByteString.Char8 as B 
import qualified Data.ByteString as BS 
import Data.Bits (xor) 

key = B.pack "Thisismykey....." 

iv = B.pack "1234567891012131" 
p1 = (B.pack "1234567812345678") 
p2 = (B.pack "1234567812345688") 
x = crypt' CTR key iv Encrypt p1 
y = crypt' CTR key iv Encrypt p2 

main = do 
    print $ BS.zipWith xor x y 
    print $ BS.zipWith xor p1 p2 

sortie

[0,0,0,0,0,0,0,0,0,0,0,0,0,0,15,0] 
[0,0,0,0,0,0,0,0,0,0,0,0,0,0,15,0] 
+0

Je pense que vous n'avez pas raison. La réutilisation d'un IV dans le CTR rend l'information non sécurisée dans le cas où les communications seraient interceptées. Cela n'influence pas le principe de la non-prédictibilité, je pense. J'aurais pu utiliser 'B.empty' comme IV ici et IMHP mon exemple serait encore valide. –

+4

@JFritsch Voir le lien stackexchange que j'ai fourni. Votre texte chiffré n'est pas prévisible pour une clé unique, des paires IV. Le problème est donné 1 texte chiffré et son texte brut, vous pouvez prédire l'autre texte de chiffrement du deuxième texte brut lorsque vous utilisez la même paire (clé, IV). – Satvik

+0

Non applicable À mon humble avis. AES utilise une matrice 4x4. Par conséquent, tout ce que je change dans un tableau de 16 octets/string/cleartext ** doit ** conduire à une sortie où au moins 50% des bits sont changés. Sinon, l'implémentation est erronée. Ne pas tenir compte des IVs. –