>>1,20
The problem is trivial enough, but why would I rewrite an already rewrite something that has been done so many times.
The bottleneck of such code would be the DES implementation. A lisper would either use a library with bindings to openssl or similar to get crypt() from it, or reimplement crypt themselves. I doubt reimplementing crypt in Lisp would be faster than the optmized asm version, at best it would match its speed(with enough declarations added). I just looked over the 'bitslice' DES implementations and they would be trivial to implement indeed, however if you truly want speed, you shouldn't stop at just compiling some C or Lisp code to x86 asm, instead you should look into:
1) Parallelization - multiple threads for normal CPUs, or:
2) Hardware implementation: DES can be very efficiently implemented in hardware, much faster than you can do with sequential CPUs.
Besides threading, a poor man's solution of 2 is to use things like CUDA-based DES crackers or build your own using a bunch of FPGAs, or if you are truly rich, build a lot of DES cracker ASICs, then DES will be a joke to you. If needed you may use Lisp in the hardware design process, afaik there are/were some EDA tools which are/were Lisp-based.
If you want a more practical example that makes use of Lisp's speed and power, you should look at CL-PPCRE.
Another victory for PHP.
... Oh,
IHBT.