Make the RAND code available from within the FIPS module by mattcaswell · Pull Request #9035 · openssl/openssl

mattcaswell · 2019-05-28T16:25:35Z

This enables calls to RAND_*() functions from within the FIPS module. This is required in order to bring in support for BIGNUM, and the various asymmetric algorithms.

I've added a dummy call into the FIPS module just to demonstrate that it works. This will be removed in due course when we no longer need it.

crypto/async/async.c

crypto/context.c

crypto/err/err.c

slontis · 2019-05-28T22:34:41Z

crypto/include/internal/cryptlib_int.h

These start/stop names look different

Not sure I understand your point. There isn't a "start" equivalent of ossl_ctx_thread_stop

What about ossl_init_thread_start?

The stop equivalent of ossl_init_thread_start is ossl_init_thread_stop. There is no "start" equivalent of ossl_ctx_thread_stop.

crypto/initthread.c

slontis · 2019-05-28T22:45:36Z

crypto/initthread.c

Should *hands be NULL here?

slontis · 2019-05-28T22:46:05Z

crypto/initthread.c

Doesnt this *hands get returned?

I refactored this to make things a bit clearer.

crypto/initthread.c

slontis · 2019-05-28T22:47:31Z

crypto/initthread.c

NIT: unique

slontis · 2019-05-28T22:56:19Z

crypto/rand/drbg_lib.c

I assume all these goto's mean that CRYPTO_THREAD_cleanup_local() doesnt handle passing NULLS - looks messy

Well, dgbl->private_drbg is not NULL if there's an error, just uninitialised - so we shouldn't attempt to use it in anyway.

Since dgbl is allocated via zalloc, and since NULL is all-bits-zero (via the sanity test), it is initialized.

It's the private_drbg field we are specifically concerned with there. And yes it will get set to 0 on create. However, when I said it was unitialised, I meant it has not been initialised via a call to CRYPTO_THREAD_init_local. We should not be calling CRYPTO_THREAD_cleanup_local on keys that have not been initialised in that way. We cannot know how CRYPTO_THREAD_cleanup_local would treat a key that is set to 0. It most likely would be fine but we cannot say for sure. For example in a pthreads implementation CRYPTO_THREAD_cleanup_local calls pthread_key_delete which has this description: "The pthread_key_delete() function shall delete a thread-specific data key previously returned by pthread_key_create()". It says nothing about what happens if you pass it zero data that was not created by pthread_key_create - so at best this behaviour is undefined.

slontis · 2019-05-28T23:00:43Z

I havent gone through the whole thing yet - but it seems that a large percentage of this PR is related to threads. Maybe the rand changes should be in a seperate PR?

slontis · 2019-05-28T23:02:12Z

travis errors are valid (except for the timeout ones)

mattcaswell · 2019-05-29T14:19:24Z

I've attempt to respond to the comments so far and have also tried to fix the various travis issues. I've also rebased and force pushed.

I'm going to take a look to see if I can easily split this up into smaller PRs to make it easier to review.

mattcaswell · 2019-05-29T15:29:29Z

I've split out various bits of this PR into other PRs. See #9038, #9039, and #9040. Once all of those are merged this PR will need to be rebased to pick up the last few commits to complete the move of the RAND code into the FIPS module. In the meantime I've set this PR to be WIP.

mattcaswell · 2019-06-04T16:36:52Z

I rebased this now that #9038 has gone in, and to include the latest changes from #9039.

mattcaswell · 2019-06-18T18:35:21Z

Needs #9186 before this can progress.

doc/man3/OPENSSL_CTX.pod

doc/man3/RAND_DRBG_get0_master.pod

levitte · 2019-06-19T08:32:47Z

Please rebase then ping, I'll try to review quickly.

mattcaswell · 2019-06-19T09:57:45Z

I've rebased this PR. Note the feedback comments above were for commits no longer in this PR. Note this PR now also includes the commits from #9186, so that needs to go in first before I can take this out of WIP.

In some circumstances the global data held in the "global" variable can be NULL, so we should error out in the circumstance instead of crashing.

Insert a dummy call to RAND_DRBG_bytes from inside the FIPS provider to demonstrate that it is possible to use the RAND code from inside the module. This is temporary and will be removed once real uses of the RAND code are available inside the module.

mattcaswell · 2019-06-19T11:08:57Z

