Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 16 Jan 2012 03:29:30 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: status.crypts overflow (was: bitmaps)

On Mon, Jan 16, 2012 at 03:00:35AM +0400, Solar Designer wrote:
> 10M	5.7M	1046 MB	1039 MB

BTW, at this raw speed and this many of LM hashes loaded, status.crypts
(64-bit) will overflow in just 4 days, whereas it'll take 15 days to
exhaustively search the printable US-ASCII space.  So we need to upgrade
this variable (and the .rec file format) to a larger size.

For a mere 1 million of LM hashes, things are better: exhaustive search
should complete in under 7 days (at 13M c/s raw) and not cause the
overflow yet.

However, this is assuming that nothing gets cracked.  Since in practice
almost everything will get cracked (or literally everything), both runs
should be much faster and the 10M run might not actually cause the
overflow (it will probably be down to 1M of uncracked hashes left in the
first day, so the effective crypts will grow much slower then).

Alexander

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.