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 06:00:20 +0400
From: Alexander Cherepanov <cherepan@...me.ru>
To: john-dev@...ts.openwall.com
Subject: Re: Endianity in input files

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:-)

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

-- 
Alexander Cherepanov

Powered by blists - more mailing lists

Your e-mail address:

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