Finally all the dependent PRs are in and I am able to take this out of WIP!

I've rebased on the latest master. Please review!

crypto/hmac/build.info

crypto/rand/build.info

mattcaswell · 2019-06-19T12:11:28Z

Fixup commit pushed addressing the feedback, and also fixing a windows linking issue. I've not addressed the doc-nits issue because that is (presumably) also a problem on master so probably is better done in a different PR.

mattcaswell · 2019-06-19T12:15:16Z

doc-nits issue fixed in #9192

levitte · 2019-06-19T16:06:37Z

Looks good to me. I would like to know what @mspncp has to say, though.

mspncp · 2019-06-19T17:19:45Z

Looks good to me. I would like to know what @mspncp has to say, though.

I started taking a look, but it might take a while to complete it, since I'm currently on vacation.

levitte · 2019-06-19T18:09:53Z

Oh, sorry, forgot about that...

mspncp

To be continued...

mspncp · 2019-06-19T16:59:39Z

crypto/hmac/hm_meth.c

    if (!value)
        return 0;
+#ifndef FIPS_MODE
+    /* Not supported in FIPS mode due to the implict fetch of the md */


I'm not sure I understand the explanation "...due to the implict fetch of the md" means. Actually, I believe this comment is incomprehensible for anybody who is not already deeply familiar with all the current replumbing and FIPS refactoring. Could this comment be a little bit more elaborated to make it more comprehensible?

Also, it contains a typo: 'implict' -> 'implicit'

"Explicit" fetch occurs when we look up an algorithm using one of the "fetch" functions such as EVP_MD_fetch(). This finds the algorithm and associates it with an implementation from a provider. Conversely "Implicit" fetch is when we don't do that, and use a function such as "EVP_sha256()" which has no provider implementation associated with it. With an algorithm obtained in that way the "fetch" happens automatically when you try to use it - hence "implicit fetch". An important difference between these two types of EVP_MD objects is that explicitly fetched versions are dynamically allocated and must be "freed", whereas implicitly fetched ones do not. That fact makes this code more complicated if we want to convert it to use explicit fetch. Since we are unlikely to need this ctrl in FIPS_MODE I didn't bother.

I replaced this comment with a longer one to try and explain this better.

mspncp · 2019-06-19T17:17:55Z

crypto/rand/drbg_hash.c

+#ifndef FIPS_MODE
    /* Any approved digest is allowed */
-    md = EVP_get_digestbynid(drbg->type);
+    md = EVP_MD_meth_dup(EVP_get_digestbynid(drbg->type));


I don't think the digest algorithm of the HASH-DRBG should be selectable via generic EVP lookup accross multiple providers. It is an integral part of the HASH-DRBG algorithm and not a replaceable part. If you take a look at the CTR-DRBG implementation, there is no such distinction between fips and generic provider: The aes-ctr algorithm is always fetched unconditionally from the provider context.

openssl/crypto/rand/drbg_ctr.c

Lines 375 to 391 in 56ce84b

switch (drbg->type) {

default:

/* This can't happen, but silence the compiler warning. */

return 0;

case NID_aes_128_ctr:

keylen = 16;

cipher = EVP_CIPHER_fetch(drbg->libctx, "AES-128-ECB", "");

break;

case NID_aes_192_ctr:

keylen = 24;

cipher = EVP_CIPHER_fetch(drbg->libctx, "AES-192-ECB", "");

break;

case NID_aes_256_ctr:

keylen = 32;

cipher = EVP_CIPHER_fetch(drbg->libctx, "AES-256-ECB", "");

break;

}

The application can only choose from a fixed number of builtin implementations. The digest selection for the HASH-DRBG should work exactly the same way. In other words, drop the #if part and keep only the #else part.

openssl/crypto/rand/drbg_hash.c

Lines 315 to 321 in 56ce84b

switch (drbg->type) {

default:

return 0;

case NID_sha256:

md = EVP_MD_fetch(drbg->libctx, "SHA256", "");

break;

}

The only difference between fips and non-fips might be that for the former the switch contains less cases.

I don't think the digest algorithm of the HASH-DRBG should be selectable via generic EVP lookup accross multiple providers
...
The aes-ctr algorithm is always fetched unconditionally from the provider context.

