ToDo: Use GCC-intrinsics for SSE2-code

[GoogleCodeExporter]

We currently use "handwritten" SSE2-code for fast SHA1- and MD5-computation. 
This code is hard to maintain, hard to call correctly and hard to compile & 
link.

Some months ago, I wrote vector-based implementations of SHA1- and 
MD5-computation using GCC-intrinsics; all data- and function-types exposed by 
the code are well defined in GCC's x86-extension. However I dropped the idea of 
replacing the current SSE2-path after testing showed that the intrinsics-code 
was slower (by about 20%) than the one we currently use.

I've attached the code to this bug. Find out if throughput can be increased 
through further optimization. We'll drop the current SSE2-code if the new one 
can at least level in terms of performance.

Original issue reported on code.google.com by lukas.l...@gmail.com on 31 Oct 2010 at 1:49

Attachments:

• md5.c
• sha1.c

[GoogleCodeExporter]

Hi. 
Years ago I wrote my assembly version of SHA1 using SSE2.
I attach the source code, I hope it helps.

Original comment by pyrit.lo...@gmail.com on 9 Dec 2010 at 10:57

Attachments:

• xmm.s.200806291157.2.s

[GoogleCodeExporter]

It would like to know, if there could be more performance by using SSSE3 PALIGNR
and "VIA PadLock" SHA functions
http://www.via.com.tw/en/initiatives/padlock/hardware.jsp#sha
Sadly I don't have VIA PadLock, but maybe someone can help us.

Original comment by wildeham...@gmail.com on 14 Dec 2010 at 9:54

[GoogleCodeExporter]

I don't see how PALIGNR would be of help.

VIA Padlock is implemented since September 2008.

Original comment by lukas.l...@gmail.com on 15 Dec 2010 at 7:51

[GoogleCodeExporter]

Sorry haven't seen that VIA Padlock is implemented

Intel uses PALIGNR to reduce some steps in SHA1.
http://software.intel.com/en-us/articles/improving-the-performance-of-the-secure
-hash-algorithm-1/

I'll try to compile with Intels version and look if it works, and speeds up the 
SHA1.

Original comment by wildeham...@gmail.com on 15 Dec 2010 at 11:18

[GoogleCodeExporter]

If you supply code, it needs to be GPL-v3 compatible. Please also take care 
that Pyrit must compile and work on i386-, SSE2- and SSE3-compatible CPUs. If 
SSE2 is available but SSE3 is not, the code must fall back to the original 
implementation.

Original comment by lukas.l...@gmail.com on 15 Dec 2010 at 11:26

[GoogleCodeExporter]

taking a quick look at the intel implementation, afaics it uses a completely 
different approach as we do. Our implementation does not have the problem the 
article describe.
You are very welcome to benchmark it and see if it may provide better 
performance, of course

Original comment by lukas.l...@gmail.com on 16 Dec 2010 at 4:39