[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 20 Jun 2012 01:32:23 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: RFC: Add --list=format-details support?
On 2012-06-20 00:39, Frank Dittrich wrote:
> On 06/20/2012 12:17 AM, magnum wrote:
>> Agreed. We'll have to settle for something, or live with what we happen
>> to use at release time.
>
> Adding new columns at the end should be less of a problem.
> But switching the sequence of columns, or switching from integer output
> to hex output for the format flags (to avoid endianness issues) after a
> release will be more problematic
Endianness is not more or less involved for hex vs dec, a number is a
number.
My very personal and spontaneous reflections are:
- I'd like a header showing what the columns mean (I had to look at the
source to figure out FMT_FLAGS).
- I'd like min left of max (not very important, just my reflection).
For human-readable output it would be better to see individual flags,
like UTF8 yes/no, but that would produce a very wide output. You could
at least output the flags in binary. Or just leave it as-is and say it's
for machine parsing.
Just thinking out loud, we could have multi-line output but that would
not help machine-parsing at all:
Format label: hmac-md5
Format name: HMAC MD5
Algorithm: 128/128 SSE2 intrinsics 12x
Plaintext length: 125
Flags: case-sensitive, 8-bit
Min. keys per crypt: 12
Max. keys per crypt: 12
\n
...
magnum
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.
