Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 31 Jan 2012 23:41:27 +0100
From: magnum <>
Subject: Re: Adding a new format

On 01/31/2012 11:10 PM, Claudio Broglia wrote:
> Thanks for the hints, anyway I was already looking into it.
> Until now, I've roughly figured out how they work together, but
> something it's still missing in the picture :)
> Here are a call dump from a single hash:
> -- loading phase --
> nds_valid(): ciphertext=...
> nds_binary(): ciphertext=...
> binary_hash_4()
> nds_salt(): ciphertext=...
> Loaded 1 password hash (...)
> -- testing phase --
> nds_valid(): ciphertext=* 
> nds_valid(): ciphertext=...
> nds_binary(): ciphertext=...
> nds_salt(): ciphertext=...
> nds_set_salt()
> nds_set_key()
> nds_crypt_all(): count=1
> get_hash_0()
> binary_hash_0()
> get_hash_1()
> binary_hash_1()
> get_hash_2()
> binary_hash_2()
> get_hash_3()
> binary_hash_3()
> get_hash_4()
> binary_hash_4()
> get_hash_5()
> binary_hash_5()
> get_hash_6()
> binary_hash_6()
> nds_cmp_all(): count=1
> nds_cmp_one(): index=0
> nds_cmp_exact()
> -- cracking phase --
> ...
> nds_set_key(): key=mace55 index=0
> nds_crypt_all(): count=1
> nds_cmp_all(): count=1
> ...
> My questions are:
> - what are needed for the binary_hash() and get_hash() functions? From
> the testing phase, I supposed they were needed to speedup comparison,
> but they aren't used during the cracking phase.

In the simple cases it just returns a number of bits from a resulting
binary hash. It's used for sorting out candidates that we don't even
have to send to cmp_all().

> - what is the meaning of the call, in the auto test phase, to
> nds_valid() with ciphertext parameter set to "*"?

It ensures that valid() is actually capable of rejecting a cipertext...

> - would you suggest to crypt many keys at every pass, to gain speed, or
> to stick with MAX_KEYS_PER_CRYPT set to 1?

If you calculate one hash at a time (like in an OpenSSL version) there
is no gain in rasing it. But when using OMP and/or SSE we do a bunch of
hashes (in parallel) per crypt_call(), so this is needed.

> - the hash format I'm adding uses only uppercase passwords. In which way
> would you suggest to handle this? For example, converting to uppercase
> the keys given in input to nds_set_key()? I'm sure there's a better way
> to do it...

For non-OMP formats you want such conversions and trimming in set_key(),
especially for unsalted format. But set_key() is single threaded so for
OMP you can postpone these things to crypt_all() with various ways to
not actually converting keys again for each new salt.


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.