Nonsensical benchmark results, please explain

Open source disk encryption with strong security for the Paranoid

Brought to you by: idrassi

Nonsensical benchmark results, please explain

Forum: Technical Topics

Creator: butesta

Created: 2016-07-10

Updated: 2016-07-26

butesta - 2016-07-10

How is SHA-512 faster than 256? Why is it orders of magnitude slower in pre-boot, even though similar # of iterations? Obviously Whirlpool is not pushing hundreds of TB/s?

Last edit: butesta 2016-07-10

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mounir IDRASSI - 2016-07-10

First, indeed the Whirlpool numbers is wrong. I can't reproduce on my side on several machines with different CPUs. Can you please give your CPU reference? Are you running VeraCrypt executable in 32-bit or 64-bit (I guess it is 64-bit)?

Concerning the difference between SHA-512 and SHA256, this is normal: SHA-512 is known to be faster on 64-bit than SHA-256. On the other hand, SHA-256 is faster on 32-bit machine than SHA-512.
VeraCrypt uses SHA-2 implementation by Dr Brian Gladman which is C only with no assembly. There are other implementation out there that use assembly by the gain is not huge and the difference of performance between SHA-512 and SHA-256 is the same (for example see benchmarks at https://www.nayuki.io/page/fast-sha2-hashes-in-x86-assembly)

Anyway, waiting for your CPU reference to try to understand the Whirlpool issue.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

butesta - 2016-07-10

Thanks for the info so far, I use an Athlon II X4 620 (Propus) on 64-bit VC/Win10.
The Whirlpool numbers seem only to be borked with the 1 GB buffer size, on the others it's the slowest of the bunch with ~60-70 MB/s.

But I'm most concerned about the pre-boot difference, since it matches my experience with VC 1.17: just unlocking the system drive took half a minute. Whereas a partition based container with the same password opened reasonably quickly.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mounir IDRASSI - 2016-07-10

Thank you for the details. I will look into this.

As for pre-boot numbers, they are caused by the fact that on Windows systems booting legacy MBR, VeraCrypt bootloader runs in 16-bit mode and because of this the performance of cryptographic primitives is poor.
On Windows systems booting on UEFI mode, the performance of VeraCrypt EFI bootloader is close to normal mounting operations. Moreover, it offers the possibility to use all hash algorithms, not only RIPEMD160 and SHA-256.
If you have a machine booting on UEFI, you can test the preview version of VeraCrypt containing EFI support that is available at https://sourceforge.net/projects/veracrypt/files/VeraCrypt%20Nightly%20Builds/ (look for "VeraCrypt Setup 1.18-EFI-PREVIEW-BETA.exe").

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Enigma2Illusion - 2016-07-26

@Butesta,

Can you test again using Beta 10 for 1.18 and report your findings?

Windows: Solve benchmark issue for Whirlpool which caused wrong numbers when a 1GB buffer is chosen.

https://sourceforge.net/projects/veracrypt/files/VeraCrypt%20Nightly%20Builds/

Last edit: Enigma2Illusion 2016-07-26

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Log in to post a comment.