Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 17 Apr 2013 00:18:25 +0200
From: Frank Dittrich <>
Subject: Re: Endianity in input files

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.

> 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


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.