Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 17 Jun 2012 18:14:09 +0200
From: Tavis Ormandy <>
Subject: Re: [patch] optional new raw sha1 implemetation

On Sun, Jun 17, 2012 at 07:27:53PM +0400, Solar Designer wrote:
> Tavis,
> Thanks again for your contribution!
> On Fri, Jun 15, 2012 at 04:54:15PM +0200, Tavis Ormandy wrote:
> > The code is original, I can assign copright to Solar if required.
> My current preference is that contributors retain copyright, but license
> their contributions under cut-down BSD license as given here:
> This ensures that both the original author and JtR maintainers are able
> to combine the code with almost anything else.  (It also happens to let
> third-parties reuse the code, including in proprietary products.)
> Can you do that, please?

Yes, OK.

> Some notes on the actual code (although I haven't fully read it yet, and
> I might not):
> The SSE4.1 trick could be handy for vectorizing DES_bs_cmp_all(),
> although it is non-obvious whether that would provide any speedup over
> the current non-vectorized version even with that trick.  Thank you for
> bringing it to us for possible reuse. ;-)

It performs pretty well on intel, I don't know if it will be worth it
for AMD hardware.

> There's currently no speedup on XOP:
> user@...l:~/john/magnum-jumbo-cpu3/src$ ../run/john -te -fo=rawsha1_sse4
> Benchmarking: Raw SHA-1 [taviso sse4]... DONE
> Raw:    21591K c/s real, 21591K c/s virtual
> user@...l:~/john/magnum-jumbo-cpu3/src$ ../run/john -te -fo=raw-sha1
> Benchmarking: Raw SHA-1 [SSE2i 8x]... DONE
> Raw:    23513K c/s real, 23751K c/s virtual
> (This is a linux-x86-64-xop build.)  I guess some speedup can be
> achieved by adding use of XOP intrinsics into your new code - that is,
> it should become faster than 23.5M c/s then.

Yes, it should be much much faster if it's that close already...that's
encouraging. I don't have any AMD hardware easily available to test, but
I can do AVX, although it might have to wait until next week unless
someone else wants to try it :-)

(I can help with hints if someone else wants to try).

> The file taviso_fmt.c should probably be renamed.  I don't mind it
> including "taviso" if you like, but it should also include "sha1".

I don't mind, it was just what I called my working copy. how about
sha1_ng_fmt? Whatever you prefer is fine.

> The format label rawsha1_sse4 should probably be renamed because there's
> no hard dependency on SSE4.1 anymore.

Sure, any suggestions?

> Thanks again,
> Alexander

------------------------------------- | pgp encrypted mail preferred

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.