Question on hardware crypto support (RDRAND only source??? - question to devs)

sense678 · Jan 25, 2015, 2:01 PM

Hi all,

I have a - for me - pretty important question regarding activated hardware crypto in the OpenVPN client section.
If I activate RDRAND does this mean RDRAND is used as the only source for cryptographic work regarding the OpenVPN connections?

Because if yes this would drive me far far away from using it and deactivating it immediately.

Would be great if you get back to me shortly on that.

Thanks!

sense678 · Jan 27, 2015, 8:47 AM

I found this now under https://software.intel.com/en-us/articles/how-to-use-the-rdrand-engine-in-openssl-for-random-number-generation

How to use the rdrand engine in OpenSSL for random number generation

John Mechalas (Intel)'s picture Submitted by John Mechalas (Intel) on July 30, 2014

The OpenSSL* ENGINE API includes an engine specifically for Intel Data Protection Technology with Secure Key. When this engine is enabled, the RAND_bytes() function will exclusively use the RDRAND instruction for generating random numbers and will not need to rely on the OS's entropy pool for reseeding. End applications can simply call RAND_bytes(), do not have to invoke RAND_seed() or RAND_add(), and the OpenSSL library will not call RAND_poll() internally.

So, if this is true also for the implementation here this is a headshot, can PLEASE any of the developers give a statement on that??

Thanks

sense678 · Jan 27, 2015, 9:27 AM

I did some tests now for openssl with and without rdrand support and found out that on my machine it seems not worth using just RDRAND for giving up security (if it's true that RDRAND is the only source then what I still don't know), there is of course a difference, but it's not THAT big luckily.

openssl speed -evp aes-256-cbc :

OpenSSL 1.0.1k-freebsd 8 Jan 2015
built on: date not available
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx)
cc
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256-cbc 88767.97k 319504.90k 1061029.23k 6796229.69k 62477303.81k

openssl speed -evp aes-256-cbc -engine rdrand :

OpenSSL 1.0.1k-freebsd 8 Jan 2015
built on: date not available
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx)
cc
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256-cbc 80887.61k 366717.61k 1464973.43k 7211180.03k 63140353.37k

Harvy66 · Jan 31, 2015, 3:54 AM

I can't wait for OpenSSL to go away. Software should never implement its own rng and should always get rng from the OS. That being said, I trust Intel's RNG more than OpenSSL's crazy fall through logic that can sometimes source "random" data directly from your raw secret keys. Or at least it has in the recent past.