Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 9 Sep 2013 19:34:58 +0530
From: Sayantan Datta <>
Subject: Re: mask mode bug

On Sun, Sep 8, 2013 at 10:48 PM, magnum <> wrote:

> On 8 sep 2013, at 18:45, magnum <> wrote:
> >> With GWS=65536, memory usage reduces to "740MB" - still too much for
> >> cracking of one hash, but is more reasonable.  Unfortunately, the speed
> >> is worse:
> >>
> >> 0g 0:00:03:04 0g/s 1976Kp/s 1342Mc/s 1342MC/s aaabetnqcu..aaabetpmpb
> >
> > The key buffer should be 640KB (n.b. not MB) in this case.
> That's not correct, it's about 3.5 MB allocated - but we only transfer
> 640KB at a key length of 10.

I'll look into this issues.

> > Considering we only have a single hash, I wonder what is using hundreds
> of megabytes of memory?
> Apparently it always allocates bitmap structs for 32 million hashes
> regardless of actual number loaded. And it allocates some kind of hash
> table with a fixed size of 512 MB. I presume this will be dynamically
> allocated later.

I'm statically allocating memory because it saves a lot of kernel arguments
(by putting them in a single structure) which in turn saves lot of vgprs.
When number of kernel arguments exceeds certain limit, it starts using
vgprs. I have verified this with catalyst 13,4. This may be a compiler
problem and if this problem is resolved in future then we wouldn't have any
problem with dynamic allocation.


Content of type "text/html" skipped

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.