Mailing List Archive

On Thu, Apr 28, 2005 at 01:38:31PM -0400, Tod Thomas wrote:

> My understanding from reading the libgcrypt info is that the
> Initialization Vector "is a non-secret random string acting as a
> kind of salt value".
[...]
> Once I change the IV in one I no longer get the correct, decrypted
> string back. I discovered this because I decided to make my IV a
> truly random value by using the output of gcry_randomize to set it
> and that failed.

Well, the IV needs to be the same for encryption and decryption; this
is so, since it has direct influence on the ciphertext (in case of
encryption) and plaintext (in case of decryption).

Moritz

--
Moritz Schulte

On Fri, 29 Apr 2005 03:38 am, Tod Thomas wrote:
> I wrote two seperate programs using libgcrypt, one to perform encryption
> and one to perform decryption. Whan I pass a string to the encryption
> module and then pipe its output to the decryption module I get the
> correct value returned - as long as the IV is the same.
This is the correct usage.

> Once I change the IV in one I no longer get the correct, decrypted
> string back. I discovered this because I decided to make my IV a truly
> random value by using the output of gcry_randomize to set it and that
> failed.
This is the intended behaviour. As Moritz explained, the ciphertext is a
function of the plain text, the key and the IV. The IV is intended to protect
from the case when you use the same key over and over, and you might encrypt
the same plaintext. In this case, if you don't have a salt/IV anyone who can
see the ciphertext knows that it the plaintext. IV also makes dictionary
attacks much harder.

> My question then is if the IV should behave as the documentation
> suggests why isn't my test working? I suspect I have misunderstood
> something in the reading or in my implementation, just not sure what.
>
> I'll be happy to provide more details upon request.
Can you tell me which part of the documentation led you think it might be OK
to use a different IV for encryption and decryption? I can take a look at
it, and perhaps propose some changes.

Brad

Brad Hards wrote:
> On Fri, 29 Apr 2005 03:38 am, Tod Thomas wrote:
>
>>I wrote two seperate programs using libgcrypt, one to perform encryption
>>and one to perform decryption. Whan I pass a string to the encryption
>>module and then pipe its output to the decryption module I get the
>>correct value returned - as long as the IV is the same.
>
> This is the correct usage.
>
>
>>Once I change the IV in one I no longer get the correct, decrypted
>>string back. I discovered this because I decided to make my IV a truly
>>random value by using the output of gcry_randomize to set it and that
>>failed.
>
> This is the intended behaviour. As Moritz explained, the ciphertext is a
> function of the plain text, the key and the IV. The IV is intended to protect
> from the case when you use the same key over and over, and you might encrypt
> the same plaintext. In this case, if you don't have a salt/IV anyone who can
> see the ciphertext knows that it the plaintext. IV also makes dictionary
> attacks much harder.

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?

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?

>>My question then is if the IV should behave as the documentation
>>suggests why isn't my test working? I suspect I have misunderstood
>>something in the reading or in my implementation, just not sure what.
>>
>>I'll be happy to provide more details upon request.
>
> Can you tell me which part of the documentation led you think it might be OK
> to use a different IV for encryption and decryption? I can take a look at
> it, and perhaps propose some changes.

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.

The statement the IV "is a non-secret random string acting as a kind of
salt value." gave me the impression it was a random number that was
somehow used by the encryption algorithm to provide a set of random
numbers to be used in the encryption process.

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.

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.

Please bear with me, I'm just learning the inner workings of encryption
so my conceptual knowledge is just beginning to grow.


Thanks - Tod

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

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