Cryptohaze.com

Do you have plans for hash functions that are less than 128 bits (LM, half LM challenge, Cisco PIX)?
There's two easy ways to do this. A new reduction function that doesn't skip the highest order byte or be backwards compatible and go back and use the unused bytes. Also for Cisco PIX technically you don't need to change anything if you just don't compress the MD5 hash at the end (remove the highest order bytes of the 4, 32 bit integers to make a 96 bit hash).

Also I remember talking about varying length passwords a long time ago but there's a really easy way to do it. Have the last character set have a null character in it and when it is used in a password the length is then considered one smaller. The only problem is if someone wants to build a rainbow table with a null character, but I can't think of a reason when you would need that. Obviously this only works for 6-7, 7-8, 8-9, etc., but this is a great improvement (19% smaller or 35% faster in this specific case) over two table sets one for [a-z]{7}[0-9]{3} and another for [a-z]{7}[0-9]{2}.

Sc00bz wrote:Do you have plans for hash functions that are less than 128 bits (LM, half LM challenge, Cisco PIX)?
There's two easy ways to do this. A new reduction function that doesn't skip the highest order byte or be backwards compatible and go back and use the unused bytes. Also for Cisco PIX technically you don't need to change anything if you just don't compress the MD5 hash at the end (remove the highest order bytes of the 4, 32 bit integers to make a 96 bit hash).

My general plan for shorter hashes was to write a different reduction function. The reduction functions are contained in the hash-specific code (MD5, NTLM, etc), so there's zero problem changing to a different reduction function. I can also tie it to table version - the code is designed to handle reduction function changes down the road.

I was looking into something for LM a while ago, and don't recall what I came up with. I think it was going to use the unused bytes and do something with them. I need to look at it, now that I have a LM module in the Multiforcer.

Also I remember talking about varying length passwords a long time ago but there's a really easy way to do it. Have the last character set have a null character in it and when it is used in a password the length is then considered one smaller. The only problem is if someone wants to build a rainbow table with a null character, but I can't think of a reason when you would need that. Obviously this only works for 6-7, 7-8, 8-9, etc., but this is a great improvement (19% smaller or 35% faster in this specific case) over two table sets one for [a-z]{7}[0-9]{3} and another for [a-z]{7}[0-9]{2}.

That's worth looking at. I would like to get per-position charset stuff working for the RTs, but I think there's some complexity I'm missing. Once the new MF framework is done, I was going to sit back down with the RTs and really hammer on some analysis tools for a while. Having a desktop with memory is going to be nice for this - I've got 12GB in my desktop now, with another 2 boxes containing 16GB available to me. Last time I was doing analysis, 4GB was hard to find.