Mailing List Archive

HMAC and RIJNDAEL192, was: bugs in bit manipulation routines
On Fri, Aug 04, 2006 at 11:40:36AM +0200, Werner Koch wrote:
> On Mon, 31 Jul 2006 18:33, bpgcrypt@itaparica.org said:
>
> > 3. HMAC-SHA256 calculation via
> >
> > gcry_md_open(&mh, GCRY_MD_SHA256, GCRY_MD_FLAG_HMAC);
> >
> > aborts with some "no secure memory allocated" message. This can be
> > fixed by explicitely doing a
> >
> > gcry_control(GCRYCTL_INIT_SECMEM, 1);
>
> or if you don't need secure memory:
>
> gcry_control (GCRYCTL_DISABLE_SECMEM, 0);
>
> The we require this is that a MAC uses a key and that key should be
> called in the so-called secure memory.

No doubt: securing the HMAC key is a wise idea. But I think it should be
unnecessary to call gcry_control() if one is going to ommit the
GCRY_MD_FLAG_SECURE flag anyway when initializing the hash function.


When reading in my /usr/include/gcrypt.h I found the following:

/* The Rijndael algorithm is basically AES, so provide some macros. */
#define GCRY_CIPHER_AES128 GCRY_CIPHER_AES
#define GCRY_CIPHER_RIJNDAEL GCRY_CIPHER_AES
#define GCRY_CIPHER_RIJNDAEL128 GCRY_CIPHER_AES128
#define GCRY_CIPHER_RIJNDAEL192 GCRY_CIPHER_AES192
#define GCRY_CIPHER_RIJNDAEL256 GCRY_CIPHER_AES256

AES is a block cipher with fixed 128 bit block length and non-fixed
key length. RIJNDAEL on the other hand is a block cipher with "any"
block length from 128 to 256. In the literature the identifier
RIJNDAEL192 usually denotes the RIJNDAEL cipher with 192 bit block length.
With the macros above RIJNDAEL192 denotes the cipher with 128 bit block
length and 192 bit key. This is confusing and possibly hazardous. I
suggest to drop all of the macros except the third one.

bp


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
Re: HMAC and RIJNDAEL192, was: bugs in bit manipulation routines [ In reply to ]
On Sun, 6 Aug 2006 23:38, bpgcrypt@itaparica.org said:

> No doubt: securing the HMAC key is a wise idea. But I think it should be
> unnecessary to call gcry_control() if one is going to ommit the
> GCRY_MD_FLAG_SECURE flag anyway when initializing the hash function.

the md_flag_secure puts all internal buffers into secure emeory. This
is for example required if you are going to hmac private key material.
Storing the hmac key into secure memory is a design issue with no way
to change it except for dropping all secure memeory.

> AES is a block cipher with fixed 128 bit block length and non-fixed
> key length. RIJNDAEL on the other hand is a block cipher with "any"
> block length from 128 to 256. In the literature the identifier

I recall from the second AES conference that it was presented in the
way it is used in libgcrypt. Can't find the proceedngs right
now. Anyway ...

> length and 192 bit key. This is confusing and possibly hazardous. I
> suggest to drop all of the macros except the third one.

... this would be an API change and thus we can't do it.


Shalom-Salam,

Werner


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