Being a memory intensive hash, I was wondering if SSD's offer any appreciable performance boost for brute force attacks.
4
-
Correct me if I'm wrong...but when computing a scrypt run, your harddrive is not used? How would a SSD benefit? Just bung in more RAM, the faster the better?– Sébastien RenauldCommented May 17, 2013 at 19:55
-
That's what I thought, I saw some numbers thrown around for the amount of ram. I didn't know if one would get to the point where swapping was necessary, but if speed and size keep at an equilibrium...– IndoleringCommented May 17, 2013 at 20:04
-
if you get to swapping, I was thinking that distributed computing might work out in your favour both in terms of economy/costs and time.– Sébastien RenauldCommented May 17, 2013 at 20:05
-
SSD's benefit hash cracking when doing Rainbow table look ups on large tables.– NULLZCommented May 18, 2013 at 19:03
Add a comment
|
2 Answers
You can speed it up, but not with an SSD or a hard drive.
The fastest calculations today are done with video cards and GPU programming. So if you get a cheap video card and run Cuda or OpenCL you can get quite a lot of performance.
That being said GPU processing vs regular processing have similar limitations when using scrypt because the most efficient way to perform hashes with ROMmix (part of scrypt) is to cache all of the previously-computed values which requires quite a lot of RAM. GPUs are used for Bitcoin mining.
DRAM
Installing more memory should increase the speed depending on the operating system and the interaction with the hardware layer (is it a restricted vm, etc). From Wikipedia on CAS Latency.
In asynchronous DRAM, the interval is specified in nanoseconds. In synchronous DRAM, the interval is specified in clock cycles. Because the latency is dependent upon a number of clock ticks instead of an arbitrary time, the actual time for an SDRAM module to respond to a CAS event might vary between uses of the same module if the clock rate differs.
Grace Hopper explains nanoseconds here.
There is a point at which adding more memory will not speed up a machine.
SSDs by contrast
Installing an SSD (and even striping it) will improve performance over a hard drive in terms of virtual memory paging, but will have nowhere near the speed of physical RAM. SSD speeds are usually measured in MB/s and IOPS. Also the SSD is potentially limited by the speed of the controller. There are SSDs that are built onto cards with higher performance controllers bypassing the limits of SATA connections, but even these have speeds around 1000MB/s.
Here's a good place to compare the different speeds. A 500MB/s SSD is .5 bytes/nanosecond.
A nanosecond is 1.0e-9 seconds.
A typical 1-byte compare instruction between memory regions takes 1 cycle.
CPU speed these days is measured in GHz which is 1 billion cycles per second.
I'm not going to compare hard drives.
Nope because you run it in memory not from the hard drive.
The only form of hash cracking I know so far which uses a hard drive, are table lookups like Rainbowtables. Even in that case the benefit of an SSD is limited since it's read in sequentially. SSDs are good for random reads and writes.
answered May 17, 2013 at 19:58
-
SSD's show the biggest boost over hard drives in random I/O, but they are typically faster than spinning hard drives even in sequential I/O. The Samsung 840 SSD is rated at 530MB sustained sequential read performance, while a Seagate Cheetah 15K RPM SAS drive is rated at [122-204 MB/sec ](seagate.com/files/docs/pdf/datasheet/disc/…) (depending on if you're reading from the inside edge of the disk or outside)– JohnnyCommented May 18, 2013 at 4:31
-
Yea but in benchmarks for this particular use case there was barely any significant time gain. I ran this benchmark using an ssd and a 7200 rpm drive. Ssd vs 7200rpm was about 3 - 5% time gain in favour of the ssd which is barely anything Commented May 18, 2013 at 4:48
-
@LucasKauffman: on the contrary, SSD are very good for rainbow tables, because table usage implies a lot of very scattered reads. An SSD-based rainbow table allows for a lot more lookups per second (like 40000 instead of 100) and thus for much more compact tables, or faster attacks. However, scrypt is salted, which makes tables inapplicable anyway, regardless of whether you have SSD or magnetic drives or whatev. Commented Jul 5, 2013 at 19:02
-
1I did some benchmarks and the difference was practically insignificant Commented Jul 5, 2013 at 22:33