Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 20 Jun 2012 01:32:23 +0200
From: magnum <>
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 

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


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.