2017-06-28 00:04:37 +08:00
|
|
|
/*
|
2020-04-23 20:55:52 +08:00
|
|
|
* Copyright 2011-2020 The OpenSSL Project Authors. All Rights Reserved.
|
2017-06-28 00:04:37 +08:00
|
|
|
*
|
2018-12-06 20:52:15 +08:00
|
|
|
* Licensed under the Apache License 2.0 (the "License"). You may not use
|
2017-06-28 00:04:37 +08:00
|
|
|
* this file except in compliance with the License. You can obtain a copy
|
|
|
|
* in the file LICENSE in the source distribution or at
|
|
|
|
* https://www.openssl.org/source/license.html
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <string.h>
|
|
|
|
#include <openssl/crypto.h>
|
|
|
|
#include <openssl/err.h>
|
|
|
|
#include <openssl/rand.h>
|
2020-05-08 08:25:19 +08:00
|
|
|
#include <openssl/aes.h>
|
|
|
|
#include "e_os.h" /* strcasecmp */
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
#include "crypto/modes.h"
|
2017-06-28 00:04:37 +08:00
|
|
|
#include "internal/thread_once.h"
|
2020-05-08 08:25:19 +08:00
|
|
|
#include "prov/implementations.h"
|
|
|
|
#include "prov/provider_ctx.h"
|
|
|
|
#include "prov/providercommonerr.h"
|
|
|
|
#include "drbg_local.h"
|
|
|
|
|
|
|
|
static OSSL_OP_rand_newctx_fn drbg_ctr_new_wrapper;
|
|
|
|
static OSSL_OP_rand_freectx_fn drbg_ctr_free;
|
|
|
|
static OSSL_OP_rand_instantiate_fn drbg_ctr_instantiate_wrapper;
|
|
|
|
static OSSL_OP_rand_uninstantiate_fn drbg_ctr_uninstantiate_wrapper;
|
|
|
|
static OSSL_OP_rand_generate_fn drbg_ctr_generate_wrapper;
|
|
|
|
static OSSL_OP_rand_reseed_fn drbg_ctr_reseed_wrapper;
|
|
|
|
static OSSL_OP_rand_settable_ctx_params_fn drbg_ctr_settable_ctx_params;
|
|
|
|
static OSSL_OP_rand_set_ctx_params_fn drbg_ctr_set_ctx_params;
|
|
|
|
static OSSL_OP_rand_gettable_ctx_params_fn drbg_ctr_gettable_ctx_params;
|
|
|
|
static OSSL_OP_rand_get_ctx_params_fn drbg_ctr_get_ctx_params;
|
|
|
|
static OSSL_OP_rand_verify_zeroization_fn drbg_ctr_verify_zeroization;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The state of a DRBG AES-CTR.
|
|
|
|
*/
|
|
|
|
typedef struct rand_drbg_ctr_st {
|
|
|
|
EVP_CIPHER_CTX *ctx_ecb;
|
|
|
|
EVP_CIPHER_CTX *ctx_ctr;
|
|
|
|
EVP_CIPHER_CTX *ctx_df;
|
|
|
|
EVP_CIPHER *cipher_ecb;
|
|
|
|
EVP_CIPHER *cipher_ctr;
|
|
|
|
size_t keylen;
|
|
|
|
int use_df;
|
|
|
|
unsigned char K[32];
|
|
|
|
unsigned char V[16];
|
|
|
|
/* Temporary block storage used by ctr_df */
|
|
|
|
unsigned char bltmp[16];
|
|
|
|
size_t bltmp_pos;
|
|
|
|
unsigned char KX[48];
|
|
|
|
} PROV_DRBG_CTR;
|
2018-07-24 09:16:38 +08:00
|
|
|
|
2017-06-28 00:04:37 +08:00
|
|
|
/*
|
2017-08-03 21:23:28 +08:00
|
|
|
* Implementation of NIST SP 800-90A CTR DRBG.
|
2017-06-28 00:04:37 +08:00
|
|
|
*/
|
2020-05-08 08:25:19 +08:00
|
|
|
static void inc_128(PROV_DRBG_CTR *ctr)
|
2017-06-28 00:04:37 +08:00
|
|
|
{
|
2020-02-22 08:20:09 +08:00
|
|
|
unsigned char *p = &ctr->V[0];
|
|
|
|
u32 n = 16, c = 1;
|
|
|
|
|
|
|
|
do {
|
|
|
|
--n;
|
|
|
|
c += p[n];
|
|
|
|
p[n] = (u8)c;
|
|
|
|
c >>= 8;
|
|
|
|
} while (n);
|
2017-06-28 00:04:37 +08:00
|
|
|
}
|
|
|
|
|
2020-05-08 08:25:19 +08:00
|
|
|
static void ctr_XOR(PROV_DRBG_CTR *ctr, const unsigned char *in, size_t inlen)
|
2017-06-28 00:04:37 +08:00
|
|
|
{
|
|
|
|
size_t i, n;
|
|
|
|
|
|
|
|
if (in == NULL || inlen == 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Any zero padding will have no effect on the result as we
|
|
|
|
* are XORing. So just process however much input we have.
|
|
|
|
*/
|
2017-08-03 21:23:28 +08:00
|
|
|
n = inlen < ctr->keylen ? inlen : ctr->keylen;
|
2017-06-28 00:04:37 +08:00
|
|
|
for (i = 0; i < n; i++)
|
2017-08-03 21:23:28 +08:00
|
|
|
ctr->K[i] ^= in[i];
|
|
|
|
if (inlen <= ctr->keylen)
|
2017-06-28 00:04:37 +08:00
|
|
|
return;
|
|
|
|
|
2017-08-03 21:23:28 +08:00
|
|
|
n = inlen - ctr->keylen;
|
2017-06-28 00:04:37 +08:00
|
|
|
if (n > 16) {
|
|
|
|
/* Should never happen */
|
|
|
|
n = 16;
|
|
|
|
}
|
2017-07-20 06:59:52 +08:00
|
|
|
for (i = 0; i < n; i++)
|
2017-08-03 21:23:28 +08:00
|
|
|
ctr->V[i] ^= in[i + ctr->keylen];
|
2017-06-28 00:04:37 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Process a complete block using BCC algorithm of SP 800-90A 10.3.3
|
|
|
|
*/
|
2020-05-08 08:25:19 +08:00
|
|
|
__owur static int ctr_BCC_block(PROV_DRBG_CTR *ctr, unsigned char *out,
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
const unsigned char *in, int len)
|
2017-06-28 00:04:37 +08:00
|
|
|
{
|
2018-03-10 19:23:21 +08:00
|
|
|
int i, outlen = AES_BLOCK_SIZE;
|
2017-06-28 00:04:37 +08:00
|
|
|
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
for (i = 0; i < len; i++)
|
2017-06-28 00:04:37 +08:00
|
|
|
out[i] ^= in[i];
|
2018-03-10 19:23:21 +08:00
|
|
|
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
if (!EVP_CipherUpdate(ctr->ctx_df, out, &outlen, out, len)
|
|
|
|
|| outlen != len)
|
2018-03-10 19:23:21 +08:00
|
|
|
return 0;
|
|
|
|
return 1;
|
2017-06-28 00:04:37 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Handle several BCC operations for as much data as we need for K and X
|
|
|
|
*/
|
2020-05-08 08:25:19 +08:00
|
|
|
__owur static int ctr_BCC_blocks(PROV_DRBG_CTR *ctr, const unsigned char *in)
|
2017-06-28 00:04:37 +08:00
|
|
|
{
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
unsigned char in_tmp[48];
|
|
|
|
unsigned char num_of_blk = 2;
|
|
|
|
|
|
|
|
memcpy(in_tmp, in, 16);
|
|
|
|
memcpy(in_tmp + 16, in, 16);
|
|
|
|
if (ctr->keylen != 16) {
|
|
|
|
memcpy(in_tmp + 32, in, 16);
|
|
|
|
num_of_blk = 3;
|
|
|
|
}
|
|
|
|
return ctr_BCC_block(ctr, ctr->KX, in_tmp, AES_BLOCK_SIZE * num_of_blk);
|
2017-06-28 00:04:37 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialise BCC blocks: these have the value 0,1,2 in leftmost positions:
|
|
|
|
* see 10.3.1 stage 7.
|
|
|
|
*/
|
2020-05-08 08:25:19 +08:00
|
|
|
__owur static int ctr_BCC_init(PROV_DRBG_CTR *ctr)
|
2017-06-28 00:04:37 +08:00
|
|
|
{
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
unsigned char bltmp[48] = {0};
|
|
|
|
unsigned char num_of_blk;
|
|
|
|
|
2017-08-03 21:23:28 +08:00
|
|
|
memset(ctr->KX, 0, 48);
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
num_of_blk = ctr->keylen == 16 ? 2 : 3;
|
|
|
|
bltmp[(AES_BLOCK_SIZE * 1) + 3] = 1;
|
|
|
|
bltmp[(AES_BLOCK_SIZE * 2) + 3] = 2;
|
|
|
|
return ctr_BCC_block(ctr, ctr->KX, bltmp, num_of_blk * AES_BLOCK_SIZE);
|
2017-06-28 00:04:37 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Process several blocks into BCC algorithm, some possibly partial
|
|
|
|
*/
|
2020-05-08 08:25:19 +08:00
|
|
|
__owur static int ctr_BCC_update(PROV_DRBG_CTR *ctr,
|
2018-03-10 19:23:21 +08:00
|
|
|
const unsigned char *in, size_t inlen)
|
2017-06-28 00:04:37 +08:00
|
|
|
{
|
|
|
|
if (in == NULL || inlen == 0)
|
2018-03-10 19:23:21 +08:00
|
|
|
return 1;
|
2017-06-28 00:04:37 +08:00
|
|
|
|
|
|
|
/* If we have partial block handle it first */
|
2017-08-03 21:23:28 +08:00
|
|
|
if (ctr->bltmp_pos) {
|
|
|
|
size_t left = 16 - ctr->bltmp_pos;
|
2017-06-28 00:04:37 +08:00
|
|
|
|
|
|
|
/* If we now have a complete block process it */
|
|
|
|
if (inlen >= left) {
|
2017-08-03 21:23:28 +08:00
|
|
|
memcpy(ctr->bltmp + ctr->bltmp_pos, in, left);
|
2018-03-10 19:23:21 +08:00
|
|
|
if (!ctr_BCC_blocks(ctr, ctr->bltmp))
|
|
|
|
return 0;
|
2017-08-03 21:23:28 +08:00
|
|
|
ctr->bltmp_pos = 0;
|
2017-06-28 00:04:37 +08:00
|
|
|
inlen -= left;
|
|
|
|
in += left;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Process zero or more complete blocks */
|
|
|
|
for (; inlen >= 16; in += 16, inlen -= 16) {
|
2018-03-10 19:23:21 +08:00
|
|
|
if (!ctr_BCC_blocks(ctr, in))
|
|
|
|
return 0;
|
2017-06-28 00:04:37 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Copy any remaining partial block to the temporary buffer */
|
|
|
|
if (inlen > 0) {
|
2017-08-03 21:23:28 +08:00
|
|
|
memcpy(ctr->bltmp + ctr->bltmp_pos, in, inlen);
|
|
|
|
ctr->bltmp_pos += inlen;
|
2017-06-28 00:04:37 +08:00
|
|
|
}
|
2018-03-10 19:23:21 +08:00
|
|
|
return 1;
|
2017-06-28 00:04:37 +08:00
|
|
|
}
|
|
|
|
|
2020-05-08 08:25:19 +08:00
|
|
|
__owur static int ctr_BCC_final(PROV_DRBG_CTR *ctr)
|
2017-06-28 00:04:37 +08:00
|
|
|
{
|
2017-08-03 21:23:28 +08:00
|
|
|
if (ctr->bltmp_pos) {
|
|
|
|
memset(ctr->bltmp + ctr->bltmp_pos, 0, 16 - ctr->bltmp_pos);
|
2018-03-10 19:23:21 +08:00
|
|
|
if (!ctr_BCC_blocks(ctr, ctr->bltmp))
|
|
|
|
return 0;
|
2017-06-28 00:04:37 +08:00
|
|
|
}
|
2018-03-10 19:23:21 +08:00
|
|
|
return 1;
|
2017-06-28 00:04:37 +08:00
|
|
|
}
|
|
|
|
|
2020-05-08 08:25:19 +08:00
|
|
|
__owur static int ctr_df(PROV_DRBG_CTR *ctr,
|
2018-03-10 19:23:21 +08:00
|
|
|
const unsigned char *in1, size_t in1len,
|
|
|
|
const unsigned char *in2, size_t in2len,
|
|
|
|
const unsigned char *in3, size_t in3len)
|
2017-06-28 00:04:37 +08:00
|
|
|
{
|
|
|
|
static unsigned char c80 = 0x80;
|
|
|
|
size_t inlen;
|
2017-08-03 21:23:28 +08:00
|
|
|
unsigned char *p = ctr->bltmp;
|
2018-03-10 19:23:21 +08:00
|
|
|
int outlen = AES_BLOCK_SIZE;
|
2017-06-28 00:04:37 +08:00
|
|
|
|
2018-03-10 19:23:21 +08:00
|
|
|
if (!ctr_BCC_init(ctr))
|
|
|
|
return 0;
|
2017-06-28 00:04:37 +08:00
|
|
|
if (in1 == NULL)
|
|
|
|
in1len = 0;
|
|
|
|
if (in2 == NULL)
|
|
|
|
in2len = 0;
|
|
|
|
if (in3 == NULL)
|
|
|
|
in3len = 0;
|
|
|
|
inlen = in1len + in2len + in3len;
|
|
|
|
/* Initialise L||N in temporary block */
|
|
|
|
*p++ = (inlen >> 24) & 0xff;
|
|
|
|
*p++ = (inlen >> 16) & 0xff;
|
|
|
|
*p++ = (inlen >> 8) & 0xff;
|
|
|
|
*p++ = inlen & 0xff;
|
|
|
|
|
|
|
|
/* NB keylen is at most 32 bytes */
|
|
|
|
*p++ = 0;
|
|
|
|
*p++ = 0;
|
|
|
|
*p++ = 0;
|
2017-08-03 21:23:28 +08:00
|
|
|
*p = (unsigned char)((ctr->keylen + 16) & 0xff);
|
|
|
|
ctr->bltmp_pos = 8;
|
2018-03-10 19:23:21 +08:00
|
|
|
if (!ctr_BCC_update(ctr, in1, in1len)
|
|
|
|
|| !ctr_BCC_update(ctr, in2, in2len)
|
|
|
|
|| !ctr_BCC_update(ctr, in3, in3len)
|
|
|
|
|| !ctr_BCC_update(ctr, &c80, 1)
|
|
|
|
|| !ctr_BCC_final(ctr))
|
|
|
|
return 0;
|
2017-06-28 00:04:37 +08:00
|
|
|
/* Set up key K */
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
if (!EVP_CipherInit_ex(ctr->ctx_ecb, NULL, NULL, ctr->KX, NULL, -1))
|
2018-03-10 19:23:21 +08:00
|
|
|
return 0;
|
2017-06-28 00:04:37 +08:00
|
|
|
/* X follows key K */
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
if (!EVP_CipherUpdate(ctr->ctx_ecb, ctr->KX, &outlen, ctr->KX + ctr->keylen,
|
2018-03-10 19:23:21 +08:00
|
|
|
AES_BLOCK_SIZE)
|
|
|
|
|| outlen != AES_BLOCK_SIZE)
|
|
|
|
return 0;
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
if (!EVP_CipherUpdate(ctr->ctx_ecb, ctr->KX + 16, &outlen, ctr->KX,
|
2018-03-10 19:23:21 +08:00
|
|
|
AES_BLOCK_SIZE)
|
|
|
|
|| outlen != AES_BLOCK_SIZE)
|
|
|
|
return 0;
|
2017-08-03 21:23:28 +08:00
|
|
|
if (ctr->keylen != 16)
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
if (!EVP_CipherUpdate(ctr->ctx_ecb, ctr->KX + 32, &outlen,
|
|
|
|
ctr->KX + 16, AES_BLOCK_SIZE)
|
2018-03-10 19:23:21 +08:00
|
|
|
|| outlen != AES_BLOCK_SIZE)
|
|
|
|
return 0;
|
|
|
|
return 1;
|
2017-06-28 00:04:37 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* NB the no-df Update in SP800-90A specifies a constant input length
|
|
|
|
* of seedlen, however other uses of this algorithm pad the input with
|
|
|
|
* zeroes if necessary and have up to two parameters XORed together,
|
2017-08-03 21:23:28 +08:00
|
|
|
* so we handle both cases in this function instead.
|
2017-06-28 00:04:37 +08:00
|
|
|
*/
|
2020-05-08 08:25:19 +08:00
|
|
|
__owur static int ctr_update(PROV_DRBG *drbg,
|
2018-03-10 19:23:21 +08:00
|
|
|
const unsigned char *in1, size_t in1len,
|
|
|
|
const unsigned char *in2, size_t in2len,
|
|
|
|
const unsigned char *nonce, size_t noncelen)
|
2017-06-28 00:04:37 +08:00
|
|
|
{
|
2020-05-08 08:25:19 +08:00
|
|
|
PROV_DRBG_CTR *ctr = (PROV_DRBG_CTR *)drbg->data;
|
2018-03-10 19:23:21 +08:00
|
|
|
int outlen = AES_BLOCK_SIZE;
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
unsigned char V_tmp[48], out[48];
|
|
|
|
unsigned char len;
|
2017-06-28 00:04:37 +08:00
|
|
|
|
2018-03-10 19:23:21 +08:00
|
|
|
/* correct key is already set up. */
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
memcpy(V_tmp, ctr->V, 16);
|
2017-08-03 21:23:28 +08:00
|
|
|
inc_128(ctr);
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
memcpy(V_tmp + 16, ctr->V, 16);
|
|
|
|
if (ctr->keylen == 16) {
|
|
|
|
len = 32;
|
|
|
|
} else {
|
2017-08-03 21:23:28 +08:00
|
|
|
inc_128(ctr);
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
memcpy(V_tmp + 32, ctr->V, 16);
|
|
|
|
len = 48;
|
2017-06-28 00:04:37 +08:00
|
|
|
}
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
if (!EVP_CipherUpdate(ctr->ctx_ecb, out, &outlen, V_tmp, len)
|
|
|
|
|| outlen != len)
|
2018-03-10 19:23:21 +08:00
|
|
|
return 0;
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
memcpy(ctr->K, out, ctr->keylen);
|
|
|
|
memcpy(ctr->V, out + ctr->keylen, 16);
|
2017-06-28 00:04:37 +08:00
|
|
|
|
2020-05-08 08:25:19 +08:00
|
|
|
if (ctr->use_df) {
|
2017-06-28 00:04:37 +08:00
|
|
|
/* If no input reuse existing derived value */
|
|
|
|
if (in1 != NULL || nonce != NULL || in2 != NULL)
|
2018-03-10 19:23:21 +08:00
|
|
|
if (!ctr_df(ctr, in1, in1len, nonce, noncelen, in2, in2len))
|
|
|
|
return 0;
|
2017-06-28 00:04:37 +08:00
|
|
|
/* If this a reuse input in1len != 0 */
|
|
|
|
if (in1len)
|
2017-08-03 21:23:28 +08:00
|
|
|
ctr_XOR(ctr, ctr->KX, drbg->seedlen);
|
2017-06-28 00:04:37 +08:00
|
|
|
} else {
|
2017-08-03 21:23:28 +08:00
|
|
|
ctr_XOR(ctr, in1, in1len);
|
|
|
|
ctr_XOR(ctr, in2, in2len);
|
2017-06-28 00:04:37 +08:00
|
|
|
}
|
|
|
|
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
if (!EVP_CipherInit_ex(ctr->ctx_ecb, NULL, NULL, ctr->K, NULL, -1)
|
|
|
|
|| !EVP_CipherInit_ex(ctr->ctx_ctr, NULL, NULL, ctr->K, NULL, -1))
|
2018-03-10 19:23:21 +08:00
|
|
|
return 0;
|
|
|
|
return 1;
|
2017-06-28 00:04:37 +08:00
|
|
|
}
|
|
|
|
|
2020-05-08 08:25:19 +08:00
|
|
|
static int drbg_ctr_instantiate(PROV_DRBG *drbg,
|
|
|
|
const unsigned char *entropy, size_t entropylen,
|
|
|
|
const unsigned char *nonce, size_t noncelen,
|
|
|
|
const unsigned char *pers, size_t perslen)
|
2017-06-28 00:04:37 +08:00
|
|
|
{
|
2020-05-08 08:25:19 +08:00
|
|
|
PROV_DRBG_CTR *ctr = (PROV_DRBG_CTR *)drbg->data;
|
2017-06-28 00:04:37 +08:00
|
|
|
|
DRBG: clarify difference between entropy counts and buffer lengths
Unlike the NIST DRBG standard, entropy counts are in bits and
buffer lengths are in bytes. This has lead to some confusion and
errors in the past, see my comment on PR 3789.
To clarify the destinction between entropy counts and buffer lengths,
a 'len' suffix has been added to all member names of RAND_DRBG which
represent buffer lengths:
- {min,max}_{entropy,adin,nonce,pers}
+ {min,max}_{entropy,adin,nonce,pers}len
This change makes naming also more consistent, as can be seen in the
diffs, for example:
- else if (adinlen > drbg->max_adin) {
+ else if (adinlen > drbg->max_adinlen) {
Also replaced all 'ent's by 'entropy's, following a suggestion of Paul Dale.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4266)
2017-08-21 05:02:46 +08:00
|
|
|
if (entropy == NULL)
|
2017-08-05 19:04:10 +08:00
|
|
|
return 0;
|
|
|
|
|
2017-08-03 21:23:28 +08:00
|
|
|
memset(ctr->K, 0, sizeof(ctr->K));
|
|
|
|
memset(ctr->V, 0, sizeof(ctr->V));
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
if (!EVP_CipherInit_ex(ctr->ctx_ecb, NULL, NULL, ctr->K, NULL, -1))
|
2018-03-10 19:23:21 +08:00
|
|
|
return 0;
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
|
|
|
|
inc_128(ctr);
|
2018-03-10 19:23:21 +08:00
|
|
|
if (!ctr_update(drbg, entropy, entropylen, pers, perslen, nonce, noncelen))
|
|
|
|
return 0;
|
2017-06-28 00:04:37 +08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2020-05-08 08:25:19 +08:00
|
|
|
static int drbg_ctr_instantiate_wrapper(void *vdrbg, unsigned int strength,
|
|
|
|
int prediction_resistance,
|
|
|
|
const unsigned char *pstr,
|
|
|
|
size_t pstr_len)
|
|
|
|
{
|
|
|
|
PROV_DRBG *drbg = (PROV_DRBG *)vdrbg;
|
|
|
|
|
|
|
|
return PROV_DRBG_instantiate(drbg, strength, prediction_resistance,
|
|
|
|
pstr, pstr_len);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int drbg_ctr_reseed(PROV_DRBG *drbg,
|
|
|
|
const unsigned char *entropy, size_t entropylen,
|
|
|
|
const unsigned char *adin, size_t adinlen)
|
2017-06-28 00:04:37 +08:00
|
|
|
{
|
2020-05-08 08:25:19 +08:00
|
|
|
PROV_DRBG_CTR *ctr = (PROV_DRBG_CTR *)drbg->data;
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
|
DRBG: clarify difference between entropy counts and buffer lengths
Unlike the NIST DRBG standard, entropy counts are in bits and
buffer lengths are in bytes. This has lead to some confusion and
errors in the past, see my comment on PR 3789.
To clarify the destinction between entropy counts and buffer lengths,
a 'len' suffix has been added to all member names of RAND_DRBG which
represent buffer lengths:
- {min,max}_{entropy,adin,nonce,pers}
+ {min,max}_{entropy,adin,nonce,pers}len
This change makes naming also more consistent, as can be seen in the
diffs, for example:
- else if (adinlen > drbg->max_adin) {
+ else if (adinlen > drbg->max_adinlen) {
Also replaced all 'ent's by 'entropy's, following a suggestion of Paul Dale.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4266)
2017-08-21 05:02:46 +08:00
|
|
|
if (entropy == NULL)
|
2017-08-05 19:04:10 +08:00
|
|
|
return 0;
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
|
|
|
|
inc_128(ctr);
|
2018-03-10 19:23:21 +08:00
|
|
|
if (!ctr_update(drbg, entropy, entropylen, adin, adinlen, NULL, 0))
|
|
|
|
return 0;
|
2017-06-28 00:04:37 +08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2020-05-08 08:25:19 +08:00
|
|
|
static int drbg_ctr_reseed_wrapper(void *vdrbg, int prediction_resistance,
|
|
|
|
const unsigned char *ent, size_t ent_len,
|
|
|
|
const unsigned char *adin, size_t adin_len)
|
|
|
|
{
|
|
|
|
PROV_DRBG *drbg = (PROV_DRBG *)vdrbg;
|
|
|
|
|
|
|
|
return PROV_DRBG_reseed(drbg, prediction_resistance, ent, ent_len,
|
|
|
|
adin, adin_len);
|
|
|
|
}
|
|
|
|
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
static void ctr96_inc(unsigned char *counter)
|
|
|
|
{
|
|
|
|
u32 n = 12, c = 1;
|
|
|
|
|
|
|
|
do {
|
|
|
|
--n;
|
|
|
|
c += counter[n];
|
|
|
|
counter[n] = (u8)c;
|
|
|
|
c >>= 8;
|
|
|
|
} while (n);
|
|
|
|
}
|
|
|
|
|
2020-05-08 08:25:19 +08:00
|
|
|
static int drbg_ctr_generate(PROV_DRBG *drbg,
|
|
|
|
unsigned char *out, size_t outlen,
|
|
|
|
const unsigned char *adin, size_t adinlen)
|
2017-06-28 00:04:37 +08:00
|
|
|
{
|
2020-05-08 08:25:19 +08:00
|
|
|
PROV_DRBG_CTR *ctr = (PROV_DRBG_CTR *)drbg->data;
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
unsigned int ctr32, blocks;
|
|
|
|
int outl, buflen;
|
2017-06-28 00:04:37 +08:00
|
|
|
|
|
|
|
if (adin != NULL && adinlen != 0) {
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
inc_128(ctr);
|
|
|
|
|
2018-03-10 19:23:21 +08:00
|
|
|
if (!ctr_update(drbg, adin, adinlen, NULL, 0, NULL, 0))
|
|
|
|
return 0;
|
2017-06-28 00:04:37 +08:00
|
|
|
/* This means we reuse derived value */
|
2020-05-08 08:25:19 +08:00
|
|
|
if (ctr->use_df) {
|
2017-06-28 00:04:37 +08:00
|
|
|
adin = NULL;
|
|
|
|
adinlen = 1;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
adinlen = 0;
|
|
|
|
}
|
|
|
|
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
inc_128(ctr);
|
2018-03-10 19:23:21 +08:00
|
|
|
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
if (outlen == 0) {
|
2017-08-03 21:23:28 +08:00
|
|
|
inc_128(ctr);
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
|
|
|
|
if (!ctr_update(drbg, adin, adinlen, NULL, 0, NULL, 0))
|
2018-03-10 19:23:21 +08:00
|
|
|
return 0;
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
return 1;
|
2017-06-28 00:04:37 +08:00
|
|
|
}
|
|
|
|
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
memset(out, 0, outlen);
|
|
|
|
|
|
|
|
do {
|
|
|
|
if (!EVP_CipherInit_ex(ctr->ctx_ctr,
|
|
|
|
NULL, NULL, NULL, ctr->V, -1))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*-
|
|
|
|
* outlen has type size_t while EVP_CipherUpdate takes an
|
|
|
|
* int argument and thus cannot be guaranteed to process more
|
|
|
|
* than 2^31-1 bytes at a time. We process such huge generate
|
|
|
|
* requests in 2^30 byte chunks, which is the greatest multiple
|
|
|
|
* of AES block size lower than or equal to 2^31-1.
|
|
|
|
*/
|
|
|
|
buflen = outlen > (1U << 30) ? (1U << 30) : outlen;
|
|
|
|
blocks = (buflen + 15) / 16;
|
|
|
|
|
|
|
|
ctr32 = GETU32(ctr->V + 12) + blocks;
|
|
|
|
if (ctr32 < blocks) {
|
|
|
|
/* 32-bit counter overflow into V. */
|
2020-06-02 17:52:24 +08:00
|
|
|
if (ctr32 != 0) {
|
|
|
|
blocks -= ctr32;
|
|
|
|
buflen = blocks * 16;
|
|
|
|
ctr32 = 0;
|
|
|
|
}
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
ctr96_inc(ctr->V);
|
|
|
|
}
|
|
|
|
PUTU32(ctr->V + 12, ctr32);
|
|
|
|
|
|
|
|
if (!EVP_CipherUpdate(ctr->ctx_ctr, out, &outl, out, buflen)
|
|
|
|
|| outl != buflen)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
out += buflen;
|
|
|
|
outlen -= buflen;
|
|
|
|
} while (outlen);
|
|
|
|
|
2018-03-10 19:23:21 +08:00
|
|
|
if (!ctr_update(drbg, adin, adinlen, NULL, 0, NULL, 0))
|
|
|
|
return 0;
|
2017-06-28 00:04:37 +08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2020-05-08 08:25:19 +08:00
|
|
|
static int drbg_ctr_generate_wrapper
|
|
|
|
(void *vdrbg, unsigned char *out, size_t outlen,
|
|
|
|
unsigned int strength, int prediction_resistance,
|
|
|
|
const unsigned char *adin, size_t adin_len)
|
2017-06-28 00:04:37 +08:00
|
|
|
{
|
2020-05-08 08:25:19 +08:00
|
|
|
PROV_DRBG *drbg = (PROV_DRBG *)vdrbg;
|
|
|
|
|
|
|
|
return PROV_DRBG_generate(drbg, out, outlen, strength,
|
|
|
|
prediction_resistance, adin, adin_len);
|
2017-06-28 00:04:37 +08:00
|
|
|
}
|
|
|
|
|
2020-05-08 08:25:19 +08:00
|
|
|
static int drbg_ctr_uninstantiate(PROV_DRBG *drbg)
|
|
|
|
{
|
|
|
|
PROV_DRBG_CTR *ctr = (PROV_DRBG_CTR *)drbg->data;
|
|
|
|
|
|
|
|
OPENSSL_cleanse(ctr->K, sizeof(ctr->K));
|
|
|
|
OPENSSL_cleanse(ctr->V, sizeof(ctr->V));
|
|
|
|
OPENSSL_cleanse(ctr->bltmp, sizeof(ctr->bltmp));
|
|
|
|
OPENSSL_cleanse(ctr->KX, sizeof(ctr->KX));
|
|
|
|
ctr->bltmp_pos = 0;
|
|
|
|
return PROV_DRBG_uninstantiate(drbg);
|
|
|
|
}
|
2017-12-29 04:42:14 +08:00
|
|
|
|
2020-05-08 08:25:19 +08:00
|
|
|
static int drbg_ctr_uninstantiate_wrapper(void *vdrbg)
|
2017-06-28 00:04:37 +08:00
|
|
|
{
|
2020-05-08 08:25:19 +08:00
|
|
|
return drbg_ctr_uninstantiate((PROV_DRBG *)vdrbg);
|
|
|
|
}
|
2017-06-28 00:04:37 +08:00
|
|
|
|
2020-05-08 08:25:19 +08:00
|
|
|
static int drbg_ctr_verify_zeroization(void *vdrbg)
|
|
|
|
{
|
|
|
|
PROV_DRBG *drbg = (PROV_DRBG *)vdrbg;
|
|
|
|
PROV_DRBG_CTR *ctr = (PROV_DRBG_CTR *)drbg->data;
|
|
|
|
|
|
|
|
PROV_DRBG_VERYIFY_ZEROIZATION(ctr->K);
|
|
|
|
PROV_DRBG_VERYIFY_ZEROIZATION(ctr->V);
|
|
|
|
PROV_DRBG_VERYIFY_ZEROIZATION(ctr->bltmp);
|
|
|
|
PROV_DRBG_VERYIFY_ZEROIZATION(ctr->KX);
|
|
|
|
if (ctr->bltmp_pos != 0)
|
2017-11-21 06:27:23 +08:00
|
|
|
return 0;
|
2020-05-08 08:25:19 +08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int drbg_ctr_init_lengths(PROV_DRBG *drbg)
|
|
|
|
{
|
|
|
|
PROV_DRBG_CTR *ctr = (PROV_DRBG_CTR *)drbg->data;
|
|
|
|
int res = 1;
|
|
|
|
|
|
|
|
#ifdef FIPS_MODULE
|
|
|
|
if (!ctr->use_df) {
|
|
|
|
PROVerr(0, RAND_R_DERIVATION_FUNCTION_MANDATORY_FOR_FIPS);
|
|
|
|
ctr->use_df = 1;
|
|
|
|
res = 0;
|
2017-06-28 00:04:37 +08:00
|
|
|
}
|
2020-05-08 08:25:19 +08:00
|
|
|
#endif
|
|
|
|
/* Maximum number of bits per request = 2^19 = 2^16 bytes */
|
|
|
|
drbg->max_request = 1 << 16;
|
|
|
|
if (ctr->use_df) {
|
|
|
|
drbg->min_entropylen = 0;
|
|
|
|
drbg->max_entropylen = DRBG_MAX_LENGTH;
|
|
|
|
drbg->min_noncelen = 0;
|
|
|
|
drbg->max_noncelen = DRBG_MAX_LENGTH;
|
|
|
|
drbg->max_perslen = DRBG_MAX_LENGTH;
|
|
|
|
drbg->max_adinlen = DRBG_MAX_LENGTH;
|
2019-05-23 21:35:42 +08:00
|
|
|
|
2020-05-08 08:25:19 +08:00
|
|
|
if (ctr->keylen > 0) {
|
|
|
|
drbg->min_entropylen = ctr->keylen;
|
|
|
|
drbg->min_noncelen = drbg->min_entropylen / 2;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
const size_t len = ctr->keylen > 0 ? drbg->seedlen : DRBG_MAX_LENGTH;
|
|
|
|
|
|
|
|
drbg->min_entropylen = len;
|
|
|
|
drbg->max_entropylen = len;
|
|
|
|
/* Nonce not used */
|
|
|
|
drbg->min_noncelen = 0;
|
|
|
|
drbg->max_noncelen = 0;
|
|
|
|
drbg->max_perslen = len;
|
|
|
|
drbg->max_adinlen = len;
|
|
|
|
}
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int drbg_ctr_init(PROV_DRBG *drbg)
|
|
|
|
{
|
|
|
|
PROV_DRBG_CTR *ctr = (PROV_DRBG_CTR *)drbg->data;
|
|
|
|
const size_t keylen = EVP_CIPHER_key_length(ctr->cipher_ctr);
|
2017-12-29 04:42:14 +08:00
|
|
|
|
2017-08-03 21:23:28 +08:00
|
|
|
ctr->keylen = keylen;
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
if (ctr->ctx_ecb == NULL)
|
|
|
|
ctr->ctx_ecb = EVP_CIPHER_CTX_new();
|
|
|
|
if (ctr->ctx_ctr == NULL)
|
|
|
|
ctr->ctx_ctr = EVP_CIPHER_CTX_new();
|
2020-05-08 08:25:19 +08:00
|
|
|
if (ctr->ctx_ecb == NULL || ctr->ctx_ctr == NULL) {
|
|
|
|
ERR_raise(ERR_LIB_PROV, ERR_R_MALLOC_FAILURE);
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ctr->cipher_ctr != NULL) {
|
|
|
|
if (!EVP_CipherInit_ex(ctr->ctx_ecb,
|
|
|
|
ctr->cipher_ecb, NULL, NULL, NULL, 1)
|
|
|
|
|| !EVP_CipherInit_ex(ctr->ctx_ctr,
|
|
|
|
ctr->cipher_ctr, NULL, NULL, NULL, 1)) {
|
|
|
|
ERR_raise(ERR_LIB_PROV, PROV_R_UNABLE_TO_INITIALISE_CIPHERS);
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
drbg->strength = keylen * 8;
|
|
|
|
drbg->seedlen = keylen + 16;
|
|
|
|
|
|
|
|
if (ctr->use_df) {
|
|
|
|
/* df initialisation */
|
|
|
|
static const unsigned char df_key[32] = {
|
|
|
|
0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
|
|
|
|
0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f,
|
|
|
|
0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17,
|
|
|
|
0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f
|
|
|
|
};
|
|
|
|
|
|
|
|
if (ctr->ctx_df == NULL)
|
|
|
|
ctr->ctx_df = EVP_CIPHER_CTX_new();
|
|
|
|
if (ctr->ctx_df == NULL) {
|
|
|
|
ERR_raise(ERR_LIB_PROV, ERR_R_MALLOC_FAILURE);
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
/* Set key schedule for df_key */
|
|
|
|
if (!EVP_CipherInit_ex(ctr->ctx_df,
|
|
|
|
ctr->cipher_ecb, NULL, df_key, NULL, 1)) {
|
|
|
|
ERR_raise(ERR_LIB_PROV, PROV_R_DERIVATION_FUNCTION_INIT_FAILED);
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return drbg_ctr_init_lengths(drbg);
|
|
|
|
|
|
|
|
err:
|
|
|
|
EVP_CIPHER_CTX_free(ctr->ctx_ecb);
|
|
|
|
EVP_CIPHER_CTX_free(ctr->ctx_ctr);
|
|
|
|
ctr->ctx_ecb = ctr->ctx_ctr = NULL;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int drbg_ctr_new(PROV_DRBG *drbg)
|
|
|
|
{
|
|
|
|
PROV_DRBG_CTR *ctr;
|
|
|
|
|
|
|
|
ctr = OPENSSL_secure_zalloc(sizeof(*ctr));
|
|
|
|
if (ctr == NULL) {
|
|
|
|
ERR_raise(ERR_LIB_PROV, ERR_R_MALLOC_FAILURE);
|
2018-03-10 19:23:21 +08:00
|
|
|
return 0;
|
2020-05-08 08:25:19 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
ctr->use_df = 1;
|
|
|
|
drbg->data = ctr;
|
|
|
|
return drbg_ctr_init_lengths(drbg);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void *drbg_ctr_new_wrapper(void *provctx, void *parent,
|
|
|
|
const OSSL_DISPATCH *parent_dispatch)
|
|
|
|
{
|
|
|
|
return prov_rand_drbg_new(provctx, parent, parent_dispatch, &drbg_ctr_new,
|
|
|
|
&drbg_ctr_instantiate, &drbg_ctr_uninstantiate,
|
|
|
|
&drbg_ctr_reseed, &drbg_ctr_generate);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void drbg_ctr_free(void *vdrbg)
|
|
|
|
{
|
|
|
|
PROV_DRBG *drbg = (PROV_DRBG *)vdrbg;
|
|
|
|
PROV_DRBG_CTR *ctr;
|
|
|
|
|
|
|
|
if (drbg != NULL && (ctr = (PROV_DRBG_CTR *)drbg->data) != NULL) {
|
|
|
|
EVP_CIPHER_CTX_free(ctr->ctx_ecb);
|
|
|
|
EVP_CIPHER_CTX_free(ctr->ctx_ctr);
|
|
|
|
EVP_CIPHER_CTX_free(ctr->ctx_df);
|
|
|
|
EVP_CIPHER_free(ctr->cipher_ecb);
|
|
|
|
EVP_CIPHER_free(ctr->cipher_ctr);
|
|
|
|
|
|
|
|
OPENSSL_secure_clear_free(ctr, sizeof(*ctr));
|
|
|
|
}
|
|
|
|
prov_rand_drbg_free(drbg);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int drbg_ctr_get_ctx_params(void *vdrbg, OSSL_PARAM params[])
|
|
|
|
{
|
|
|
|
PROV_DRBG *drbg = (PROV_DRBG *)vdrbg;
|
|
|
|
|
|
|
|
return drbg_get_ctx_params(drbg, params);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const OSSL_PARAM *drbg_ctr_gettable_ctx_params(void)
|
|
|
|
{
|
|
|
|
static const OSSL_PARAM known_gettable_ctx_params[] = {
|
|
|
|
OSSL_PARAM_DRBG_GETABLE_CTX_COMMON,
|
|
|
|
OSSL_PARAM_END
|
|
|
|
};
|
|
|
|
return known_gettable_ctx_params;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int drbg_ctr_set_ctx_params(void *vctx, const OSSL_PARAM params[])
|
|
|
|
{
|
|
|
|
PROV_DRBG *ctx = (PROV_DRBG *)vctx;
|
|
|
|
PROV_DRBG_CTR *ctr = (PROV_DRBG_CTR *)ctx->data;
|
|
|
|
OPENSSL_CTX *libctx = PROV_LIBRARY_CONTEXT_OF(ctx->provctx);
|
|
|
|
const OSSL_PARAM *p;
|
|
|
|
char *ecb;
|
|
|
|
const char *propquery = NULL;
|
|
|
|
int i, cipher_init = 0;
|
|
|
|
|
|
|
|
if ((p = OSSL_PARAM_locate_const(params, OSSL_DRBG_PARAM_USE_DF)) != NULL
|
|
|
|
&& OSSL_PARAM_get_int(p, &i)) {
|
|
|
|
/* FIPS errors out in the drbg_ctr_init() call later */
|
|
|
|
ctr->use_df = i != 0;
|
|
|
|
cipher_init = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((p = OSSL_PARAM_locate_const(params,
|
|
|
|
OSSL_DRBG_PARAM_PROPERTIES)) != NULL) {
|
|
|
|
if (p->data_type != OSSL_PARAM_UTF8_STRING)
|
|
|
|
return 0;
|
|
|
|
propquery = (const char *)p->data;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((p = OSSL_PARAM_locate_const(params, OSSL_DRBG_PARAM_CIPHER)) != NULL) {
|
|
|
|
const char *base = (const char *)p->data;
|
AES CTR-DRGB: performance improvement
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)
2019-11-16 06:27:09 +08:00
|
|
|
|
2020-05-08 08:25:19 +08:00
|
|
|
if (p->data_type != OSSL_PARAM_UTF8_STRING
|
|
|
|
|| p->data_size < 3)
|
2018-03-10 19:23:21 +08:00
|
|
|
return 0;
|
2020-05-08 08:25:19 +08:00
|
|
|
if (strcasecmp("CTR", base + p->data_size - sizeof("CTR")) != 0) {
|
|
|
|
ERR_raise(ERR_LIB_PROV, PROV_R_REQUIRE_CTR_MODE_CIPHER);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
if ((ecb = OPENSSL_strdup(base)) == NULL) {
|
|
|
|
ERR_raise(ERR_LIB_PROV, ERR_R_MALLOC_FAILURE);
|
2018-03-10 19:23:21 +08:00
|
|
|
return 0;
|
2020-05-08 08:25:19 +08:00
|
|
|
}
|
|
|
|
strcpy(ecb + p->data_size - sizeof("ECB"), "ECB");
|
|
|
|
EVP_CIPHER_free(ctr->cipher_ecb);
|
|
|
|
EVP_CIPHER_free(ctr->cipher_ctr);
|
|
|
|
ctr->cipher_ctr = EVP_CIPHER_fetch(libctx, base, propquery);
|
|
|
|
ctr->cipher_ecb = EVP_CIPHER_fetch(libctx, ecb, propquery);
|
|
|
|
OPENSSL_free(ecb);
|
|
|
|
if (ctr->cipher_ctr == NULL || ctr->cipher_ecb == NULL) {
|
|
|
|
ERR_raise(ERR_LIB_PROV, PROV_R_UNABLE_TO_FIND_CIPHERS);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
cipher_init = 1;
|
|
|
|
}
|
2017-08-03 21:23:28 +08:00
|
|
|
|
2020-05-08 08:25:19 +08:00
|
|
|
if (cipher_init && !drbg_ctr_init(ctx))
|
2019-04-11 06:52:22 +08:00
|
|
|
return 0;
|
2017-06-28 00:04:37 +08:00
|
|
|
|
2020-05-08 08:25:19 +08:00
|
|
|
return drbg_set_ctx_params(ctx, params);
|
|
|
|
}
|
2018-03-10 01:24:23 +08:00
|
|
|
|
2020-05-08 08:25:19 +08:00
|
|
|
static const OSSL_PARAM *drbg_ctr_settable_ctx_params(void)
|
|
|
|
{
|
|
|
|
static const OSSL_PARAM known_settable_ctx_params[] = {
|
|
|
|
OSSL_PARAM_utf8_string(OSSL_DRBG_PARAM_PROPERTIES, NULL, 0),
|
|
|
|
OSSL_PARAM_utf8_string(OSSL_DRBG_PARAM_CIPHER, NULL, 0),
|
|
|
|
#ifndef FIPS_MODULE
|
|
|
|
/*
|
|
|
|
* Don't advertise this for FIPS, it isn't allowed to change.
|
|
|
|
* The parameter can still be passed and will be processed but errors
|
|
|
|
* out.
|
|
|
|
*/
|
|
|
|
OSSL_PARAM_int(OSSL_DRBG_PARAM_USE_DF, NULL),
|
|
|
|
#endif
|
|
|
|
OSSL_PARAM_DRBG_SETABLE_CTX_COMMON,
|
|
|
|
OSSL_PARAM_END
|
|
|
|
};
|
|
|
|
return known_settable_ctx_params;
|
2017-06-28 00:04:37 +08:00
|
|
|
}
|
2020-05-08 08:25:19 +08:00
|
|
|
|
|
|
|
const OSSL_DISPATCH drbg_ctr_functions[] = {
|
|
|
|
{ OSSL_FUNC_RAND_NEWCTX, (void(*)(void))drbg_ctr_new_wrapper },
|
|
|
|
{ OSSL_FUNC_RAND_FREECTX, (void(*)(void))drbg_ctr_free },
|
|
|
|
{ OSSL_FUNC_RAND_INSTANTIATE,
|
|
|
|
(void(*)(void))drbg_ctr_instantiate_wrapper },
|
|
|
|
{ OSSL_FUNC_RAND_UNINSTANTIATE,
|
|
|
|
(void(*)(void))drbg_ctr_uninstantiate_wrapper },
|
|
|
|
{ OSSL_FUNC_RAND_GENERATE, (void(*)(void))drbg_ctr_generate_wrapper },
|
|
|
|
{ OSSL_FUNC_RAND_RESEED, (void(*)(void))drbg_ctr_reseed_wrapper },
|
|
|
|
{ OSSL_FUNC_RAND_ENABLE_LOCKING, (void(*)(void))drbg_enable_locking },
|
|
|
|
{ OSSL_FUNC_RAND_LOCK, (void(*)(void))drbg_lock },
|
|
|
|
{ OSSL_FUNC_RAND_UNLOCK, (void(*)(void))drbg_unlock },
|
|
|
|
{ OSSL_FUNC_RAND_SETTABLE_CTX_PARAMS,
|
|
|
|
(void(*)(void))drbg_ctr_settable_ctx_params },
|
|
|
|
{ OSSL_FUNC_RAND_SET_CTX_PARAMS, (void(*)(void))drbg_ctr_set_ctx_params },
|
|
|
|
{ OSSL_FUNC_RAND_GETTABLE_CTX_PARAMS,
|
|
|
|
(void(*)(void))drbg_ctr_gettable_ctx_params },
|
|
|
|
{ OSSL_FUNC_RAND_GET_CTX_PARAMS, (void(*)(void))drbg_ctr_get_ctx_params },
|
|
|
|
{ OSSL_FUNC_RAND_SET_CALLBACKS, (void(*)(void))drbg_set_callbacks },
|
|
|
|
{ OSSL_FUNC_RAND_VERIFY_ZEROIZATION,
|
|
|
|
(void(*)(void))drbg_ctr_verify_zeroization },
|
|
|
|
{ 0, NULL }
|
|
|
|
};
|