Optimize the the AES-based implementation of the CTR_DRBG
construction, see 10.2.1 in [1].
Due to the optimizations, the code may deviate (more) from the
pseudocode in [1], but it is functional equivalence being decisive
for compliance:
"All DRBG mechanisms and algorithms are described in this document
in pseudocode, which is intended to explain functionality.
The pseudocode is not intended to constrain real-world
implementations." [9 in [1]].
The following optimizations are done:
- Replace multiple plain AES encryptions by a single AES-ECB
encryption of a corresponding pre-initialized buffer, where
possible.
This allows platform-specific AES-ECB support to
be used and reduces the overhead of multiple EVP calls.
- Replace the generate operation loop (which is a counter
increment followed by a plain AES encryption) by a
loop which does a plain AES encryption followed by
a counter increment. The latter loop is just a description
of AES-CTR, so we replace it by a single AES-CTR
encryption.
This allows for platform-specific AES-CTR support to be used
and reduces the overhead of multiple EVP calls.
This change, that is, going from a pre- to a post- counter
increment, requires the counter in the internal state
to be kept at "+1" (compared to the pseudocode in [1])
such that it is in the correct state, when a generate
operation is called.
That in turn also requires all other operations to be
changed from pre- to post-increment to keep functional
equivalence.
[1] NIST SP 800-90A Revision 1
Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10457)
The callback data allows passing context specific data from the
application of the DRBG to to the entropy callbacks.
This a rather specialized feature which is useful for implementing
known answer tests (KATs) or deterministic signatures (RFC6979),
which require passing a specified entropy and nonce for instantiating
the DRBG.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10950)
These fields are purely application data, and applications don't reach
into the bowels of the FIPS module, so these fields are never used
there.
Fixes#10835
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10837)
Make the include guards consistent by renaming them systematically according
to the naming conventions below
For the public header files (in the 'include/openssl' directory), the guard
names try to match the path specified in the include directives, with
all letters converted to upper case and '/' and '.' replaced by '_'. For the
private header files files, an extra 'OSSL_' is added as prefix.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9333)
Apart from public and internal header files, there is a third type called
local header files, which are located next to source files in the source
directory. Currently, they have different suffixes like
'*_lcl.h', '*_local.h', or '*_int.h'
This commit changes the different suffixes to '*_local.h' uniformly.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9333)
