[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bced5d3143af041ea6141effd3fe8286@smtp.hushmail.com>
Date: Mon, 29 Oct 2012 19:53:48 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: new fastssh format, please test and review
On 29 Oct, 2012, at 16:14 , Dhiru Kholia <dhiru.kholia@...il.com> wrote:
> By using the attached fastssh format, it is possible to get > 3X
> speedup over existing code (speedup is currently only for AES-128-CBC
> encrypted keys which are default these days on many systems).
>
> For some reason, benchmarking speed is very low. Actual cracking speed
> is nice :-)
You have a similar "problem" with the Office format. The benchmark includes both AES and DES test vectors. If you comment the DES ones out, the speed will probably be accurate.
> You can increase "#define SAFETY_FACTOR 32" parameter to reduce
> false positives at the cost of speed. This factor controls the number
> of bytes we decrypt.
Why compromise between speed and accuracy when you can have both? You can allow for a fair share of false positives in crypt_all() / cmp_all() but then you need to sort them out fully in cmp_exact(). Just implement a full check in cmp_exact() and then tune that SAFETY_FACTOR for best speed in crypt_all().
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.
