libgcrypt - Initialization Vector

[Tod Thomas]

Brad Hards wrote:
> On Fri, 29 Apr 2005 23:47 pm, Tod Thomas wrote:
> 
>>But what if I take my testing scenario from above and rather than
>>running them both on the same machine piping the output of one to the
>>other, instead run each program on a seperate machine?
> 
> You must have the same IV on each machine.
> 
> 
>>Using your description wouldn't I have to pass the IV's value along with
>>the ciphertext to be able to decrypt it on the other end?  Wouldn't I
>>then have the burden of passing the IV in a secured fashion instead of
>>just needing to pass the resulting ciphertext?  Maybe I wouldn't want to
>>use symmetric encryption for that kind of task?
> 
> The IV doesn't need to remain secret. You can pass it any way you like.
> 
> 
>>What I want to do is be able to encrypt a value using libgcrypt and then
>>provide the decryption algorithm to an internal customer so they can
>>decrypt it for their own purposes.
> 
> OK.
> 
> 
>>I see now that it is more of a random value used to 'mask' the key value
>>on an encryption by encryption basis.  But this unique quality prevents
>>its value from being reproduced, requiring that it somehow be made
>>available to the process that will ultimately perform the decryption.
> 
> I think of it as an extra bit of plain text that goes at the front of the 
> plain text, that masks the plain text and makes it harder for an attacker to 
> pre-compute all the possible plaintext/ciphertext combinations.
> 
> 
>>This would mean either the decryption routine would need to know how to
>>replicate the salt (not likely due to its randomness) or have it passed
>>as a value along with the ciphertext.
> 
> You must pass it.
> 
> 
>>Please bear with me, I'm just learning the inner workings of encryption
>>so my conceptual knowledge is just beginning to grow.
> 
> It would be well worth looking at how Electronic Code Book mode varies from 
> Cipher Block Chaining mode. ECB works on just a key, and has some serious 
> limitations / weaknesses if you don't use it exactly as intended. CBC (or 
> CFB, or OFB - look those up too!) is much more robust.
> 
> Brad

Will do.  Thanks for the feedback.


Tod