libgcrypt - Initialization Vector

Brad Hards bradh at frogmouth.net
Sat Apr 30 01:25:27 CEST 2005


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20050430/f8967bd7/attachment.pgp


More information about the Gcrypt-devel mailing list