Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 30 Dec 2012 14:32:21 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Rejecting hashes in valid() due to memory allocation failures?

On 30 Dec, 2012, at 14:23 , Dhiru Kholia <dhiru.kholia@...il.com> wrote:
> On 12/30/2012 06:51 PM, magnum wrote:
>> On 30 Dec, 2012, at 9:09 , Frank Dittrich <frank_dittrich@...mail.com> wrote:
>>> How unlikely is it that a memory allocation failure occurs when trying
>>> to crack a huge number of passwords?
>>> (This could also be caused by strict ulimit settings.)
>>> IMHO, In such a case we shouldn't silently drop valid hashes as if they
>>> were invalid, but instead at least print some kind of error message.
>>> (May be even change the interface and allow a negative return value in
>>> valid(), to signal that there is a more general problem, so that we
>>> don't get thousands of error messages for memory allocation failures...)
>> 
>> Maybe the best thing is to just bail out with error(). The shared mem_alloc() and mem_alloc_tiny() will do so.
> 
> Sound good. So do we need another wrapper (like mem_alloc) for strdup?


Yeah, why not. Not sure if it should be in memory.c or misc.c?

>> BTW we probably have several places where malloc() should be replaced with mem_alloc().

If/when we search & replace these, we should check for ones that should be replaced with mem_alloc_tiny() instead (in particular, ones that lack a corresponding free()).

magnum

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.