Posted: 2013-09-15 Tags: Programming | SHA-3 | Lisp

A new patch release 1.0.2 of the SHA-3 library has been released, which fixes an important bug in the generation of message digests, where multiple calls to sha3-update with partially filled buffers could lead to input data being lost and therefore incorrect and colliding message digests being generated.

All users of SHA-3 should upgrade to the new release to avoid this issue. Uses of the library that only called sha3-update once for each message digest, as well as all uses of the high-level entry points were not affected by this issue, but should still upgrade as a precaution.

Thanks to Orivej Desh for reporting this issue.

The release is available from its PMSF page, and its GitHub home.

Posted: 2013-03-11 Tags: Programming | SHA-3 | Lisp

A new patch release 1.0.1 of the SHA-3 library has been released, which switches the implementation choice for 64bit versions of LispWorks to the 32bit implementation instead of the fixnum default implementation. No other changes are contained in this release.

The release is available from its PMSF page, and its GitHub home.

Posted: 2012-11-03 Tags: Programming | SHA-3 | MD5 | Lisp

As atonement for the recent MD5 release, and since we seem to perversely enjoy bumming numeric Common Lisp code, we have put together an implementation of the newly announced SHA-3, i.e. the algorithm formerly known as Keccak.

The package should be portable across nearly¹ all ANSI compliant CL implementations with specialized versions tuned for implementations that offer unboxed 64bit arithmetic, unboxed 32bit arithmetic and for implementations with efficient fixnum arithmetic (requiring fixnums that can represent (unsigned-byte 16)). Especially the 64 and 32bit implementations have been mostly optimized for SBCL and CMU CL. For those implementations, digests with a 1024 bit-rate (and 288 bit digest output) can be generated in between 30 (64bit SBCL) to around 100 (32bit CMU CL) cycles/byte on an i7-640M; whereas optimized C/assembler implementations reach around 12 to 50 cycles/byte on 64/32 bit Intel hardware. The reason for the discrepancy probably lies in missing peephole and dependency optimizations in the SBCL/CMU CL compiler backend, which we might look at in a future release.

The release is available from its PMSF page, and its GitHub home.

Many thanks go to the Keccak Team (Guido Bertoni, Joan Daemen, Michaël Peeters and Gilles Van Assche, cf. http://keccak.noekeon.org) for their algorithm and excellent documentation and reference implementations.

Enjoy.

---

1. Currently there is no version of the code that would work for CL implementations that have the smallest allowable fixnum size, which only covers (signed-byte 16), not (unsigned-byte 16) as required by the 16bit version in the package. I'm not aware of such a CL implementation, and in any case this could be easily fixed, at the cost of some code clarity and/or performance.