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
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.