Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 17 Apr 2013 08:58:34 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Endianity in input files

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

>> 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.

Frank

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