I think there is some confusion here. Ignoring the FIPS provider for a moment (which is a special case), the DRBG code exists in libcrypto and is not associated with a particular provider (yet). We probably will want to make it possible to "fetch" a DRBG implementation from a provider and use that...but we're not there yet. For now its just in libcrypto. The look up across "multiple providers" will happen anyway when used, even with aes-ctr. It just looks for an implementation of (for example) "AES-128-ECB" and uses it. The default provider (which might not even be available for all we know) may or may not be used.

Now, as I said, the FIPS provider is a special case. It does not link against libcrypto and so can't use the built-in DRBG implementation. Therefore, for that provider only, we are additionally making the DRBG code available inside the FIPS provider. For that provider only, when we do a "fetch" it will only ever find algorithms provided by itself.

Anyway, aside from that confusion, your suggestion is fine and I have refactored things accordingly.

I'd lean towards making the digest selection completely open. It provides a degree of flexibility in case something untoward happens to one of the digests. However, I'm happy enough with the current switch statement to not be too bothered (there are plenty of choices available and it avoids an explicit XOF check).

One could argue that the CTR-DRBG should have this flexibility too (ARIA and Camellia should both drop in instead of AES). Still, for some point in the future rather than now.

I don't mind, as long as the implementation is consistent for the three DRBG implementations. Anyway, if this change is desired it would be a matter for a separate pull request.

crypto/rand/drbg_hash.c

crypto/rand/drbg_hmac.c

Providers that link against libcrypto can just use OBJ_nid2sn() to look up the name of an algorithm given a NID. However that doesn't work for the FIPS provider because OBJ_nid2sn() is not available there (due to the reliance of the code on ASN.1 types). Therefore we provider a new function to do this mapping. For providers linking against libcrypto the new function just wraps OBJ_nid2sn(). For the FIPS provider it has a look up for all the NIDs known there.

…ames We use the new function ossl_prov_util_nid_to_name() to look up the algorithm and unify the FIPS_MODE and non-FIPS_MODE handling.

As per the previous commit we make the same change for DRBG HMAC and more closely align the FIPS_MODE and non FIPS_MODE implementations.

mattcaswell · 2019-06-20T13:06:44Z

New commits addressing the feedback pushed.

mspncp

Looks good, but some questions remain. (You can ignore the ones for @paulidale and @slontis).

BTW: Is it actually possible by now to run and check the DRBG code of the FIPS provider in the debugger (on linux)? If yes, what do I need to set it up?

mspncp · 2019-06-20T22:27:44Z

crypto/hmac/hm_meth.c

