[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201109181154.31387.pfernandez@13t.org>
Date: Sun, 18 Sep 2011 11:54:31 +0200
From: Pablo Fernandez <pfernandez@....org>
To: john-dev@...ts.openwall.com
Subject: Re: integer limit reached
Hi Alexander,
> > Does actually John work internally with numbers bigger than 32 bit
> > integers?
>
> There's no plan to move external modes to bigger than 32-bit integers.
> I see almost no need for that (so far yours is the only exception, and
> it's a questionable one). It'd be a slight slowdown even on many 64-bit
> machines. Also, some existing external modes assume that int is exactly
> 32 bits (Strip, AppendLuhn).
That specific question was actually about JTR itself, not about the external
modes. 32 bit integers actually seem quite small number for certain hashes,
so, I was wondering if John can actually work in the incremental mode on those
orders of magnitude. My first guess is that, since each word is generated by
the previous one, you don't need to "count" the words so far... but what
happens with the sessions, for example?
I actually got myself around the 32bit limit in my external mode, by adding
two variables: turns_min and turn_max, that carry the number of times my
counter has to turn around 31 bits (to avoid sign). So, as soon as the
autoincrement becomes negative (MAX_INT / 2), I decrease the number of turns,
and set the counter to 0. It's not perfect, but it works!
> /*
> * Data type used by compiled programs.
> */
> typedef int c_int;
Thanks for the patch, I have just tried with long long int, and it seems to
work fine.
BR/Pablo
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.
