Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 18 Sep 2011 11:54:31 +0200
From: Pablo Fernandez <>
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.


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.