Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 10 May 2012 02:46:54 +0400
From: Solar Designer <>
Subject: Re: Sayantan: Weekly Report #3

Sayantan -

On Thu, May 10, 2012 at 03:55:25AM +0530, SAYANTAN DATTA wrote:
> Well it's not MD4 alone which consumes cpu time. A deeper look into the
> code suggests that conversion from byte to hexstring consumes significant
> amount of  time, nearly around 90% of total CPU time. Thus the  remaining
> 10% of cpu time is consumed by the md4 and other stuffs.

You shouldn't be doing that "byte to hexstring" conversion.  I don't
understand why you do it.  You only use ciphertext_host in cmp_exact(),
but you set BINARY_SIZE to 16, so you should not have false positives
before cmp_exact() anyway.  I think you should do one of:

1. Drop the ciphertext_host stuff, have cmp_exact() always return 1.


2. Reduce BINARY_SIZE to 4, make other relevant adjustments.  Then you
will in fact have false positives reaching cmp_exact(), and you'll need
to have cmp_exact() implemented for real.  Move the "byte to hexstring"
conversion from crypt_all() to cmp_exact(), because you only need to
perform the conversion when you have a false positive, not all the time.
Or you may perform the reverse conversion there, such as by simply
calling binary() and using all of its returned 16 bytes, not just 4.

#1 is simpler, #2 saves memory (12 bytes per loaded hash).

byte2hexstring() is indeed very slow - it uses malloc() and sprintf().
You also appear to be leaking that memory, so I guess you wouldn't
actually be able to crack MSCash2 hashes with this for very long.  On a
typical system, you'd run out of memory in a few hours or at most days.


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.