Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: GnuPG: gcrypt

Is gcry_ac_data_encrypt_scheme() not re-entrant?

 

 

GnuPG gcrypt RSS feed   Index | Next | Previous | View Threaded


mastermanu2004 at gmail

Jul 17, 2008, 7:06 PM

Post #1 of 2 (997 views)
Permalink
Is gcry_ac_data_encrypt_scheme() not re-entrant?

The libgcrypt manual states that multi-threading should not be an
issue, but some behavior I observed prompted me to ask some questions
about this property.

Let us say that I am using 2048-bit RSA (256 byte blocks) and I that
wish to encrypt two separate strings.

I initialize the appropriate gcry_ac_io_t structures and then make a
call to gcry_ac_data_encrypt_scheme as follows:

int encrypt_message(struct crypto_context *cntxt, unsigned char
*message, size_t num_bytes,
unsigned char **cipher, size_t *cipher)
{
gcry_ac_io_t io_plaintext;
gcry_ac_io_t io_cipher;


gcry_ac_io_init(&io_plaintext, GCRY_AC_IO_READABLE, GCRY_AC_IO_STRING,
message, num_bytes);

gcry_ac_io_init(&io_cipher, GCRY_AC_IO_WRITABLE, GCRY_AC_IO_STRING,
&cipher, &cipher_size);

err = gcry_ac_data_encrypt_scheme (cntxt->handle,
GCRY_AC_ES_PKCS_V1_5, 0, NULL, pub_key,
&io_plaintext, &io_cipher);
}

I encrypt the first string as follows:
encrypt_message(my_context, "my string 1", 12, &BUFFER, &BUFFER_SIZE);
The result is that a pointer to a cipher array of size 256 bytes is
placed in BUFFER,
which is precisely what I want.


I then encrypt the second string:
encrypt_message(my_context, "my string 2", 12, &BUFFER2, &BUFFER_SIZE2)

Here is where the issue is. Rather than generating a new array and
placing the cipher for
string 2 in it, it concatenates this cipher for string 2 with the
cipher for string 1! Thus,
BUFFER2 points to BUFFER (assuming a re-allocation gave it the same
pointer) and BUFFER_SIZE
is now 512 bytes! But I really just wanted two disparate cipher
buffers of 256 bytes each!

Quick questions regarding this behavior:

1) Is there a way around the results described above? In particular,
can it be the way I want it to be -
each cipher is allocated in its own array rather than successive
ciphers being concatenated together?
Or do I have to do this manually (i.e. copy chunks of 256 bytes of
cipher into their own arrays).
An alternative way to pose this question is: Can I "clear" the
state so that the next cipher I generate
is in its own array?

2) More importantly, is this re-entrant? If I have multiple threads
(each with their own gcry_ac_handle_t),
then is there a risk of thread 2's cipher being placed
contiguously after thread 1's cipher? (This issue would
make it impossible to use the encrypt_scheme() methods in a MT environment).

Is this also expected behavior?

Thanks,
Manu

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel


mastermanu2004 at gmail

Jul 17, 2008, 8:37 PM

Post #2 of 2 (933 views)
Permalink
Re: Is gcry_ac_data_encrypt_scheme() not re-entrant? [In reply to]

Nevermind, I did not realize that the value of *cipher when passed to
gcry_ac_io_init() needs to be NULL to avoid
regrowing the array.

(Also, the ampersands should not be there for initializing the second
gcry_ac_io_t struct although that was a typo
in the email and independent of the issue I was encountering).

On Thu, Jul 17, 2008 at 7:06 PM, Manu Srivastava
<mastermanu2004 [at] gmail> wrote:
> The libgcrypt manual states that multi-threading should not be an
> issue, but some behavior I observed prompted me to ask some questions
> about this property.
>
> Let us say that I am using 2048-bit RSA (256 byte blocks) and I that
> wish to encrypt two separate strings.
>
> I initialize the appropriate gcry_ac_io_t structures and then make a
> call to gcry_ac_data_encrypt_scheme as follows:
>
> int encrypt_message(struct crypto_context *cntxt, unsigned char
> *message, size_t num_bytes,
> unsigned char **cipher, size_t *cipher)
> {
> gcry_ac_io_t io_plaintext;
> gcry_ac_io_t io_cipher;
>
>
> gcry_ac_io_init(&io_plaintext, GCRY_AC_IO_READABLE, GCRY_AC_IO_STRING,
> message, num_bytes);
>
> gcry_ac_io_init(&io_cipher, GCRY_AC_IO_WRITABLE, GCRY_AC_IO_STRING,
> &cipher, &cipher_size);
>
> err = gcry_ac_data_encrypt_scheme (cntxt->handle,
> GCRY_AC_ES_PKCS_V1_5, 0, NULL, pub_key,
> &io_plaintext, &io_cipher);
> }
>
> I encrypt the first string as follows:
> encrypt_message(my_context, "my string 1", 12, &BUFFER, &BUFFER_SIZE);
> The result is that a pointer to a cipher array of size 256 bytes is
> placed in BUFFER,
> which is precisely what I want.
>
>
> I then encrypt the second string:
> encrypt_message(my_context, "my string 2", 12, &BUFFER2, &BUFFER_SIZE2)
>
> Here is where the issue is. Rather than generating a new array and
> placing the cipher for
> string 2 in it, it concatenates this cipher for string 2 with the
> cipher for string 1! Thus,
> BUFFER2 points to BUFFER (assuming a re-allocation gave it the same
> pointer) and BUFFER_SIZE
> is now 512 bytes! But I really just wanted two disparate cipher
> buffers of 256 bytes each!
>
> Quick questions regarding this behavior:
>
> 1) Is there a way around the results described above? In particular,
> can it be the way I want it to be -
> each cipher is allocated in its own array rather than successive
> ciphers being concatenated together?
> Or do I have to do this manually (i.e. copy chunks of 256 bytes of
> cipher into their own arrays).
> An alternative way to pose this question is: Can I "clear" the
> state so that the next cipher I generate
> is in its own array?
>
> 2) More importantly, is this re-entrant? If I have multiple threads
> (each with their own gcry_ac_handle_t),
> then is there a risk of thread 2's cipher being placed
> contiguously after thread 1's cipher? (This issue would
> make it impossible to use the encrypt_scheme() methods in a MT environment).
>
> Is this also expected behavior?
>
> Thanks,
> Manu
>

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

GnuPG gcrypt RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.