HMAC with gcrypt

On my way towards a working RFC4226 implementation, I needed an HMAC implementation.  I originally started working on my own, but then I was going to need a working suite of hash functions.  Obviously I should use some well-known cryptographic libraries for these hash functions.  I found libgcrypt, part of GPG.  I didn't expect for some reason to find that HMAC was already implemented in this suite as well.

I decided to use their HMAC to have better integration with their hash functions and for assured functionality.  This turned out to be a good thing because it took lots ot tinkering to get my digest to match RFC 4231. Skipping the dirty work, here are the important functions (in order):

   gcry_control(GCRYCTL_INIT_SECMEM, 1);
   gcry_md_open(&hash_handle_, hash_type,
   gcry_md_setkey(hash_handle_, key, key_length);
   gcry_md_write(hash_handle_, message, length);
   gcry_md_read(hash_handle_, 0);

The hardest part was getting the key to be correct.  I take the hexadecimal description of the key, and convert it to an array of unsigned chars for safety (signedness is notorious for messing up values). This is all it takes (more or less) to get a working HMAC implementation.  I arraned things more nicely in preparation for the full-blown RFC 4226 code.

Unit Testing Not a Panacea

I attempted to use unit testing on my recently finished HMAC implementation in an attempt to use what I have been told repeatedly and experienced first hand.  I first start by noting that when writing in C, unit testing libraries offer little more than a central block of code where tests should be placed.  I looked at some libraries here and they seemed suitable, but for my small HMAC implementation, I just made a function that calls some tests I came up with on the spot.

Here is where my problems began.  Unit tests can only test functionality that you explicitly write.  This is all that a programmer could ask for, unless someone implements some FSA to represent a function.  That would work on a small subset of useful functions (regular languages), but that is certainly a tangent.  I tested some utility functions I wrote by supplying input and the known output.  Example below:
   char *ascii_hex;
   unsigned char *binary;
   ascii_hex = (char *)malloc(4);
   ascii_hex[0] = 'A';
   ascii_hex[1] = 'B';
   ascii_hex[2] = 'C';
   ascii_hex[3] = '9';
   binary = ascii_hex_to_binary(ascii_hex, 2); /* 2 is size in bytes */
   if(binary[0] != 0xAB && binary[1] != 0xC9)
       printf("Error, ascii_hex_to_binary didn't work\n");

I was happy to know that my test passed, but I realized later that ascii_hex_to_binary was not behaving properly.  My test did not check the all possible casess of the input string, especially the one that caused my program to not function correctly. The lesson I suppose would be one test is certainly not enough to check the behavior of a nontrivial function.

RFC 4226

I found this when reading about OATH.  I am now working on implementing this in C++ with eclipse using the C++ development tools.  I find these are not up to par in comparison with Eclipse's java integration, but there is some utility when compared to vim (certainly not in the text editing field though).

I first need to implement HMAC.  I am going to use the strategy pattern so that any hash function can be used with my HMAC implementation.  Since I am not writing my own hash algorithms though, I will be limited to what Libgcrypt has to offer.

I noticed some problems though in my wikipedia research, so I corrected what I saw.  I noticed that Existential forgery had its own page, where as selective and universal forgery were on one page.  I combined the existential forgery page into the generic forgery page.  I then renamed the forgery page to reflect the use of digital signatures as well as macs, so now Forgery (MAC) becomes Forgery (Cryptography).  I also added a disambiguation page for Forgery.