cryptography - Use of Initialization Vector in DES -

say have encrypt data using des (or triple des). if iv used 8 bytes, set '0' (ie. iv constant byte[], set 0x00), okay? or same using no iv in first place?

it no good. hard-coded iv means same plain text encrypt same cipher text. iv intended prevent. if use mode allows iv @ all, approach randomly generate iv, use in encryption on blocks of plain text want encrypt, , prepend iv unencrypted cipher text.

many people worry "won't would-be attacker see iv then?" answer yes, doesn't matter. key needs secret. iv not need secret enhance security of encryption dramatically. does, however, need random.

note not enough thwart active attacker. enough thwart passive eavesdropper.

edit: ok, explain why won't stop active attacker best recall attack. explanation, consider cipher block chaining (cbc) because commonly used. you'll have extrapolate explanation other modes. cipher block chaining xors first block of message iv , encrypts block happen under ecb mode. output of encryption cipher text block 1, xored message block 2 before block encrypted. output xored block after way end.

now decrypt, decrypt first block of cipher text in ecb mode, , xor same iv used on encrypt. yields plain text because in total encrypted , decrypted , xored iv twice, , these 2 xors cancel 1 out. take cipher text block 1 (not plain text, mind you) , after decrypting block 2, xor output preceding cipher text block.

ok, briefly review how cbc works. round trip message cipher text message block, then, xor-encrypt-decrypt-xor 2 xors cancelling 1 out. let me keep extremely simple , imagine super silly example large amount of money wired account. details arranged except account number, , requested.

so alice sending account number bob, , not lose point of explanation among details, imagine account number 10 decimal digits long , therefore fits in single block of aes few bytes of padding spare. encrypts account number wants send money to: 1234567890, xors output of encryption iv, , sends iv , encrypted account number bob @ bank processing.

except eve operating router between alice , bob. supposing knows alice planning wire money account 1234567890 , making educated guess content of encrypted block, can steal wire.

to this, takes original iv , xors 1234567890. xors result own account number 4564564560. replaces original iv final output and, leaving cipher text block untouched, forwards on bob. bob decrypts block , gets have gotten original cipher text block. except when xors iv, not 1234567890 padding plain text; gets 4564564560. transfers money eve per instructions received (but not ones alice sent).

this same tampering possible longer messages long attacker considers garbled plain text on recipient side acceptable. won't explain why here, should apparent if think can make block x decrypt long can correctly guess original plain text , ok block x-1 decrypting random noise.

using mac (as of well-known protocols such ssl, tls, ipsec do) 1 way shore vulnerability of raw cbc attack. it's recommended use 1 of protocols unless there reason cannot so.