[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <516E5727.1020306@mccme.ru>
Date: Wed, 17 Apr 2013 12:02:47 +0400
From: Alexander Cherepanov <cherepan@...me.ru>
To: john-dev@...ts.openwall.com
Subject: Re: Endianity in input files
On 2013-04-17 10:58, Frank Dittrich wrote:
> On 04/17/2013 04:00 AM, Alexander Cherepanov wrote:
>> On 2013-04-17 02:18, Frank Dittrich wrote:
>>> On 04/16/2013 11:54 PM, Alexander Cherepanov wrote:
>>>> 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.
>>>
>>> Since we can't easily drop support for the old hash format (except for
>>> new formats which haven't been released in a previous jumbo version),
>>> these functions will not get simpler by changing the preferred hash
>>> representation, at least not in the short run.
>>
>> Yeah, if we need to process both formats things get more compicated. If
>> we just print warning for old formats evering becomes easier:-)
>
> We would need to provide a tool which converts existing john.pot entries
> into the new hash representation, before we can drop support for the
> older, deprecated hash representation.
> I remember suggesting such a conversion tool in the past, but apparently
> the need to convert existing .pot files is "too much complexity for the
> user", see http://www.openwall.com/lists/john-users/2005/06/23/2
I need to read this thread later but generally it seems hard to maintain
good john.pot but easy to extract value from it -- cracked passwords.
Roughly speaking --loopback should solve most problems IMHO.
>>> The preferred way of storing a hash also depends on
>>> -how the system which uses these hashes is storing / reporting them
>>> -what third party tools adopted john's hash representation / support
>>> which other representations
>>
>> IIUC we talk now about formats which get into john through *2john
>> programs so there is no natural form for them.
>
> OK, but third party tools still need to be considered.
Sure. But this thread has started with the problem that the presentation
of some hashes must be changed. In such a situation third-party tools
are to be broken anyway. And it seems quite appealing to improve the
presentation of hashes while we are breaking third-party stuff and old
john.pot files. There could be no other possibility to do it.
Whether and how to improve hashes which we are not forced to change is a
hard question. Well, we need to find a problem with them which will
require some change to the presentation:-)
--
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.
