Re^14: SaltedDigest Salt?

[zwon]

Ok, let's see this graph again. Fig 13 shows that throughoutput of SHA512 was 616Mbit/s comparing to 91Mbit/s for 3DES. As we talking about breaking password, we interested in number of encryptions per second, not in throughoutput. SHA512 block size 512 bit which gives us 1203125 encryptions/s. 3DES block size 64 bit, that's 1421875 3DES encryptions/s or 4265625 DES encryptions/s. And this turns your 6 coefficient into 0.28. Now, reading description of tests in you can see that they were hashing 3MB of data, which means that they probably used 3DES in CBC mode, so couldn't use many optimisations, like e.g. parallel encryption of several blocks. Note also that Fig 12 shows that SHA512 implementation used 23% of FPGA slices, twice as much as SHA1 implementation (not counting IO slices), and document says nothing about 3DES.

Summarising:

1. SHA512 in [1] was 3.5 times slower than DES
2. you're not taking into account number of slices required to implement SHA512 and DES
3. [1] is about hashing data stream, copacobana is about key search. [1] doesn't allow parallel operations, copacobana does.

And based on that I think your estimation sucks

[1] http://www.east.isi.edu/~bschott/pubs/grembowski02comparative.pdf

[BrowserUk]

1. SHA512 in 1 was 3.5 times slower than DES

   I used the numbers in that pdf to try and relate the headline numbers available for DES to SHA512, because both algorithms had been implemented on the same hardware. I accept my interpretation of that relationship may be wrong.

   Okay. You don't like those numbers, I have different ones. These are all direct throughput measurements of the SHA512 algorithm implemented in FPGAs.

   • This one gives a throughput figure for SHA512 of 1.365Gb/s. (Virtex-4 hardware.
   • This one gives a (derived) throughput value of 2.285Gb/s for SHA512 (Virtex-5 hardware.)
   • This one gives a throughput value of 1.243 Gb/s. (Virtex-E hardware.)

   All 3 or 4 years older than the current generation of Virtex-7 hardware. And all single FPGA implementations.

   Using the highest of those values as an underestimate for this years hardware -- now using 28nm rather than 40nm process -- we get 4.8 Gencryptions/second for each FPGA.

   Now multiply that by 1792 for the RIVYERA hardware.

2. you're not taking into account number of slices required to implement SHA512 and DES

   This is essentially irrelavent. The fact that SHA512 uses 23% of the slices means that there is 77% of the hardware left to play with to improve the performance. Which many others have subsequently done by using that unused capacity to unroll lumps of the algorithm,moving them off the critical path.

   Unused slices are like unused memory on a PC. Indeed, one of the uses the can be put to is to form on-chip 'memory' to speed things up.

3. 1 is about hashing data stream, copacobana is about key search. 1 doesn't allow parallel operations, copacobana does.

   "Didn't use", not "doesn't allow".

   One of the possible uses for that 77% of unused capacity, would be to create 4 identical encryptors. Loading up 4 keys at a time onto each FPGA and encrypting them in parallel. Even that very old device with only 100 slices could have pipelined 4 keys at a time.

   The Virtex-7 device has 3,600 slices. It could handle 144 pipelines of the gremboski implementation per FPGA. And run them faster. (Higher clockrate due to process shrink.)

   So, using your math: 616Mb/s / 512 = 1,261,568 keys/s. * 144 (piplines/FPGA) * 1792 (FPGAs/system) * 5 (clock-rate increase) = 1,631,358,812,160 keys/s.

I guess we're done now, but keep watching, because it's coming. Like it or not.

(Indeed, I'm guessing that certain organisations with very deep pockets already have it.)

[zwon]

Okay. You don't like those numbers, I have different ones.

That's just ridiculous. I don't even question the result numbers, but your methods of manipulating data, sure they allow you to get any result you want.

[BrowserUk]

Have you heard of Groucho Marx?