gcry_cipher_decrypt usage

Joe the Shmoe news at edrusb.is-a-geek.org
Thu Apr 7 10:55:11 CEST 2011


Werner Koch wrote:
> On Wed,  6 Apr 2011 20:35, news at edrusb.is-a-geek.org said:
> 
>> In other words, when a buffer of ciphered data is given to
>> gcry_cipher_decrypt, how is it possible to know the amount of clear text
>> data that has been produced?
> 
> That depends on the cipher mode.  Almost all modes return the same
> number of bytes as you put in.  Can you please give a more explicit
> example?

Sure,

the context is the one of an archiver program ("Disk ARchive") when
comes the time to read an encrypted archive.

Cipher used is blowfish. In this buggy situation, gcry_cipher_decrypt()
receives 10248 bytes of input, which in fact do contain 10240 bytes of
ciphered data followed by 8 bytes of clear data.

The fact that clear data is located after the ciphered data is not
possible to know when gcry_cipher_decrypt() is called that time, thus as
this call do not return any error, it is (wrongly) assumed that
gcry_cipher_decrypt() could decrypt 10248 bytes of data and provided the
same amount of plain text data into the output buffer.

At that time, this decrypted data is sent to its destination and the
next block of data is treated by gcry_cipher_decrypt(). This second
time, gcry_cipher_decrypt() returns an error as expected, because the
data is no more encrypted at all. At that time, reading the clear text
data directly I get the information that the clear data started 8 bytes
before ... but that's too late, the previous 8 bytes have already been
wrongly sent to destination.

Thus, my question is not how much clear data, for a given amount of
ciphered data a given algorithm do provide _in theory_, but rather how
to know whether a given ciphered block of data could successfully be
deciphered completely or partially. The best would be to have
gcry_cipher_decrypt() being able to provide the effective amount of
clear data available in the output buffer. But having
gcry_cipher_decrypt() failing if all the provided data could not be
decrypted would also solve my problem.

I have re-read documentation, reviewed libgcrypt header file for any
undocumented call, but I'm affraid to have to change the implementation
of Disk ARchive after having passed from openssl to libgcrypt dependancy?

Thanks for any help,

Kind Regards,
"Joe the Shmoe" aka Denis Corbin.











More information about the Gcrypt-devel mailing list