On 11/9/21, 22:23, "Dr Paul Dale" <pa...@openssl.org> wrote:

>    Currently I've no idea and can't reproduce locally :(

Maybe you'd know how to force the "-engine rdrand" path through "openssl.cnf"?

>    A rogue configuration file could cause the DRBGs/seeds to fail.  Do you 
>    have seed=rdrand line in the random section?  That will cause the 
>    seeding source to fail to load at all.

No, I don't - and providing empty config causes the same result:

$ OPENSSL_CONF=/dev/null openssl3 rand -hex 4
$ OPENSSL_CONF=/dev/null openssl3 rand -engine rdrand -hex 4
Engine "rdrand" set.
61f1666d
$


    Pauli

    On 10/11/21 1:10 pm, Blumenthal, Uri - 0553 - MITLL wrote:
    > Thank you!
    >
    > I'm trying to:
    >
    > a. understand why something like "openssl-3 rand -hex 4" does not work 
(returns empty string), but "openssl-3 rand -engine rdrand -hex 4" works fine, 
and gives me my random bytes - here's an illustration
    >
    > $ openssl3 version
    > OpenSSL 3.1.0-dev  (Library: OpenSSL 3.1.0-dev )
    > $ openssl3 info -seeds
    > rdrand ( rdseed rdrand ) os-specific
    > $ openssl3 rand -hex 4
    > $ openssl3 rand -engine rdrand -hex 4
    > Engine "rdrand" set.
    > d9b8f268
    >
    > and
    >
    > b. somehow force RDRAND engine to be loaded and initialized by default, 
so I don't have to include "-engine rdrand" in every invocation, especially 
since I often need to specify other engines (like "pkcs11").
    >
    > Here's my config, in case you spot something wrong with it (and yes, it 
includes "rdcpu"):
    >
    > ./config --prefix=${OPENSSL_DIR} --debug --openssldir=${OPENSSL_DIR}/etc 
--with-rand-seed=rdcpu,os enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 
enable-rmd160 enable-weak-ssl-ciphers zlib-dynamic enable-ssl-trace 
enable-trace threads enable-buildtest-c++
    >
    > Thanks
    > --
    > Regards,
    > Uri
    >   
    > There are two ways to design a system. One is to make is so simple there 
are obviously no deficiencies.
    > The other is to make it so complex there are no obvious deficiencies.
    >                                                                           
                                                            -  C. A. R. Hoare
    >   
    >
    > On 11/9/21, 21:49, "openssl-users on behalf of Dr Paul Dale" 
<openssl-users-boun...@openssl.org on behalf of pa...@openssl.org> wrote:
    >
    >      Currently there is exactly one seed source that is usable in OpenSSL
    >      3.0: "SEED-SRC".  It is documented in EVP_RAND-SEED-SRC.  The reason 
the
    >      seed source can be set is to allow you to use a third party provider
    >      than includes one.
    >
    >      If you want to force RDRAND as the only seeding source, this needs 
to be
    >      done at configuration time with the --with-rand-seed configuration
    >      option.  Note that this will enable RDSEED in preference to RDRAND 
but
    >      will use RDRAND if RDSEED isn't available.
    >
    >      I assume that you meant openssl info -seeds not openssl list -seeds.
    >      This lists the seed sources that were configured at build time.
    >
    >
    >      There is no relationship between the RDRAND engine and the seed
    >      sources.  Well, they both use the same machine instruction to get the
    >      seed material but it's called from completely different places.
    >
    >
    >      Yes, the man pages could be more informative and user friendly :(
    >
    >
    >      Pauli
    >
    >      On 10/11/21 12:35 pm, Blumenthal, Uri - 0553 - MITLL wrote:
    >      > "man config" for OpenSSL-3.0 and newer says that there can be 
"[random]" section in "openssl.cnf", where I can specify type of RNG, other 
things, and *seed*, and seed *properties*.
    >      >
    >      > Unfortunately, it did not bother to even list the possible/allowed 
values, let alone explain what they'd mean:
    >      >
    >      >     Random Configuration
    >      >         The name random in the initialization section names the 
section containing the random number
    >      >         generater settings.
    >      >
    >      >         Within the random section, the following names have 
meaning:
    >      >
    >      >         random
    >      >             This is used to specify the random bit generator.  For 
example:
    >      >
    >      >              [random]
    >      >              random = CTR-DRBG
    >      >
    >      >             The available random bit generators are:
    >      >
    >      >             CTR-DRBG
    >      >             HASH-DRBG
    >      >             HMAC-DRBG
    >      > .  .  .  .  .
    >      >         properties
    >      >             This sets the property query used when fetching the 
random bit generator and any
    >      >             underlying algorithms.
    >      >
    >      >         seed
    >      >             This sets the randomness source that should be used.  
By default SEED-SRC will be used
    >      >             outside of the FIPS provider.  The FIPS provider uses 
call backs to access the same
    >      >             randomness sources from outside the validated boundary.
    >      >
    >      >         seed_properties
    >      >             This sets the property query used when fetching the 
randomness source.
    >      >
    >      > I want to configure this [random] to use CTR-DRBG, using RDRAND as 
"seed". Based on "openssl list -seeds", I guess "seed = rdrand" should be OK. 
What properties can I set, if any? How does this "[random]" relate to the 
RDRAND *engine* (see below)?
    >      >
    >      > $ openssl3 engine rdrand -t
    >      > (rdrand) Intel RDRAND engine
    >      >       [ available ]
    >      >
    >      >
    >      > Thanks!
    >      > --
    >      > Regards,
    >      > Uri Blumenthal                              Voice: (781) 981-1638
    >      > Secure Resilient Systems and Technologies   Cell:  (339) 223-5363
    >      > MIT Lincoln Laboratory
    >      > 244 Wood Street, Lexington, MA  02420-9108
    >      >
    >      > Web:     https://www.ll.mit.edu/biographies/uri-blumenthal
    >      > Root CA: https://www.ll.mit.edu/llrca2.pem
    >      >
    >      > There are two ways to design a system. One is to make is so simple 
there are obviously no deficiencies.
    >      > The other is to make it so complex there are no obvious 
deficiencies.
    >      >                                                                    
                                                                   -  C. A. R. 
Hoare
    >      >
    >

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to