From bpgcrypt at itaparica.org  Thu Apr  9 18:31:26 2009
From: bpgcrypt at itaparica.org (bpgcrypt at itaparica.org)
Date: Thu, 9 Apr 2009 18:31:26 +0200
Subject: Bug in gcry_mpi_set_flag plus feature request
Message-ID: <20090409163125.GA2364@tango.0pointer.de>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: demo.c
Type: text/x-csrc
Size: 640 bytes
Desc: not available
URL: </pipermail/attachments/20090409/f07acd43/attachment.c>

From wk at gnupg.org  Thu Apr  9 19:24:20 2009
From: wk at gnupg.org (Werner Koch)
Date: Thu, 09 Apr 2009 19:24:20 +0200
Subject: Bug in gcry_mpi_set_flag plus feature request
In-Reply-To: <20090409163125.GA2364@tango.0pointer.de>
	(bpgcrypt@itaparica.org's message of "Thu, 9 Apr 2009 18:31:26 +0200")
References: <20090409163125.GA2364@tango.0pointer.de>
Message-ID: <87r6012117.fsf@wheatstone.g10code.de>

On Thu,  9 Apr 2009 18:31, bpgcrypt at itaparica.org 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.