[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 05 Dec 2011 16:38:39 +0100
From: Simon Marechal <simon@...quise.net>
To: john-dev@...ts.openwall.com
Subject: Re: Bit slice implementation of DES based hashes
On 05/12/2011 16:27, piyush mittal wrote:
> # The user’s ASCII <http://en.wikipedia.org/wiki/ASCII> password is
> converted to uppercase <http://en.wikipedia.org/wiki/Uppercase>.
This is susceptible to the same problem as the widechar conversion for
Oracle. In the case of LM hashes, all possible cases have been
documented by HSC for french accents here :
http://www.hsc.fr/~lehembre/breves/rainbowtables/rainbowcrack-1.2-french-accents-HSC.diff
I'm not sure how much more is needed to cover the whole input set. LM
hashes for some input values are simply not generated, which could lead
to an optimization. The exact rules are unknown to me.
For Oracle, implementing in a naive way (interleaving 0's between chars)
will not work for non ascii values. I believe proper unicode conversion
libraries are now included in JtR jumbos, but I have no clue on how they
work.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
