2017-06-27 12:04:37 -04:00
|
|
|
/*
|
2018-01-09 05:49:01 +01:00
|
|
|
* Copyright 2011-2018 The OpenSSL Project Authors. All Rights Reserved.
|
2017-06-27 12:04:37 -04:00
|
|
|
*
|
2018-12-06 13:52:15 +01:00
|
|
|
* Licensed under the Apache License 2.0 (the "License"). You may not use
|
2017-06-27 12:04:37 -04: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>
|
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-15 23:27:09 +01:00
|
|
|
#include "crypto/modes.h"
|
2017-06-27 12:04:37 -04:00
|
|
|
#include "internal/thread_once.h"
|
2019-09-28 00:45:40 +02:00
|
|
|
#include "rand_local.h"
|
2018-07-24 11:16:38 +10:00
|
|
|
|
2017-06-27 12:04:37 -04:00
|
|
|
/*
|
2017-08-03 09:23:28 -04:00
|
|
|
* Implementation of NIST SP 800-90A CTR DRBG.
|
2017-06-27 12:04:37 -04:00
|
|
|
*/
|
2017-08-03 09:23:28 -04:00
|
|
|
static void inc_128(RAND_DRBG_CTR *ctr)
|
2017-06-27 12:04:37 -04:00
|
|
|
{
|
2020-02-22 01:20:09 +01: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-27 12:04:37 -04:00
|
|
|
}
|
|
|
|
|
2017-08-03 09:23:28 -04:00
|
|
|
static void ctr_XOR(RAND_DRBG_CTR *ctr, const unsigned char *in, size_t inlen)
|
2017-06-27 12:04:37 -04: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 09:23:28 -04:00
|
|
|
n = inlen < ctr->keylen ? inlen : ctr->keylen;
|
2017-06-27 12:04:37 -04:00
|
|
|
for (i = 0; i < n; i++)
|
2017-08-03 09:23:28 -04:00
|
|
|
ctr->K[i] ^= in[i];
|
|
|
|
if (inlen <= ctr->keylen)
|
2017-06-27 12:04:37 -04:00
|
|
|
return;
|
|
|
|
|
2017-08-03 09:23:28 -04:00
|
|
|
n = inlen - ctr->keylen;
|
2017-06-27 12:04:37 -04:00
|
|
|
if (n > 16) {
|
|
|
|
/* Should never happen */
|
|
|
|
n = 16;
|
|
|
|
}
|
2017-07-19 17:59:52 -05:00
|
|
|
for (i = 0; i < n; i++)
|
2017-08-03 09:23:28 -04:00
|
|
|
ctr->V[i] ^= in[i + ctr->keylen];
|
2017-06-27 12:04:37 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Process a complete block using BCC algorithm of SP 800-90A 10.3.3
|
|
|
|
*/
|
2018-03-10 12:23:21 +01:00
|
|
|
__owur static int ctr_BCC_block(RAND_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-15 23:27:09 +01:00
|
|
|
const unsigned char *in, int len)
|
2017-06-27 12:04:37 -04:00
|
|
|
{
|
2018-03-10 12:23:21 +01:00
|
|
|
int i, outlen = AES_BLOCK_SIZE;
|
2017-06-27 12:04:37 -04: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-15 23:27:09 +01:00
|
|
|
for (i = 0; i < len; i++)
|
2017-06-27 12:04:37 -04:00
|
|
|
out[i] ^= in[i];
|
2018-03-10 12:23:21 +01: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-15 23:27:09 +01:00
|
|
|
if (!EVP_CipherUpdate(ctr->ctx_df, out, &outlen, out, len)
|
|
|
|
|| outlen != len)
|
2018-03-10 12:23:21 +01:00
|
|
|
return 0;
|
|
|
|
return 1;
|
2017-06-27 12:04:37 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Handle several BCC operations for as much data as we need for K and X
|
|
|
|
*/
|
2018-03-10 12:23:21 +01:00
|
|
|
__owur static int ctr_BCC_blocks(RAND_DRBG_CTR *ctr, const unsigned char *in)
|
2017-06-27 12:04:37 -04: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-15 23:27:09 +01: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-27 12:04:37 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialise BCC blocks: these have the value 0,1,2 in leftmost positions:
|
|
|
|
* see 10.3.1 stage 7.
|
|
|
|
*/
|
2018-03-10 12:23:21 +01:00
|
|
|
__owur static int ctr_BCC_init(RAND_DRBG_CTR *ctr)
|
2017-06-27 12:04:37 -04: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-15 23:27:09 +01:00
|
|
|
unsigned char bltmp[48] = {0};
|
|
|
|
unsigned char num_of_blk;
|
|
|
|
|
2017-08-03 09:23:28 -04: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-15 23:27:09 +01: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-27 12:04:37 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Process several blocks into BCC algorithm, some possibly partial
|
|
|
|
*/
|
2018-03-10 12:23:21 +01:00
|
|
|
__owur static int ctr_BCC_update(RAND_DRBG_CTR *ctr,
|
|
|
|
const unsigned char *in, size_t inlen)
|
2017-06-27 12:04:37 -04:00
|
|
|
{
|
|
|
|
if (in == NULL || inlen == 0)
|
2018-03-10 12:23:21 +01:00
|
|
|
return 1;
|
2017-06-27 12:04:37 -04:00
|
|
|
|
|
|
|
/* If we have partial block handle it first */
|
2017-08-03 09:23:28 -04:00
|
|
|
if (ctr->bltmp_pos) {
|
|
|
|
size_t left = 16 - ctr->bltmp_pos;
|
2017-06-27 12:04:37 -04:00
|
|
|
|
|
|
|
/* If we now have a complete block process it */
|
|
|
|
if (inlen >= left) {
|
2017-08-03 09:23:28 -04:00
|
|
|
memcpy(ctr->bltmp + ctr->bltmp_pos, in, left);
|
2018-03-10 12:23:21 +01:00
|
|
|
if (!ctr_BCC_blocks(ctr, ctr->bltmp))
|
|
|
|
return 0;
|
2017-08-03 09:23:28 -04:00
|
|
|
ctr->bltmp_pos = 0;
|
2017-06-27 12:04:37 -04:00
|
|
|
inlen -= left;
|
|
|
|
in += left;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Process zero or more complete blocks */
|
|
|
|
for (; inlen >= 16; in += 16, inlen -= 16) {
|
2018-03-10 12:23:21 +01:00
|
|
|
if (!ctr_BCC_blocks(ctr, in))
|
|
|
|
return 0;
|
2017-06-27 12:04:37 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Copy any remaining partial block to the temporary buffer */
|
|
|
|
if (inlen > 0) {
|
2017-08-03 09:23:28 -04:00
|
|
|
memcpy(ctr->bltmp + ctr->bltmp_pos, in, inlen);
|
|
|
|
ctr->bltmp_pos += inlen;
|
2017-06-27 12:04:37 -04:00
|
|
|
}
|
2018-03-10 12:23:21 +01:00
|
|
|
return 1;
|
2017-06-27 12:04:37 -04:00
|
|
|
}
|
|
|
|
|
2018-03-10 12:23:21 +01:00
|
|
|
__owur static int ctr_BCC_final(RAND_DRBG_CTR *ctr)
|
2017-06-27 12:04:37 -04:00
|
|
|
{
|
2017-08-03 09:23:28 -04:00
|
|
|
if (ctr->bltmp_pos) {
|
|
|
|
memset(ctr->bltmp + ctr->bltmp_pos, 0, 16 - ctr->bltmp_pos);
|
2018-03-10 12:23:21 +01:00
|
|
|
if (!ctr_BCC_blocks(ctr, ctr->bltmp))
|
|
|
|
return 0;
|
2017-06-27 12:04:37 -04:00
|
|
|
}
|
2018-03-10 12:23:21 +01:00
|
|
|
return 1;
|
2017-06-27 12:04:37 -04:00
|
|
|
}
|
|
|
|
|
2018-03-10 12:23:21 +01:00
|
|
|
__owur static int ctr_df(RAND_DRBG_CTR *ctr,
|
|
|
|
const unsigned char *in1, size_t in1len,
|
|
|
|
const unsigned char *in2, size_t in2len,
|
|
|
|
const unsigned char *in3, size_t in3len)
|
2017-06-27 12:04:37 -04:00
|
|
|
{
|
|
|
|
static unsigned char c80 = 0x80;
|
|
|
|
size_t inlen;
|
2017-08-03 09:23:28 -04:00
|
|
|
unsigned char *p = ctr->bltmp;
|
2018-03-10 12:23:21 +01:00
|
|
|
int outlen = AES_BLOCK_SIZE;
|
2017-06-27 12:04:37 -04:00
|
|
|
|
2018-03-10 12:23:21 +01:00
|
|
|
if (!ctr_BCC_init(ctr))
|
|
|
|
return 0;
|
2017-06-27 12:04:37 -04: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 09:23:28 -04:00
|
|
|
*p = (unsigned char)((ctr->keylen + 16) & 0xff);
|
|
|
|
ctr->bltmp_pos = 8;
|
2018-03-10 12:23:21 +01: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-27 12:04:37 -04: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-15 23:27:09 +01:00
|
|
|
if (!EVP_CipherInit_ex(ctr->ctx_ecb, NULL, NULL, ctr->KX, NULL, -1))
|
2018-03-10 12:23:21 +01:00
|
|
|
return 0;
|
2017-06-27 12:04:37 -04: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-15 23:27:09 +01:00
|
|
|
if (!EVP_CipherUpdate(ctr->ctx_ecb, ctr->KX, &outlen, ctr->KX + ctr->keylen,
|
2018-03-10 12:23:21 +01: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-15 23:27:09 +01:00
|
|
|
if (!EVP_CipherUpdate(ctr->ctx_ecb, ctr->KX + 16, &outlen, ctr->KX,
|
2018-03-10 12:23:21 +01:00
|
|
|
AES_BLOCK_SIZE)
|
|
|
|
|| outlen != AES_BLOCK_SIZE)
|
|
|
|
return 0;
|
2017-08-03 09:23:28 -04: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-15 23:27:09 +01:00
|
|
|
if (!EVP_CipherUpdate(ctr->ctx_ecb, ctr->KX + 32, &outlen,
|
|
|
|
ctr->KX + 16, AES_BLOCK_SIZE)
|
2018-03-10 12:23:21 +01:00
|
|
|
|| outlen != AES_BLOCK_SIZE)
|
|
|
|
return 0;
|
|
|
|
return 1;
|
2017-06-27 12:04:37 -04: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 09:23:28 -04:00
|
|
|
* so we handle both cases in this function instead.
|
2017-06-27 12:04:37 -04:00
|
|
|
*/
|
2018-03-10 12:23:21 +01:00
|
|
|
__owur static int ctr_update(RAND_DRBG *drbg,
|
|
|
|
const unsigned char *in1, size_t in1len,
|
|
|
|
const unsigned char *in2, size_t in2len,
|
|
|
|
const unsigned char *nonce, size_t noncelen)
|
2017-06-27 12:04:37 -04:00
|
|
|
{
|
2017-12-28 21:42:14 +01:00
|
|
|
RAND_DRBG_CTR *ctr = &drbg->data.ctr;
|
2018-03-10 12:23:21 +01: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-15 23:27:09 +01:00
|
|
|
unsigned char V_tmp[48], out[48];
|
|
|
|
unsigned char len;
|
2017-06-27 12:04:37 -04:00
|
|
|
|
2018-03-10 12:23:21 +01: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-15 23:27:09 +01:00
|
|
|
memcpy(V_tmp, ctr->V, 16);
|
2017-08-03 09:23:28 -04: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-15 23:27:09 +01:00
|
|
|
memcpy(V_tmp + 16, ctr->V, 16);
|
|
|
|
if (ctr->keylen == 16) {
|
|
|
|
len = 32;
|
|
|
|
} else {
|
2017-08-03 09:23:28 -04: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-15 23:27:09 +01:00
|
|
|
memcpy(V_tmp + 32, ctr->V, 16);
|
|
|
|
len = 48;
|
2017-06-27 12:04:37 -04: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-15 23:27:09 +01:00
|
|
|
if (!EVP_CipherUpdate(ctr->ctx_ecb, out, &outlen, V_tmp, len)
|
|
|
|
|| outlen != len)
|
2018-03-10 12:23:21 +01: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-15 23:27:09 +01:00
|
|
|
memcpy(ctr->K, out, ctr->keylen);
|
|
|
|
memcpy(ctr->V, out + ctr->keylen, 16);
|
2017-06-27 12:04:37 -04:00
|
|
|
|
2018-02-08 23:04:16 +01:00
|
|
|
if ((drbg->flags & RAND_DRBG_FLAG_CTR_NO_DF) == 0) {
|
2017-06-27 12:04:37 -04:00
|
|
|
/* If no input reuse existing derived value */
|
|
|
|
if (in1 != NULL || nonce != NULL || in2 != NULL)
|
2018-03-10 12:23:21 +01:00
|
|
|
if (!ctr_df(ctr, in1, in1len, nonce, noncelen, in2, in2len))
|
|
|
|
return 0;
|
2017-06-27 12:04:37 -04:00
|
|
|
/* If this a reuse input in1len != 0 */
|
|
|
|
if (in1len)
|
2017-08-03 09:23:28 -04:00
|
|
|
ctr_XOR(ctr, ctr->KX, drbg->seedlen);
|
2017-06-27 12:04:37 -04:00
|
|
|
} else {
|
2017-08-03 09:23:28 -04:00
|
|
|
ctr_XOR(ctr, in1, in1len);
|
|
|
|
ctr_XOR(ctr, in2, in2len);
|
2017-06-27 12:04:37 -04: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-15 23:27:09 +01: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 12:23:21 +01:00
|
|
|
return 0;
|
|
|
|
return 1;
|
2017-06-27 12:04:37 -04:00
|
|
|
}
|
|
|
|
|
2018-03-10 12:23:21 +01:00
|
|
|
__owur static int drbg_ctr_instantiate(RAND_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-27 12:04:37 -04:00
|
|
|
{
|
2017-12-28 21:42:14 +01:00
|
|
|
RAND_DRBG_CTR *ctr = &drbg->data.ctr;
|
2017-06-27 12:04:37 -04: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-20 23:02:46 +02:00
|
|
|
if (entropy == NULL)
|
2017-08-05 12:04:10 +01:00
|
|
|
return 0;
|
|
|
|
|
2017-08-03 09:23:28 -04: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-15 23:27:09 +01:00
|
|
|
if (!EVP_CipherInit_ex(ctr->ctx_ecb, NULL, NULL, ctr->K, NULL, -1))
|
2018-03-10 12:23:21 +01: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-15 23:27:09 +01:00
|
|
|
|
|
|
|
inc_128(ctr);
|
2018-03-10 12:23:21 +01:00
|
|
|
if (!ctr_update(drbg, entropy, entropylen, pers, perslen, nonce, noncelen))
|
|
|
|
return 0;
|
2017-06-27 12:04:37 -04:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2018-03-10 12:23:21 +01:00
|
|
|
__owur static int drbg_ctr_reseed(RAND_DRBG *drbg,
|
|
|
|
const unsigned char *entropy, size_t entropylen,
|
|
|
|
const unsigned char *adin, size_t adinlen)
|
2017-06-27 12:04:37 -04: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-15 23:27:09 +01:00
|
|
|
RAND_DRBG_CTR *ctr = &drbg->data.ctr;
|
|
|
|
|
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-20 23:02:46 +02:00
|
|
|
if (entropy == NULL)
|
2017-08-05 12:04:10 +01: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-15 23:27:09 +01:00
|
|
|
|
|
|
|
inc_128(ctr);
|
2018-03-10 12:23:21 +01:00
|
|
|
if (!ctr_update(drbg, entropy, entropylen, adin, adinlen, NULL, 0))
|
|
|
|
return 0;
|
2017-06-27 12:04:37 -04:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
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-15 23:27:09 +01: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);
|
|
|
|
}
|
|
|
|
|
2018-03-10 12:23:21 +01:00
|
|
|
__owur static int drbg_ctr_generate(RAND_DRBG *drbg,
|
|
|
|
unsigned char *out, size_t outlen,
|
|
|
|
const unsigned char *adin, size_t adinlen)
|
2017-06-27 12:04:37 -04:00
|
|
|
{
|
2017-12-28 21:42:14 +01:00
|
|
|
RAND_DRBG_CTR *ctr = &drbg->data.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-15 23:27:09 +01:00
|
|
|
unsigned int ctr32, blocks;
|
|
|
|
int outl, buflen;
|
2017-06-27 12:04:37 -04: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-15 23:27:09 +01:00
|
|
|
inc_128(ctr);
|
|
|
|
|
2018-03-10 12:23:21 +01:00
|
|
|
if (!ctr_update(drbg, adin, adinlen, NULL, 0, NULL, 0))
|
|
|
|
return 0;
|
2017-06-27 12:04:37 -04:00
|
|
|
/* This means we reuse derived value */
|
2018-02-08 23:04:16 +01:00
|
|
|
if ((drbg->flags & RAND_DRBG_FLAG_CTR_NO_DF) == 0) {
|
2017-06-27 12:04:37 -04: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-15 23:27:09 +01:00
|
|
|
inc_128(ctr);
|
2018-03-10 12:23:21 +01: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-15 23:27:09 +01:00
|
|
|
if (outlen == 0) {
|
2017-08-03 09:23:28 -04: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-15 23:27:09 +01:00
|
|
|
|
|
|
|
if (!ctr_update(drbg, adin, adinlen, NULL, 0, NULL, 0))
|
2018-03-10 12:23:21 +01: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-15 23:27:09 +01:00
|
|
|
return 1;
|
2017-06-27 12:04:37 -04: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-15 23:27:09 +01: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. */
|
|
|
|
blocks -= ctr32;
|
|
|
|
buflen = blocks * 16;
|
|
|
|
ctr32 = 0;
|
|
|
|
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 12:23:21 +01:00
|
|
|
if (!ctr_update(drbg, adin, adinlen, NULL, 0, NULL, 0))
|
|
|
|
return 0;
|
2017-06-27 12:04:37 -04:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2017-12-28 21:42:14 +01:00
|
|
|
static int drbg_ctr_uninstantiate(RAND_DRBG *drbg)
|
2017-06-27 12:04:37 -04: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-15 23:27:09 +01:00
|
|
|
EVP_CIPHER_CTX_free(drbg->data.ctr.ctx_ecb);
|
|
|
|
EVP_CIPHER_CTX_free(drbg->data.ctr.ctx_ctr);
|
2018-03-10 12:23:21 +01:00
|
|
|
EVP_CIPHER_CTX_free(drbg->data.ctr.ctx_df);
|
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-15 23:27:09 +01:00
|
|
|
EVP_CIPHER_free(drbg->data.ctr.cipher_ecb);
|
|
|
|
EVP_CIPHER_free(drbg->data.ctr.cipher_ctr);
|
2017-12-28 21:42:14 +01:00
|
|
|
OPENSSL_cleanse(&drbg->data.ctr, sizeof(drbg->data.ctr));
|
2017-06-27 12:04:37 -04:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2017-12-28 21:42:14 +01:00
|
|
|
static RAND_DRBG_METHOD drbg_ctr_meth = {
|
|
|
|
drbg_ctr_instantiate,
|
|
|
|
drbg_ctr_reseed,
|
|
|
|
drbg_ctr_generate,
|
|
|
|
drbg_ctr_uninstantiate
|
|
|
|
};
|
|
|
|
|
|
|
|
int drbg_ctr_init(RAND_DRBG *drbg)
|
2017-06-27 12:04:37 -04:00
|
|
|
{
|
2017-12-28 21:42:14 +01:00
|
|
|
RAND_DRBG_CTR *ctr = &drbg->data.ctr;
|
2017-06-27 12:04:37 -04:00
|
|
|
size_t 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-15 23:27:09 +01:00
|
|
|
EVP_CIPHER *cipher_ecb = NULL;
|
|
|
|
EVP_CIPHER *cipher_ctr = NULL;
|
2017-06-27 12:04:37 -04:00
|
|
|
|
2018-03-15 19:48:43 +01:00
|
|
|
switch (drbg->type) {
|
2017-06-27 12:04:37 -04:00
|
|
|
default:
|
|
|
|
/* This can't happen, but silence the compiler warning. */
|
2017-11-20 23:27:23 +01:00
|
|
|
return 0;
|
2017-06-27 12:04:37 -04:00
|
|
|
case NID_aes_128_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-15 23:27:09 +01:00
|
|
|
cipher_ecb = EVP_CIPHER_fetch(drbg->libctx, "AES-128-ECB", "");
|
|
|
|
cipher_ctr = EVP_CIPHER_fetch(drbg->libctx, "AES-128-CTR", "");
|
2017-06-27 12:04:37 -04:00
|
|
|
break;
|
|
|
|
case NID_aes_192_ctr:
|
|
|
|
keylen = 24;
|
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-15 23:27:09 +01:00
|
|
|
cipher_ecb = EVP_CIPHER_fetch(drbg->libctx, "AES-192-ECB", "");
|
|
|
|
cipher_ctr = EVP_CIPHER_fetch(drbg->libctx, "AES-192-CTR", "");
|
2017-06-27 12:04:37 -04:00
|
|
|
break;
|
|
|
|
case NID_aes_256_ctr:
|
|
|
|
keylen = 32;
|
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-15 23:27:09 +01:00
|
|
|
cipher_ecb = EVP_CIPHER_fetch(drbg->libctx, "AES-256-ECB", "");
|
|
|
|
cipher_ctr = EVP_CIPHER_fetch(drbg->libctx, "AES-256-CTR", "");
|
2017-06-27 12:04:37 -04:00
|
|
|
break;
|
|
|
|
}
|
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-15 23:27:09 +01:00
|
|
|
if (cipher_ecb == NULL || cipher_ctr == NULL)
|
2019-05-23 14:35:42 +01: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-15 23:27:09 +01:00
|
|
|
EVP_CIPHER_free(ctr->cipher_ecb);
|
|
|
|
ctr->cipher_ecb = cipher_ecb;
|
|
|
|
EVP_CIPHER_free(ctr->cipher_ctr);
|
|
|
|
ctr->cipher_ctr = cipher_ctr;
|
2017-12-28 21:42:14 +01:00
|
|
|
|
2017-08-03 09:23:28 -04: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-15 23:27:09 +01: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();
|
|
|
|
if (ctr->ctx_ecb == NULL || ctr->ctx_ctr == NULL
|
|
|
|
|| !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))
|
2018-03-10 12:23:21 +01: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-15 23:27:09 +01:00
|
|
|
|
|
|
|
drbg->meth = &drbg_ctr_meth;
|
2017-08-03 09:23:28 -04:00
|
|
|
drbg->strength = keylen * 8;
|
|
|
|
drbg->seedlen = keylen + 16;
|
2017-06-27 12:04:37 -04:00
|
|
|
|
2018-02-08 23:04:16 +01:00
|
|
|
if ((drbg->flags & RAND_DRBG_FLAG_CTR_NO_DF) == 0) {
|
2017-06-27 12:04:37 -04:00
|
|
|
/* df initialisation */
|
2018-03-10 12:23:21 +01:00
|
|
|
static const unsigned char df_key[32] = {
|
2017-09-15 21:14:34 +02:00
|
|
|
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
|
2017-06-27 12:04:37 -04:00
|
|
|
};
|
2018-03-10 12:23:21 +01:00
|
|
|
|
|
|
|
if (ctr->ctx_df == NULL)
|
|
|
|
ctr->ctx_df = EVP_CIPHER_CTX_new();
|
|
|
|
if (ctr->ctx_df == NULL)
|
|
|
|
return 0;
|
2017-06-27 12:04:37 -04:00
|
|
|
/* Set key schedule for df_key */
|
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-15 23:27:09 +01:00
|
|
|
if (!EVP_CipherInit_ex(ctr->ctx_df,
|
|
|
|
ctr->cipher_ecb, NULL, df_key, NULL, 1))
|
2018-03-10 12:23:21 +01:00
|
|
|
return 0;
|
2017-08-03 09:23:28 -04: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-20 23:02:46 +02:00
|
|
|
drbg->min_entropylen = ctr->keylen;
|
2018-10-10 01:53:29 +02:00
|
|
|
drbg->max_entropylen = DRBG_MAX_LENGTH;
|
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-20 23:02:46 +02:00
|
|
|
drbg->min_noncelen = drbg->min_entropylen / 2;
|
2018-10-10 01:53:29 +02:00
|
|
|
drbg->max_noncelen = DRBG_MAX_LENGTH;
|
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-20 23:02:46 +02:00
|
|
|
drbg->max_perslen = DRBG_MAX_LENGTH;
|
|
|
|
drbg->max_adinlen = DRBG_MAX_LENGTH;
|
2017-06-27 12:04:37 -04:00
|
|
|
} else {
|
2019-04-11 08:52:22 +10:00
|
|
|
#ifdef FIPS_MODE
|
|
|
|
RANDerr(RAND_F_DRBG_CTR_INIT,
|
|
|
|
RAND_R_DERIVATION_FUNCTION_MANDATORY_FOR_FIPS);
|
|
|
|
return 0;
|
|
|
|
#else
|
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-20 23:02:46 +02:00
|
|
|
drbg->min_entropylen = drbg->seedlen;
|
|
|
|
drbg->max_entropylen = drbg->seedlen;
|
2017-06-27 12:04:37 -04:00
|
|
|
/* Nonce not used */
|
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-20 23:02:46 +02:00
|
|
|
drbg->min_noncelen = 0;
|
|
|
|
drbg->max_noncelen = 0;
|
|
|
|
drbg->max_perslen = drbg->seedlen;
|
|
|
|
drbg->max_adinlen = drbg->seedlen;
|
2019-04-11 08:52:22 +10:00
|
|
|
#endif
|
2017-06-27 12:04:37 -04:00
|
|
|
}
|
|
|
|
|
2017-08-03 09:23:28 -04:00
|
|
|
drbg->max_request = 1 << 16;
|
2018-03-09 18:24:23 +01:00
|
|
|
|
2017-06-27 12:04:37 -04:00
|
|
|
return 1;
|
|
|
|
}
|