Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <516DC88D.2070808@mccme.ru>
Date: Wed, 17 Apr 2013 01:54:21 +0400
From: Alexander Cherepanov <cherepan@...me.ru>
To: john-dev@...ts.openwall.com
Subject: Re: Endianity in input files

On 2013-04-16 23:12, magnum wrote:
> On 16 Apr, 2013, at 19:55 , Alexander Cherepanov<cherepan@...me.ru>  wrote:
>> On 2013-04-14 10:06, Solar Designer wrote:
>>> On Sat, Apr 13, 2013 at 05:31:23PM +0200, magnum wrote:
>>>> I did some testing of *2john programs on big-endian and noticed a problem that might be wide-spread: zip2john produces infiles that can only be cracked with a same-endian build of John. That is, some of the hex fields (integers) are in machine's endianness.
>>>
>>> Ouch.  I am not surprised, though.
>>>
>>>> This is not a huge problem but we might want to fix it (in bleeding?). I think all hex fields should be LE regardless of arch.
>>>
>>> I agree.
>>>
>>>> OTOH if we change it, we break backwards compatibility on BE archs.
>>>
>>> Maybe we need to introduce new/revised $-prefixes for the affected
>>> formats, to indicate that they're now reliably LE.  Print a warning for
>>> the old ones.
>>
>> If $-prefixes are to be revised maybe they could be simplified at the same time.

s/they/hashes/

> Anything specific in mind?

Mainly I thought about cases where fields inside a hash are separated by 
a char but lengths are also recorded for some fields. This is redundant, 
makes valid more complex and doesn't really simplify get_salt and co.
Also lengths are sometimes recorded in decimal (dmg, gpg, etc.) and 
sometimes in hexadecimal (pkzip).

Another old idea is to use base64 instead of hex. This will make hashes 
1.5 times shorter. And this shouldn't make decoding harder if special 
functions are used.

> This could be a good opportunity to drop the first, redundant, '*'. It occurs in all or nearly all of Dhiru's formats.
>
> $zip$*0*1*8005b1b7d077708d*dee4 - old, machine-endian last field
> $zip$0*1*8005b1b7d077708d*dee4  - new, little-endian last field

Yes, this begs to be fixed and is ideal to differentiate the new format 
from the old one.

And the whole ides of using two different delimiters ($ and *) seems 
questionable.

-- 
Alexander Cherepanov

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.