Mobile-OTP Android Client

My brother and I have recently published an application to the Android Market that implements the mimics the Mobile-OTP reference implementation.  I am proud of this for two reasons:
1.  This is my first application into the android market.
2.  I believe the features of this applications are better than the other MobileOTP clients I have seen thus far.

Our implementation allows for multiple profiles; essentially this allows a user to store credentials for multiple servers.  Also, instead of remembering codes such as "#**#" to initialize a device, our client has easy to navigate menus that follow traditional Android applications' feel.

Here are some links

DAAP with Android

I recently set up my router to port forward incoming DAAP request to my personal server.  Essentially this allows me to listen to all my wonderful music over the internet.  There exists a few problems though.  iTunes does not allow connecting to DAAP servers that aren't connected on the local network.  There are a few windows programs that do this, but just a heads up.  Also, My phone currently has no software to allow me to connect to DAAP shares.

I am considering writing an android application that would allow this.  I am still in the research phases though.  First off, the software would only be able to access custom daap servers or iTunes applications whose version number is less than 7.2 as the protocol was changed then and no reverse engineering has broke it yet.  Perhaps my reverse engineering course can change that, but let's see.  Second, I need to be able to make android stream an mp3 file.  I found this nice blog post which seems very helpful.  Let's see where this goes.

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_check_version(GCRYPT_VERSION);
   gcry_control(GCRYCTL_SUSPEND_SECMEM_WARN);
   gcry_control(GCRYCTL_INIT_SECMEM, 1);
   gcry_control(GCRYCTL_RESUME_SECMEM_WARN);
   gcry_control(GCRYCTL_INITIALIZATION_FINISHED);
   gcry_md_open(&hash_handle_, hash_type,
      GCRY_MD_FLAG_SECURE| GCRY_MD_FLAG_HMAC);
   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.