Hi Jian, On 05/14/19 09:03, Wang, Jian J wrote: >> -----Original Message----- >> From: Laszlo Ersek [mailto:ler...@redhat.com] >> Sent: Tuesday, May 14, 2019 12:15 AM >> To: devel@edk2.groups.io; Wang, Jian J <jian.j.w...@intel.com>; Lu, XiaoyuX >> <xiaoyux...@intel.com> >> Cc: Ye, Ting <ting...@intel.com> >> Subject: Re: [edk2-devel] [PATCH v2 5/6] CryptoPkg: Upgrade OpenSSL to 1.1.1b
>> Honestly the best I could suggest is, "use RDRAND if available, fall >> back to TimerLib otherwise". :( But I would understand if you wanted to >> postpone RDRAND until later. > Actually we wanted to use hardware seed/rand generator at first. I > thought it might not be acceptable due to the fact it's processor > dependent. So we hesitated. My understanding to above comment > is that you agree to use rdrand/rdseed if available and fall back to > TimerLib otherwise, right? I've now tried to read up a little bit on RDRAND. It seems that crypto folks do not universally trust RDRAND. Some people reject RDRAND completely, while others are willing to use RDRAND as *one* source for entropy, but they always mix it with other entropy sources. But even that practice is not acceptable to some people, saying that RDRAND can be used to compromise those other entropy sources, dependent on the mixing details. It seems that FreeBSD at the least uses the Yarrow algorithm for mixing, which comes with its own complexities. As much as I dislike it, at the moment I cannot recommend anything better than just TimerLib. I'm not satisfied with TimerLib, but I don't know enough to suggest an improvement. RDRAND looked like a good entropy source, but then reading up on people's opinions on it, gave me pause. In the longer term, I believe a serious reorganization of BaseCryptLib / OpensslLib / etc might help. Namely, move the seeding / entropy collection out of these low-level libraries, and force all dependent modules (drivers and such) to provide their own entropy. Then, privileged drivers (e.g. SMM drivers) could use a low-level platform device for collecting randomness, without depending on 3rd party UEFI drivers. Less privileged drivers (such as for HTTPS boot) could perhaps consume EFI_RNG_PROTOCOL, or maybe some protocol / abstraction exposed by TPM drivers. I guess it's OK if we stick with TimerLib for this OpenSSL version upgrade. Can we please document the use of platform timers as entropy sources (including the TSC) in the following wiki article? https://github.com/tianocore/tianocore.github.io/wiki/CryptoPkg I'm not asking for many details, just a short summary of the fact and why we do this. Thanks Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#40590): https://edk2.groups.io/g/devel/message/40590 Mute This Topic: https://groups.io/mt/31552212/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
