bpgcrypt at itaparica
Apr 9, 2009, 9:31 AM
Post #1 of 2
Bug in gcry_mpi_set_flag plus feature request
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):
err = gcry_control(GCRYCTL_INIT_SECMEM, 1);
assert(! gcry_mpi_scan(&h, GCRYMPI_FMT_HEX, "1234", 0, NULL));
assert(gcry_mpi_cmp_ui(h, 0x1234) == 0);
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);
Output when run:
> demo: mpiutil.c:199: mpi_set_secure: Assertion `!ap' failed.
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