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