Simon Josefsson simon@josefsson.org writes:
Fixing a small bug in my 2010-12-07 port of serpent.c from libgcrypt to nettle was all that was required to make it work. Please consider this work, applied as follows:
Great!
I'll try to get this integrated reasonably soon. Have you compared the performance of the old and new code?
Some minor things (which I think I can take care of myself):
/* Serpent works on 128 bit blocks. */ typedef uint32_t serpent_block_t[4];
/* Serpent key, provided by the user. If the original key is shorter than 256 bits, it is padded. */ typedef uint32_t serpent_key_t[8];
I dislike array typedefs.
#define byte_swap_32(x) \ (0 \ | (((x) & 0xff000000) >> 24) | (((x) & 0x00ff0000) >> 8) \ | (((x) & 0x0000ff00) << 8) | (((x) & 0x000000ff) << 24))
This and the endian test where it is used should be replaced by using LE_READ_UINT32.
/* Convert the user provided key KEY of KEY_LENGTH bytes into the internally used format. */ static void serpent_key_prepare (const uint8_t * key, unsigned int key_length, serpent_key_t key_prepared)
This function seems to assume that key is aligned on a four-byte boundary, and that key_length is a multiple of four. The nettle interface specifies no alignment requirement on the key. And the old serpent code is supposed to support any key size (although unfortunately I don't have any testcases for sizes other than 16, 24 and 32 bytes).
After this code is in, I'd like to try to do serpent with two blocks at a time in parallel, for machines with native 64-bit registers (and change at least the ctr code to do a couple of blocks at a time). I think that might be about as fast as aes or camellia.
Regards, /Niels