>>32
Six million tripcodes per second per CPU is actually a quite sound estimate. You're probably thinking in terms of running standard crypt() (or maybe DES_crypt()) in a for loop. Remember every time you call crypt(), it has to do a lot of bitwise manipulating to get a 56-bit key out of the input characters, set up the IV, etc., and it has to do more bit arithmetic at the end. For a sequential search of *all* tripcodes with a given key size you can make the search many times more efficient by setting up the IV once and iterating through the keys numerically. This is especially fast if you use bitslicing code instead of assuming a one-to-one mapping of plaintext->crypttext. Now, once you've eliminated all that unnecessary bit-shifting and initialization overhead, you can speed things up further by reducing the comparison function to a simple xor between two 64-bit integers instead of a costly strcmp().