Simon Josefsson <[email protected]> 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 -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
