Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 15 Jul 2012 13:49:33 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: New core (?) LM fails alignment

On 2012-07-15 12:57, Solar Designer wrote:
> On Sun, Jul 15, 2012 at 12:21:52PM +0400, Solar Designer wrote:
>> Oh, indeed.  I changed BINARY_SIZE from 32-bit to 64-bit, because we now
>> derive full LM hash halves (for writing to john.pot) from the binaries.
>> This is actually two 32-bit words, not one 64-bit word.  But indeed the
>> self-test does not know that, and tries to insist on a 64-bit alignment.
>>
>> I think I will just drop the alignment check, and instead revise the
>> loader so that alignment of the pointer returned by binary() would not
>> be expected anymore.
> 
> I decided not to do that yet.  Instead, I made the alignment of binary
> and salt configurable per format, which is desirable anyway.  While at
> it, I also revised the memory.c code not to assume that pointers fit in
> "unsigned long", although that assumption caused no trouble so far.

I have no objections to that patch other than I will not likely have
time to merge it within 8-9 days or so, as I'll have to "investigate"
each format while adding this.
Or, I could merge the core files and leave bleeding-jumbo in a
non-buildable state until someone else fixes them and commits the changes.

On the other hand, I dropped some extra alignment checks that Jumbo had
which just happened to place stuff in other ways, so right now it does
not fail on LM, on my gear.

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.