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

Mailing List Archive: GnuPG: gcrypt

Bug in gcry_mpi_set_flag plus feature request

 

 

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


bpgcrypt at itaparica

Apr 9, 2009, 9:31 AM

Post #1 of 2 (1210 views)
Permalink
Bug in gcry_mpi_set_flag plus feature request

Hi list,

in a cryptographic application I work with hexadecimal representations of
large numbers and I use libgcrypt to implement some arithmetic on these.
I am also extensively using gcrypt's capabilities of using secure memory.

In this email I describe a bug in libgcrypt. In addition I humbly present
a feature request. Have a look at this .c-file (also attached to this email):


#include <stdio.h>
#include <gcrypt.h>
#include <assert.h>

int main()
{
gcry_error_t err;
gcry_mpi_t h;
assert(gcry_check_version("1.4.1"));
err = gcry_control(GCRYCTL_INIT_SECMEM, 1);
assert(! gcry_err_code(err));

assert(! gcry_mpi_scan(&h, GCRYMPI_FMT_HEX, "1234", 0, NULL));
gcry_mpi_set_flag(h, GCRYMPI_FLAG_SECURE);
assert(gcry_mpi_cmp_ui(h, 0x1234) == 0);
gcry_mpi_release(h);

assert(! gcry_mpi_scan(&h, GCRYMPI_FMT_HEX, "0000", 0, NULL));
//h = gcry_mpi_new(0);
gcry_mpi_set_flag(h, GCRYMPI_FLAG_SECURE); // THIS TRIGGERS AN ASSERTION()
assert(gcry_mpi_cmp_ui(h, 0x0000) == 0);
gcry_mpi_release(h);
}

Output when run:
> demo: mpiutil.c:199: mpi_set_secure: Assertion `!ap' failed.
> Aborted


The second part of the code does nothing but to parse the hexadecimal
number "1234" and to store it in secure memory. Subsequently it is verified
that the conversion was correct.

The third part does the same with the number "0000". When flagging the
mpi as to be stored in secure memory an assertion is triggered. Why that?
If, on the other hand, the mpi is initialized directly to zero
("h = gcry_mpi_new(0)"), the assertion is not triggered.
There seems to be a bug in gcry_mpi_scan or gcry_mpi_set_flag.

And here is my feature request: according to the documentation there is no
possibility to scan a hexadecimal encoded number directly to secure memory.
Of course the code presented above contains a race condition: if the
operating system decides to swap out the program memory just between a
mpi_scan and a mpi_set_flag call an attacker can read back the secret
number from harddisk.
Please add a possibility to scan a hexstring to a secured gcrypt_mpi_t
directly!

kind regards,
bp
Attachments: demo.c (0.62 KB)


wk at gnupg

Apr 9, 2009, 10:24 AM

Post #2 of 2 (1080 views)
Permalink
Re: Bug in gcry_mpi_set_flag plus feature request [In reply to]

On Thu, 9 Apr 2009 18:31, bpgcrypt [at] itaparica said:

> The third part does the same with the number "0000". When flagging the
> mpi as to be stored in secure memory an assertion is triggered. Why that?

Good catch. This is likely because we try not allocate any limbs for a
number with the value 0. To set something to secure we do this on the
memory for the limb data and the assert checks that there is any data
allocated. Sure, the assert is wrong. I'll fix that next week.

> And here is my feature request: according to the documentation there is no
> possibility to scan a hexadecimal encoded number directly to secure memory.
> Of course the code presented above contains a race condition: if the

Well, I can change that. The hex data scanning was initially only used
for testing and is based on some very old code. I'll look into this.


Salam-Shalom,

Werner


--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
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.