Re: [edk2] RNG algo question

2016-09-17 Thread Long, Qin 
Exactly. Thanks, Ard.

gEfiRngAlgorithmRaw is designed to provide entropy directly (defined in UEFI 
spec), which is intended to use the DRNG to seed in an ongoing manner some 
current software PRNG. Though RDRAND is quite usable as a source of random 
values. For standards compliance, some may feel it necessary to demand an 
absolute guarantee that values returned by RDRAND reflect independent entropy 
samples within the DRNG. One choice is to use RdSeed instruction directly. The 
current implementation leverage the reseeding guarantee of the DRBG to generate 
random seeds from values obtained via RDRAND (for the processor that do not 
support the RDSEED).
For gEfiRngAlgorithmSp80090Ctr256Guid, the current RdRand output is already 
compliant with NIST SP800-90C standards.

More information can be referred from 
https://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide


Best Regards & Thanks,
LONG, Qin

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
Biesheuvel
Sent: Saturday, September 17, 2016 3:19 PM
To: Palmer, Thomas 
Cc: edk2-devel@lists.01.org; Gibbons, Pat 
Subject: Re: [edk2] RNG algo question

On 16 September 2016 at 22:33, Palmer, Thomas  wrote:
>
> EDK2 community
>
> Why is the RngGetRNG  sending requests for "gEfiRngAlgorithmRaw"  to 
> "RdRandGenerateEntropy",  which does AES operations on RDRAND output, whereas 
> the requests for "gEfiRngAlgorithmSp80090Ctr256Guid" get sent to 
> RdRandGetBytes which simply reads the rdrand source without modification.
>
> Shouldn't the processing be switched, so that "Raw" goes to RdRandGetBytes 
> and "gEfiRngAlgorithmSp80090Ctr256Guid" goes to RdRandGenerateEntropy?  I did 
> not see anything in the UEFI 2.5 spec indicating why this was the case.
>

The RDRAND instruction does not give you raw entropy, but the output of a DRBG. 
So the 'raw' entropy is being emulated by taking multiple rounds of RDRAND 
output and shuffling it around to make it 'raw'

>From the top of RngDxe.c:

  RNG Algoritnms defined in UEFI 2.4:
   - EFI_RNG_ALGORITHM_SP800_90_CTR_256_GUID  - Supported
 (RDRAND implements a hardware NIST SP800-90 AES-CTR-256 based DRBG)
   - EFI_RNG_ALGORITHM_RAW- Supported
 (Structuring RDRAND invocation can be guaranteed as high-quality entropy 
source) ___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] RNG algo question

2016-09-17 Thread Ard Biesheuvel 
On 16 September 2016 at 22:33, Palmer, Thomas  wrote:
>
> EDK2 community
>
> Why is the RngGetRNG  sending requests for "gEfiRngAlgorithmRaw"  to 
> "RdRandGenerateEntropy",  which does AES operations on RDRAND output, whereas 
> the requests for "gEfiRngAlgorithmSp80090Ctr256Guid" get sent to 
> RdRandGetBytes which simply reads the rdrand source without modification.
>
> Shouldn't the processing be switched, so that "Raw" goes to RdRandGetBytes 
> and "gEfiRngAlgorithmSp80090Ctr256Guid" goes to RdRandGenerateEntropy?  I did 
> not see anything in the UEFI 2.5 spec indicating why this was the case.
>

The RDRAND instruction does not give you raw entropy, but the output
of a DRBG. So the 'raw' entropy is being emulated by taking multiple
rounds of RDRAND output and shuffling it around to make it 'raw'

>From the top of RngDxe.c:

  RNG Algoritnms defined in UEFI 2.4:
   - EFI_RNG_ALGORITHM_SP800_90_CTR_256_GUID  - Supported
 (RDRAND implements a hardware NIST SP800-90 AES-CTR-256 based DRBG)
   - EFI_RNG_ALGORITHM_RAW- Supported
 (Structuring RDRAND invocation can be guaranteed as high-quality
entropy source)
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel