Being a memory intensive hash, I was wondering if SSD's offer any appreciable performance boost for brute force attacks.

  • 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? 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...
    – Indolering
    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. May 17, 2013 at 20:05
  • SSD's benefit hash cracking when doing Rainbow table look ups on large tables.
    – NULLZ
    May 18, 2013 at 19:03

2 Answers 2


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.


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.

  • 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)
    – Johnny
    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 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. Jul 5, 2013 at 19:02
  • 1
    I did some benchmarks and the difference was practically insignificant Jul 5, 2013 at 22:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .