Libgcrypt

Posted by: stak
Tags: code
Posted on: 2010-12-03 01:33:33

This post is about my recent experience in trying to use libgcrypt-1.4.6, although older versions probably exhibit the same behavior. I'm putting this online so that anybody else who runs into the problems might find it useful.

First of all, libgcrypt doesn't do base64 encoding. Even though the header files have base64-related constants, it doesn't do anything with them. Filed as Issue 1303.

Second, libgcrypt doesn't do elliptic curve encryption. It does have ECDSA support, but only for signing and verification. I found the gnupg-ecc project which claims to add full ECC support to GnuPG, but unfortunately it doesn't seem to expose it correctly via libgcrypt. I logged issue #1 on the project asking for clarification but there hasn't been a response yet. In short, I couldn't get ECC encryption/decryption working with libgcrypt, even using gnupg-ecc.

Third, when serializing and de-serializing s-expressions, be careful of the format you use. In particular, given the classic rsa key-gen example "(genkey (rsa (nbits 4:1024)))" you might think that a value of the format <length>:<data> will always be interpreted the same way, where <length> and <data> are both base-10 numbers, and <length> indicates the length of <data>. This is not always true, however - it depends on where the number is being used. In fact, if you look at the src/sexp.c file in libgcrypt, you'll see that the <data> field is read in assuming it's a binary field. It's only later in cipher/pubkey.c that strtoul is called on that field, thus parsing it as a base-10 value. I found this out the hard way after trying to build an RSA public key with an exponent expressed as "(e 5:65537)". The "65537" in that got interpreted as a binary field instead of the base-10 value that I was expecting it to, resulting in a hard-to-track-down bug. The correct approach to doing that is to write "(e #010001#)".

[ Add a new comment ]