On May 17, 2010, at 14:40, RB Tilley wrote:
> Thanks, I'll try the hex-decoding idea to see if that helps, I did
> consider that, but wasn't sure it would have that much impact. Will
> look at the static memory allocation as well.
The hex thing is minor, and wouldn't affect your comparison much since you're
using it the same way in both cases; memory allocation is probably more
interesting. You're doing *lots* of operations with buffers of exactly the
same size from one attempt to the next; creating and destroying objects than
manage dynamic storage is wasteful, and makes for an unfair comparison. It may
still turn out that smallsha1 is faster, but you should compare them on equal
footing.
> I go parallel over the alphabet, not the hashes. For example, assuming
> that a person has selected a password from 94 English chars, and I
> have 94 cores then I could start at 94 different points (iterating
> forward through each point). So in that scenario (94 CPUs and 94
> chars), I use one CPU or core (basically a hardware thread) on each
> char. CPU1 only does char A, CPU2 only does char B, etc.
So at some point you're doing something like:
thread 1: sha1("testpasswordfooA")
thread 2: sha1("testpasswordfooB")
thread 3: sha1("testpasswordfooC")
etc?
If you can have one thread compute, say, 8 hashes (e.g., final letters A
through H) in parallel in the time it would take to compute 5 or 6 one at a
time, it's a significant time savings. I've no idea if a parallel SHA1
assuming SSE2 or SSSE3 or whatever would be that much faster though.
Whether it's worth exploring depends on your problem space. If you're just
looking to crack a few short passwords, it's better to just live with the
possibly-longer run time than invest lots of effort into redesigning the
program. If you had lots of difficult and long passwords to go after, where
run time may take days, weeks, or months, then investing effort in taking
advantage of parallelism might make sense.
> So parallel hashing on the same HW thread would not occur. With fewer
> HW threads, each thread would iterate through a subset (3, 4, 5, or
> upto total chars/2 for a dual core system) of the 94 chars and then
> stop. That being the approach, I would think any sha1 library would
> do, and I like Crypto++ due to its wealth of hash functions compared
> to other libs.
So, you're going to be using this with other hash functions as well?
Ken
--
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to [email protected].
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