+    /*
+     * We don't have EVP_get_digestbyname() in FIPS_MODE. That function returns
+     * an EVP_MD without an associated provider implementation (i.e. it is
+     * using "implict fetch"). We could replace it with an "explicit" fetch


typo: 'implict' -> 'implicit'

mspncp · 2019-06-20T22:46:16Z

doc/internal/man3/ossl_prov_util_nid_to_name.pod

+
+ #include "internal/providercommon.h"
+
+ const char *ossl_prov_util_nid_to_name(int nid);


I'm surprised that an internal function gets documented in the manual pages (which doesn't mean I'm against documenting it). Is it intended to be used by third party providers, too?

@levitte has been championing the documentation of the "internal" API, i.e. stuff that ends up in our internal header files. There's quite a few man pages there already. This particular function is purely internal. There is no intention for it to be used by third party providers.

mspncp · 2019-06-22T17:44:58Z

crypto/rand/drbg_hash.c

+#ifndef FIPS_MODE
+    case NID_blake2b512:
+    case NID_blake2s256:
+    case NID_sm3:


This is more a question to @paulidale and @slontis than a review comment: NIST SP 800-90Ar1 does not mention SHA3, BLAKE and SM3. Is it 'legal' nevertheless to use them?

Section 10.1 opens by saying that the hash DRBG mechanisms have been designed to use any approved hash function. Based on this SHA3 would be legal.

BLAKE and SM3 cannot be FIPS validated.

mspncp · 2019-06-22T17:45:19Z

crypto/rand/drbg_hmac.c

+#ifndef FIPS_MODE
+    case NID_blake2b512:
+    case NID_blake2s256:
+    case NID_sm3:


Same question to @paulidale and @slontis.

I think it has the same answer. 10.1.2 again mentions an approved hash function.

mspncp · 2019-06-22T17:50:05Z

crypto/rand/rand_crng_test.c

 };

 int rand_crngt_get_entropy_cb(OPENSSL_CTX *ctx,
+                              RAND_POOL *pool,


What is the rationale behind the changes in rand_crng_test.c?

Is it a fixup for 4e297b7 which you made along the way?

Effectively yes. I encountered a crash related to this code. The change is related to the crngt_get_entropy callback. That callback gets called from rand_crng_ossl_ctx_new. That function is called when we are initialising an OPENSSL_CTX with CRNG data for the first time. Unfortunately, in the original implementation, the default callback was itself trying to get CRNG data from the OPENSSL_CTX. But since we're still initialising it it went round in an an infinite recursive loop trying to initialise the OPENSSL_CTX until eventually it blew the stack. The solution to the problem was to change the callback to take the RAND_POOL to be used as a parameter instead of getting it from the OPENSSL_CTX.

mspncp · 2019-06-22T17:54:28Z

crypto/rand/rand_win.c

 }

-# if !OPENSSL_API_1_1_0
+# if !OPENSSL_API_1_1_0 || defined(FIPS_MODE)


Are you sure to enable it in FIPS mode? Or did you mean

# if !OPENSSL_API_1_1_0 && !defined(FIPS_MODE)

Yes, I did mean that!

Hmmm... but why? The code is marked deprecated-in-1.1.0 and not called anywhere.

msp@msppc:~/src/openssl$ git grep -E -nH 'RAND_(event|screen)' pr-9035 pr-9035:crypto/rand/rand_win.c:166:int RAND_event(UINT iMsg, WPARAM wParam, LPARAM lParam) pr-9035:crypto/rand/rand_win.c:172:void RAND_screen(void) pr-9035:doc/man3/RAND_add.pod:5:RAND_add, RAND_poll, RAND_seed, RAND_status, RAND_event, RAND_screen, pr-9035:doc/man3/RAND_add.pod:25: int RAND_event(UINT iMsg, WPARAM wParam, LPARAM lParam); pr-9035:doc/man3/RAND_add.pod:26: void RAND_screen(void); pr-9035:doc/man3/RAND_add.pod:74:RAND_event() and RAND_screen() are equivalent to RAND_poll() and exist pr-9035:doc/man3/RAND_add.pod:84:RAND_event() returns RAND_status(). pr-9035:doc/man3/RAND_add.pod:98:RAND_event() and RAND_screen() were deprecated in OpenSSL 1.1.0 and should pr-9035:include/openssl/rand.h:68:DEPRECATEDIN_1_1_0(void RAND_screen(void)) pr-9035:include/openssl/rand.h:69:DEPRECATEDIN_1_1_0(int RAND_event(UINT, WPARAM, LPARAM)) pr-9035:util/libcrypto.num:1331:RAND_event 1318 3_0_0 EXIST:_WIN32:FUNCTION:DEPRECATEDIN_1_1_0 pr-9035:util/libcrypto.num:1816:RAND_screen 1804 3_0_0 EXIST:_WIN32:FUNCTION:DEPRECATEDIN_1_1_0

Is it because it is still referenced in libcrypto.num?

pr-9035:util/libcrypto.num:1331:RAND_event 1318 3_0_0 EXIST:_WIN32:FUNCTION:DEPRECATEDIN_1_1_0 pr-9035:util/libcrypto.num:1816:RAND_screen 1804 3_0_0 EXIST:_WIN32:FUNCTION:DEPRECATEDIN_1_1_0

Sorry, I wasn't clear. What you wrote is what I meant! I've fixed it now.

But the FIPS provider does not reuse libcrypto.num, right?

Sorry, I wasn't clear. What you wrote is what I meant! I've fixed it now.

Ok, now the world is in order again :-)

But the FIPS provider does not reuse libcrypto.num, right?

Right. It has its own num file which exports exactly one function:

https://github.com/openssl/openssl/blob/master/util/providers.num

mattcaswell · 2019-06-24T10:35:51Z

BTW: Is it actually possible by now to run and check the DRBG code of the FIPS provider in the debugger (on linux)? If yes, what do I need to set it up?

With this PR, yes. Set a breakpoint on line 120 of providers/fips/fipsprov.c and then run evp_extra_test:

$ OPENSSL_MODULES=providers util/shlib_wrap.sh gdb --args test/evp_extra_test -test 13
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from test/evp_extra_test...done.
(gdb) break fipsprov.c:120
No source file named fipsprov.c.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (fipsprov.c:120) pending.
(gdb) run
Starting program: /home/matt/dev/openssl-write/test/evp_extra_test -test 13
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
    # Subtest: test_EVP_MD_fetch
    1..5
    ok 1 - iteration 1
    ok 2 - iteration 2
    ok 3 - iteration 3

Breakpoint 1, dummy_evp_call (provctx=0x5555557c0530)
    at providers/fips/fipsprov.c:120
120	    if (RAND_DRBG_bytes(drbg, randbuf, sizeof(randbuf)) <= 0)

mspncp · 2019-06-24T10:41:07Z

Thanks for the instructions. I'll give it a try this evening...

mattcaswell · 2019-06-24T14:17:43Z

Fix up commit pushed addressing the feedback.

mspncp

Looks good to me. I would like to know what @mspncp has to say, though.

I think the 'DRBG part' is fine now. But I'd prefer if @levitte could also give his approval for the 'provider part'. Also, if you have time to wait until tomorrow, I'll do a live examination in the debugger this evening.

mattcaswell · 2019-06-26T16:10:30Z

I'll do a live examination in the debugger this evening.

Did you manage to do that?

mspncp · 2019-06-26T16:32:28Z

Yes I did, and I have some thoughts to share, which I did not find the time to write down yet. Also, I might have some questions for you. But it's nothing that would prevent this pull request from being merged, I haven't found any issues (yet). I'd still be more comfortable if @levitte would approve the provider related (non-drbg) parts of this pull request, but if you think my approval is sufficient, feel free to go ahead and merge it.

mattcaswell · 2019-06-27T08:27:36Z

I'd still be more comfortable if @levitte would approve the provider related (non-drbg) parts of this pull request, but if you think my approval is sufficient, feel free to go ahead and merge it.

I think @levitte is away at the moment with only occasional network access. I'll leave this open a little bit longer to see if he comments, but otherwise I will merge this later today.

mattcaswell · 2019-06-28T09:28:19Z

Pushed! Thanks!

Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from #9035)

In some circumstances the global data held in the "global" variable can be NULL, so we should error out in the circumstance instead of crashing. Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from #9035)

Insert a dummy call to RAND_DRBG_bytes from inside the FIPS provider to demonstrate that it is possible to use the RAND code from inside the module. This is temporary and will be removed once real uses of the RAND code are available inside the module. Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from #9035)

Providers that link against libcrypto can just use OBJ_nid2sn() to look up the name of an algorithm given a NID. However that doesn't work for the FIPS provider because OBJ_nid2sn() is not available there (due to the reliance of the code on ASN.1 types). Therefore we provider a new function to do this mapping. For providers linking against libcrypto the new function just wraps OBJ_nid2sn(). For the FIPS provider it has a look up for all the NIDs known there. Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from #9035)

…ames We use the new function ossl_prov_util_nid_to_name() to look up the algorithm and unify the FIPS_MODE and non-FIPS_MODE handling. Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from #9035)

As per the previous commit we make the same change for DRBG HMAC and more closely align the FIPS_MODE and non FIPS_MODE implementations. Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from #9035)

mattcaswell added the branch: master Applies to master branch label May 28, 2019

mattcaswell requested review from levitte and mspncp May 28, 2019 16:25

slontis reviewed May 28, 2019

View reviewed changes

mattcaswell force-pushed the fips-rand-v3 branch from 6db151f to ae6e55a Compare May 29, 2019 14:18

This was referenced May 29, 2019

Make basic AES ciphers available from within the FIPS providers #9038

Closed

Prepare the RAND code for moving into the FIPS module #9039

Closed

Make the threading code provider aware #9040

Closed

mattcaswell changed the title ~~Make the RAND code available from within the FIPS module~~ WIP: Make the RAND code available from within the FIPS module May 29, 2019

mattcaswell force-pushed the fips-rand-v3 branch from ae6e55a to 370df5a Compare June 4, 2019 16:32

mattcaswell mentioned this pull request Jun 11, 2019

Make BIGNUM code available in the FIPS provider #9130

Closed

mattcaswell mentioned this pull request Jun 18, 2019

Provide an ability to deregister thread stop handlers #9186

Closed

levitte reviewed Jun 19, 2019

View reviewed changes

doc/man3/OPENSSL_CTX.pod Outdated Show resolved Hide resolved

levitte reviewed Jun 19, 2019

View reviewed changes

doc/man3/RAND_DRBG_get0_master.pod Outdated Show resolved Hide resolved

mattcaswell force-pushed the fips-rand-v3 branch from 370df5a to 825514f Compare June 19, 2019 09:56

mattcaswell added 3 commits June 19, 2019 12:03

Make the RAND code available from inside the FIPS module

86fb39f

Fix NULL pointer dereference in the ex_data code

29dbcf8

In some circumstances the global data held in the "global" variable can be NULL, so we should error out in the circumstance instead of crashing.

mattcaswell changed the title ~~WIP: Make the RAND code available from within the FIPS module~~ Make the RAND code available from within the FIPS module Jun 19, 2019

mattcaswell force-pushed the fips-rand-v3 branch from 825514f to d4c81c6 Compare June 19, 2019 11:08

levitte requested changes Jun 19, 2019

View reviewed changes

crypto/hmac/build.info Outdated Show resolved Hide resolved

crypto/rand/build.info Show resolved Hide resolved

mattcaswell mentioned this pull request Jun 19, 2019

Make BIGNUM rand functions available within the FIPS module #9193

Closed

mspncp suggested changes Jun 19, 2019

View reviewed changes

mattcaswell added 4 commits June 20, 2019 12:46

Change the DRBG HASH implementation to lookup all allowed algorithm n…

2808612

…ames We use the new function ossl_prov_util_nid_to_name() to look up the algorithm and unify the FIPS_MODE and non-FIPS_MODE handling.

Change the DRBG HMAC implementation to lookup allowed digest names

9fd8f9d

As per the previous commit we make the same change for DRBG HMAC and more closely align the FIPS_MODE and non FIPS_MODE implementations.

fixup! Make the RAND code available from inside the FIPS module

e44a711

mspncp reviewed Jun 22, 2019

View reviewed changes

fixup! Make the RAND code available from inside the FIPS module

3a97ca4

fixup! Make the RAND code available from inside the FIPS module

3e332f9

mspncp approved these changes Jun 24, 2019

View reviewed changes

mattcaswell closed this Jun 28, 2019

levitte pushed a commit that referenced this pull request Jun 28, 2019

Make the RAND code available from inside the FIPS module

57ca171

Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from #9035)

	switch (drbg->type) {
	default:
	/* This can't happen, but silence the compiler warning. */
	return 0;
	case NID_aes_128_ctr:
	keylen = 16;
	cipher = EVP_CIPHER_fetch(drbg->libctx, "AES-128-ECB", "");
	break;
	case NID_aes_192_ctr:
	keylen = 24;
	cipher = EVP_CIPHER_fetch(drbg->libctx, "AES-192-ECB", "");
	break;
	case NID_aes_256_ctr:
	keylen = 32;
	cipher = EVP_CIPHER_fetch(drbg->libctx, "AES-256-ECB", "");
	break;
	}


		#include "internal/providercommon.h"

		const char *ossl_prov_util_nid_to_name(int nid);

Uh oh!

Conversation

mattcaswell commented May 28, 2019

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

slontis commented May 28, 2019

Uh oh!

slontis commented May 28, 2019

Uh oh!

mattcaswell commented May 29, 2019

Uh oh!

mattcaswell commented May 29, 2019

Uh oh!

mattcaswell commented Jun 4, 2019

Uh oh!

mattcaswell commented Jun 18, 2019

Uh oh!

Uh oh!

Uh oh!

levitte commented Jun 19, 2019

Uh oh!

mattcaswell commented Jun 19, 2019

Uh oh!

mattcaswell commented Jun 19, 2019

Uh oh!

Uh oh!

Uh oh!

mattcaswell commented Jun 19, 2019

Uh oh!

mattcaswell commented Jun 19, 2019

Uh oh!

levitte commented Jun 19, 2019

Uh oh!

mspncp commented Jun 19, 2019

Uh oh!

levitte commented Jun 19, 2019

Uh oh!

mspncp left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mspncp Jun 19, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mspncp Jun 19, 2019 •

edited

Loading