On 11/9/21, 23:07, "Dr Paul Dale" <pauli@xxxxxxxxxxx> wrote: > There is documentation: https://www.openssl.org/docs/man3.0/man5/config.html Yes, I know. Alas, it's not helpful at all. RDRAND is an *engine*, but it does not seem to have a "separate" physical presence, like a shared library. For other engines I specify something like [openssl_init] providers = provider_sect engines = engine_section # List of providers to load [provider_sect] default = default_sect legacy = legacy_sect [default_sect] activate = 1 [legacy_sect] activate = 1 [engine_section] pkcs11 = pkcs11_section gost = gost_section [pkcs11_section] engine_id = pkcs11 dynamic_path = /opt/local/libexec/openssl3/lib/engines-3/pkcs11.dylib MODULE_PATH = /Library/OpenSC/lib/opensc-pkcs11.so init = 0 [gost_section] engine_id = gost dynamic_path = /opt/local/libexec/openssl3/lib/engines-3/gost.dylib #default_algorithms = ALL #CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet PBE_PARAMS = "gost12_512" Where does "rdrand" engine fit in, and how do I tell OpenSSL to load it? There's no "dynamic_path" that I know of. I don't think the rdrand engine takes any extras. Pauli On 10/11/21 1:38 pm, Blumenthal, Uri - 0553 - MITLL wrote: > On 11/9/21, 22:23, "Dr Paul Dale" <pauli@xxxxxxxxxxx> 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-bounces@xxxxxxxxxxx on behalf of pauli@xxxxxxxxxxx> 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
