[openssl-users] Problems on authentication during TLS handshake

[Jin Xie]

Hello everyone,

I’m new at OpenSSL programming and encountered a problem while build TLS 
connection. I’m working on a crypto chip ATECC508A. So the client private key 
is stored in the chip and no way to get it out. However during standard TLS 
handshake, I need to provide client private key by “SSL_CTX_use_private_key()” 
if server needs to identify the client. Because the server will give a 
“challenge” to client and client needs to encrypt it by client private key. 
Then the server will decode it by client public key and check if they match. 
For your reference: 
https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake

I have written my sample client and server code. Everything works fine if I use 
my own test certificates: selft-signed CA and client cert signed by CA (this 
means I have the test client cert private key so that I could use 
SSL_CTX_use_private_key() to import it). 

The problem is here, in ATECC508A, I’m not able to provide private key directly 
but have API to sign any digests. So I wonder are there any ways to do some 
“modification” during handshake? I have tried following two ways:

1. Using OpenSSL Engine. I see that we could set our own algorithms inside 
engine to overwrite original methods. I think signing “challenge” is at 
EC_KEY_METHOD. So I write an EC_KEY_METHOD engine and load it successful. 
Besides I print “enter” and “leave” at the beginning and end of every function 
in EC_KEY_METHOD. When I do some tests using “ECDSA_sign”, I could see “enter” 
and “leave” printed from my sign_sig and sign function. However if I run TLS 
connection, nothing printed (except engine initialization log) and 
authentication failed (obviously). Those means my own sign and verify functions 
hasn’t been called.

2. Set callback in SSL or SLL_ctx? I have checked the source code of these two 
structures but not sure how to do that.

Those are what I tried and of course failed every try. :( So could anyone point 
me what should I do? Maybe I used wrong engine, missed some important callback 
or others?

Best Regards,

Jim

=

I post my client test code for your reference:

#include 
#include 
#include "openssl/eccx08_engine.h"
#include "openssl/eccx08_engine_internal.h"

int main()
{
    static ENGINE *ateccx08_engine;
    OpenSSL_add_all_algorithms();
    ERR_load_crypto_strings();

    PRINTF("ENGINE_load_dynamic");
    ENGINE_load_dynamic();

    printf("CONF_modules_load_file");
    if (!CONF_modules_load_file(NULL, NULL, CONF_MFLAGS_DEFAULT_SECTION))
    {
    printf("Config failed to load");
    }

    printf("ENGINE_by_id");
    ateccx08_engine = ENGINE_by_id("ateccx08");

    if (ateccx08_engine == NULL)
    {
    printf("Engine failed to load");
    }

    // after some initialization

    // load client-side cert and key, signed by intermediate cert
    SSL_CTX_use_certificate_file(m_ctx, ClientCertificateFileTest, 
SSL_FILETYPE_PEM);

    // no need anymore because no way to extract private key
    // SSL_CTX_use_PrivateKey_file(m_ctx, ClientPrivateKeyFileTest, 
SSL_FILETYPE_PEM);

    // load intermediate cert, signed by CA
     X509* chaincert = X509_new();
    BIO* bio_cert = BIO_new_file(SignerCertificateFileTest, "rb");
    PEM_read_bio_X509(bio_cert, , NULL, NULL);
    SSL_CTX_add1_chain_cert(m_ctx, chaincert)

    m_ssl = SSL_new(m_ctx);

    // get_seocket is my own API
    m_sock = get_socket();

    SSL_set_fd(m_ssl, m_sock)

    // doing handshake and build connection, however no output from ECDSA sign 
algorithm
    auto r = SSL_connect(m_ssl);
}



-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Openssl asynchronous operation in real network

[Ananthu Unnikrishnan]

Can anyone please help on this? If u need any additional information please
let me know.

On Mon, Jan 7, 2019 at 6:25 PM Ananthu Unnikrishnan 
wrote:

> Hi all,
>
> Adding more details to the previous mail. We have edited the OpenSSL code
> for implementing the polling for changed fd's as in OpenSSL speed command.
> Attached the code snippet of the same along with this mail.
> Mentioned below some observations which found doubtful:
>
> 1) We have got prints in ASYNC_FINISH case, before getting print in
> ASYNC_PAUSE case. Attaching the log also, so you can understand easily.
> 2) Shown below the code snippet which we have written to provide a write
> on fd.
>
> if ((waitctx = ASYNC_get_wait_ctx((ASYNC_JOB *)job)) == NULL) {
> printf("In dynamic engine | waitctx == NULL : %d\n", __LINE__);
> return ret;
> }
>
> printf("\n- In dynamic engine | After pausing | job is %lx |
> waitctx in resume job %lx |-\n", job, waitctx);
>
> if ((ret = ASYNC_WAIT_CTX_get_fd(waitctx, engine_id, ,
>   )) > 0) {
> if (write(efd, , sizeof(uint64_t)) == -1) {
> printf("\nFailed to write\n");
> }
> }
>
> Here waitctx is getting NULL when we tried to fetch waitctx using
> ASYNC_get_wait_ctx(). We have printed data of sizeof(ASYNC_JOB) ie.1176
> bytes contained in the job address from the engine,  we got correct data
> before calling ASYNC_pause() and but got half data zero data when we tried
> to access the same address after ASYNC_pause().
>
> Attaching both job structure contents before and after calling
> ASYNC_pause(). Also, we got the correct data in the same address when we
> have printed from ssl_start_async_job() before polling starts, where we
> have started the async_job
> .
> The prints starting with "In dynamic engine" are prints inside the engine,
> rest prints are from ss/ssl_lib.c. Kindly check this and please point out
> if anything is wrong somewhere. Thanks in advance.
>
>
> On Sun, Jan 6, 2019 at 10:30 AM Ananthu Unnikrishnan <
> ananthuu...@gmail.com> wrote:
>
>> Hi all,
>>
>>We have implemented a dynamic engine and tested in the async mode
>> using OpenSSL speed command. But in a real network scenario, we have seen
>> only starting the async_job(in file ssl/ssl_lib.c, function:
>> ssl_start_async_job) in the OpenSSL. We haven't seen polling async_fd's for
>> resuming the job as in apps/speed.c(in speed command case).
>> So can anyone please suggest any solution for resuming the
>> async_jobs in real network scenario? Thanks in advance.
>>
>>
>>
>>
>
> --
> With best Regards,
>
>  Ananthu
>
>
>

-- 
With best Regards,

 Ananthu
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] possible C bugs in ecp_nistp521

[Patrick Steuer]

Dear Bo-Yin Yang,

I looked into your felem_square counterexample:

There is an overflow in the result's least significant 128-bit limb such 
that the computed result is 2^128 smaller than the actual result.


The general problem is the following..

The function's comment says:
/*-
 * felem_square sets |out| = |in|^2
 * On entry:
 *   in[i] < 2^62
 * On exit:
 *   out[i] < 17 * max(in[i]) * max(in[i])
 */

If you look at the function's code youll notice that given the entry 
assumption, the exit assertion's "less than" should actually be a
"less than or equal to" for in the case of all in[i]s being equal to say 
x, max(in[i])=x and out[0]=17*x^2.


So out[0] is stored in 128-bits, but for e.g. x=2^62-1, out[0]>2^128.

If its a bug depends on the contexts from which felem_square is called. 
If for some reason its inputs are guaranteed to satisfy some stricter 
entry condition than stated in the above comment (such that there is no 
overflow) things might be alright.


I didnt look at your other examples but id expect something similar.

Best Regards,

Patrick Steuer
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] RNG behavior by default

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in <20190107183136.-ew61%stef...@sdaoden.eu>:
  ...
 |  ...
 ||RAND_bytes() has always documented that it can fail. Most function
 ...
 |So, to me.., i do not see any possible error condition, since the
 |initial seeding has been testified with RAND_status().
 |
 |This is different now, and i will change the implementation as
 |soon as possible.  (This week.)

So i did, we disable the OpenSSL reseeding by directly calling
RAND_DRBG_set_reseed_defaults() after calling OPENSSL_init_ssl(),
which i hope will always be possible.
Be warned that i gave credit to both of you.

I have seen DRBG offers a lot of possibilities to control what
OpenSSL does, also regarding the fork handlers and all that.
Thanks for these possibilities, it is a terribly huge interface,
but it allows users to have control on what happens, instead of
sitting on an intransparent black box!  Getting something going on
such a thing causes grief, as it is hacky and otherwise
troublesome!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] RNG behavior by default

[Steffen Nurpmeso]

Jakob Bohm via openssl-users wrote in <07f4dea3-1a62-0c8c-76a4-cbe56abc8\
7...@wisemo.com>:
 |On 07/01/2019 22:31, Steffen Nurpmeso wrote:
 |> Good evening.
 |> 
 |> Jakob Bohm via openssl-users wrote in <95bceb59-b299-015a-f9c2-e2487a699\
 |> 8...@wisemo.com>:
 |>|Small corrections below:
 |>| ...
 |
 |Note that I do not represent the project at all, I am just another user 
 |trying to help you.

Surprise!  Indeed i do see your name only once in the commits!
So now, what to do?  What is due?  Congratulations, or even an
excuse?  I had a very false impression indeed.  Excuse this miss
of mine, please.

 |As such, I cannot really respond to your criticism of other project 
 |aspects, some of which I myself don't like either, while others are 
 |obvious to me as someone who has more or less followed along since this 
 |was a two-man Australian project.

Then you lead me by more than a decade in respect to "following"
the project.  (I only saw, otherwise offline, the headers and
libraries fly by.)  (And in my granted lengthy text i thought
about changing my ARC4 thing to ChaCha, and not feed the bytes of
the pool as such, but run a Blake2 digest on top of it, and feed
the output of that.  For now, however, this ARC4 PRNG, and then
also well seeded, is really good enough for my purpose(s).)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Session params output fails via cron

[Jakob Bohm via openssl-users]

On 07/01/2019 22:26, Jordan Brown wrote:

[ Off topic for OpenSSL... ]

On 1/7/2019 8:06 AM, Jakob Bohm via openssl-users wrote:

A chroot with no other reason to open /dev/null should not contain that
file name, even on unix-like platforms (least privilege chroot design).



There's always a first reason :-)

But also:  /dev/null is part of the definition of UNIX 
.  
Programs have every right to expect that it will be there.  Yes, you 
can build a chroot environment that doesn't include it... but then you 
can't complain when programs don't work in your environment.  You can 
also build an environment that doesn't include system libraries, and 
there are reasons to do so, but few programs will work in it.


Looking at Solaris, about 15% of the programs in /usr/bin and 5% of 
the libraries in /usr/lib have a reference to /dev/null.




The whole point of a chroot jail is to deny a program access to any
and all parts of Unix (and the local flavor) it won't need.  For
example, most chroot jails remove /bin/ls, with ftp servers as the
major exception.

Thus /dev/null being part of UNIX/POSIX doesn't say anything about
its availability in chroot jails. Nor does it say anything about
its availability on non-unix platforms, many of which are explicitly
supported by the OpenSSL libraries.

For many programs, it is standard to chroot to a directory with
nothing or almost nothing after loading configuration files, code,
certificates etc. /var/empty and /var/www are common examples.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] RNG behavior by default

[Jakob Bohm via openssl-users]

On 07/01/2019 22:31, Steffen Nurpmeso wrote:
> Good evening.
> 
> Jakob Bohm via openssl-users wrote in <95bceb59-b299-015a-f9c2-e2487a699\
> 8...@wisemo.com>:
>   |Small corrections below:
>   | ...

Note that I do not represent the project at all, I am just another user 
trying to help you.

As such, I cannot really respond to your criticism of other project 
aspects, some of which I myself don't like either, while others are 
obvious to me as someone who has more or less followed along since this 
was a two-man Australian project.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Session params output fails via cron

[Jordan Brown]

[ Off topic for OpenSSL... ]

On 1/7/2019 8:06 AM, Jakob Bohm via openssl-users wrote:
> A chroot with no other reason to open /dev/null should not contain that
> file name, even on unix-like platforms (least privilege chroot design).


There's always a first reason :-)

But also:  /dev/null is part of the definition of UNIX
.
 
Programs have every right to expect that it will be there.  Yes, you can
build a chroot environment that doesn't include it... but then you can't
complain when programs don't work in your environment.  You can also
build an environment that doesn't include system libraries, and there
are reasons to do so, but few programs will work in it.

Looking at Solaris, about 15% of the programs in /usr/bin and 5% of the
libraries in /usr/lib have a reference to /dev/null.

-- 
Jordan Brown, Oracle Solaris

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] RNG behavior by default

[Steffen Nurpmeso]

Good evening.

Jakob Bohm via openssl-users wrote in <95bceb59-b299-015a-f9c2-e2487a699\
8...@wisemo.com>:
 |Small corrections below:
 |
 |On 07/01/2019 19:31, Steffen Nurpmeso wrote:
 |
 ||...
 |||RAND_load_file() and all this stuff. Just make sure the os entropy \
 |||sources
 |||are available and then simply use RAND_bytes(). But don't expect it to
 |||succeed always.
 |
 ||And may i ask, what to do if it fails?  Try it in a loop a finite
 ||number of times, assuming it over-and-over detects it is in an
 ||error state and tries to reseed unless that succeeds, and bail if
 ||still without success thereafter?
 |
 ||Talking about the only program in the public that i represent:
 ||i will not abort that one just because a PRNG fails to produce
 ||some bytes that this program uses for the purpose of, well, having
 ||some (pseudo but) random bytes; because: this is _completely_
 ||disproportionate to the use cases of those random numbers.
 ||I guess the same could be said about UUIDS generated via PRNGs
 ||instead of how the standard defines them, etc. etc.
 ||Please do not say "use random(3) or rand(3)" now, please.
 ||So what to do?
 |
 |"Just failing" is precisely to allow you (and others) to do something 
 |sensible without the random bytes, such as using something less secure, 
 |or doing a polite error reporting to the user.

I have to say i struggle with the OpenSSL project release
announcements.  Really.  I see a short mail which simply points
users to some (granted super duper) web site (with custom fonts
and such -- it must look fantastic on such a tablet thing that
i do not own!), and on these pages, which i, unfortunately and
until now, over and over again look at, ... to see nothing.

I mean, OpenSSL is such a vivid part of the infrastructure, top
that with security, of the world, it is used a billion of times
each and every day, and how many people really now about the
details inside this library with the terrible interface names (a
few minutes ago i discovered the also new ADMISSIONS.pod
documentation, and this is a statement for a language with
namespaces and method-on-object not instance-on-function; i always
think by myself that some university should perform neurological
science on what looking at

  const STACK_OF(ADMISSIONS) *ADMISSION_SYNTAX_get0_contentsOfAdmissions(const 
ADMISSION_SYNTAX *as);

from 9 to 5 (or 14 to 04 or whatever)/365-52 actually causes, how
do you say that in english?, what damages to the brain it causes,
anyway.)

The thing is, i have just seen the release candidate announcement
for bash 5.0 a while ago, and know what my own release message
will (have to) look like.

I did know nothing of all that.

 |||> I think i will move away from RAND_ then, nonetheless, and at
 |||> least for the things i have control of.
 |||
 |||I don't think this is a good idea. In the case when there is no suitable \
 |||\
 |||entropy
 |||source, the OpenSSL RNG will fail to generate random bytes, indeed.
 |||But how do you expect your application to seed the RNG properly in this
 |||case? What is your application's entropy source? If you have one, which
 |
 ||Yes, that is the problem.  We do have several possibilities for
 ||VAL_RANDOM.  Some of them only seed our builtin ARC4
 ||implementation, which until now exposes the internal buffer as
 ...
 ||randomizing those weakly through the well-known algorithm from
 ||"Random number generators: good ones are hard to find", Park and
 ||Miller, Communications of the ACM, vol. 31, no. 10, October 1988,
 ||p. 1195 (a_aux_rand_weak()).  This is the code:
 ...
 |Note that since that ancient article, ARC4 was not only invented, 
 |but also found too insecure for modern use.

I seem to know that for things like save transport.
I have for example suppressed adding the 

   for(u.i = 5 * sizeof(a_aux_rand->b8); u.i != 0; --u.i)
  a_aux_rand_get8();

which follows the unscientific seeding.  (And which likely is also
unscientific given that we have been seeded with random data
rather than with key/nonce ... whatever.)

 |Enjoy

Not really!  For example i read

  The reseeding default values are applied only during creation of
  a DRBG instance.  To ensure that they are applied to the global
  and thread-local DRBG instances (, resp.  and
  ), it is necessary to call
  RAND_DRBG_set_reseed_defaults() before creating any thread and
  before calling any cryptographic routines that obtain random
  data directly or indirectly.

Does this give me at least the promise that OPENSSL_init_ssl() can
be called without rendering RAND_DRBG_set_reseed_defaults(0,0,0,0)
effectively a useless call?
I see that said function may return error, but it seems that the
MAX_RESEED_INTERVAL it fails to accept is not a public variable!
I tend to do the much more expensive dance with
RAND_DRBG_get0_public() and RAND_DRBG_get0_master() and
individually applying RAND_DRBG_set_reseed_time_interval() as well
as RAND_DRBG_set_reseed_interval() on each of them.
Is this even allowed 

Re: [openssl-users] RNG behavior by default

[Jakob Bohm via openssl-users]

  
  
Small corrections below:
  
  On 07/01/2019 19:31, Steffen Nurpmeso wrote:


  ...


 |> That is really bad.  Of course you had to do it like this, and you
 |> surely have looked around to see what servers and other software
 |> which use OpenSSL do with the PRNG after forking (i.e., whether
 |> they reiterate the [RAND_file_name(),] RAND_load_file(),
 |> [:[RAND_add(),] RAND_status()], [RAND_write_file()] dance as
 |> documented, or not).
 |
 |I really don't understand your frustration: the new PRNG was designed
 |to relieve the application from the burden of seeding. It is easier to use,
 |not more complicated: No need to call RAND_add(), RAND_seed(),
 |RAND_load_file() and all this stuff. Just make sure the os entropy sources
 |are available and then simply use RAND_bytes(). But don't expect it to
 |succeed always.

And may i ask, what to do if it fails?  Try it in a loop a finite
number of times, assuming it over-and-over detects it is in an
error state and tries to reseed unless that succeeds, and bail if
still without success thereafter?

Talking about the only program in the public that i represent:
i will not abort that one just because a PRNG fails to produce
some bytes that this program uses for the purpose of, well, having
some (pseudo but) random bytes; because: this is _completely_
disproportionate to the use cases of those random numbers.
I guess the same could be said about UUIDS generated via PRNGs
instead of how the standard defines them, etc. etc.
Please do not say "use random(3) or rand(3)" now, please.
So what to do?


"Just failing" is precisely to allow you (and others) to do
  something 
  sensible without the random bytes, such as using something less
  secure, 
  or doing a polite error reporting to the user.


  

 |> I think i will move away from RAND_ then, nonetheless, and at
 |> least for the things i have control of.
 |
 |I don't think this is a good idea. In the case when there is no suitable \
 |entropy
 |source, the OpenSSL RNG will fail to generate random bytes, indeed.
 |But how do you expect your application to seed the RNG properly in this
 |case? What is your application's entropy source? If you have one, which

Yes, that is the problem.  We do have several possibilities for
VAL_RANDOM.  Some of them only seed our builtin ARC4
implementation, which until now exposes the internal buffer as
such (sufficient for our purpose yet).  Examples of this are
/dev/urandom, Linux getrandom as system call or library call,
aehh...  If that seeding fails, we create a completely
unscientific homebrew seed via CLOCK_REALTIME or gettimeofday(2),
whatever is available, wildly XORing through the buffer, further
randomizing those weakly through the well-known algorithm from
"Random number generators: good ones are hard to find", Park and
Miller, Communications of the ACM, vol. 31, no. 10, October 1988,
p. 1195 (a_aux_rand_weak()).  This is the code:


Note that since that ancient article, ARC4 was not only
  invented, 
  but also found too insecure for modern use.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded 
  

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] RNG behavior by default

[Steffen Nurpmeso]

A wonderful Monday in the beautiful Winter time i wish.

I am sorry for the late reply again, i got a bug report for the
mailer i maintain, and from a long time user.
I hope it is ok that i compress the answers in one message, i am
talking much too much...

Kurt Roeckx wrote in <20190105221506.ga18...@roeckx.be>:
 |On Sat, Jan 05, 2019 at 08:33:18PM +0100, Steffen Nurpmeso wrote:
 |> 
 |> (I am also really interested and will look into OpenSSL to see if
 |> the abort() that seems to happen if the initial seed fails is in
 |> a linker-resolved constructor, and if not, why later failures do
 |> not also abort.
 |
 |We do not call abort(). A function like RAND_bytes() or
 |RAND_status() will just return an error.

Aah, i see.  I obviously had a completely false impression of the
new design.  I do not know where this came from, if i now search
in doc/ of the [master] there no mention of such wording, neither
abort nor exit nor whatever.  Hmm.?

  ...
 |RAND_bytes() has always documented that it can fail. Most function
 |calls can return errors for various reasons. Not checking for such
 |errors is in my opinion a bad style.

Well i, and until just now, interpreted the PRNG as something like
a "cipher stream", which simply applies (magic, to me) math to
a buffer of undefined content and an algorithm-chosen size.  Just
like MD5, which' RFC (1321) does not have error conditions.  (A
digest, but i had the RFC number at hand.)

So, to me.., i do not see any possible error condition, since the
initial seeding has been testified with RAND_status().

This is different now, and i will change the implementation as
soon as possible.  (This week.)

 |> i do not like that the stuff is instantiated in all threads
 |
 |It's only created in each thread that tries to the RNG. I'm not
 |sure what exactly your problem with it is. Either we need a global
 |lock, or we need an RNG per thread. We went with the per thread
 |RNG.

All my fault.  As a side note, i remember a commit message of
DragonFlyBSD and M. Dillon fly by (some years ago) where he
utilized the effect of SMP races as a random source.  If i recall
correctly.  Of course you had to protect the reseed count or
whatever (but there atomic cas or a spinlock would suffice
i guess).

 |We have a master DRBG that you can get with
 |RAND_DRBG_get0_master(). I recommend that you do not use it. It
 |requires that you take an external lock to use it. Internally we
 |lock it, but there is no way for you to use the same lock.
 |
 |> which
 |> in addition requires forks handlers to be installed all over the
 |> place.
 |
 |OpenSSL adds it's own fork handler now. You should not need to do
 |anything on fork related to OpenSSL.

It is just, to me, lack of standard.  But i do not dlopen() you,
and i do not dlclose() you.  In this scenario libraries may do use
anything, install atexit, onfork, whatever.  Other SSL libraries
even removed the possibility to hook the memory allocation
methods!

 |> the Linux kernel that drives
 |> the world from smallest to hugest has one internal entropy pool
 |> that feeds two public pools, whereas i the lucent little hobby
 |> server from user space get an armada of these.  Wow.
 |
 |Linux has a master pool, and a pool per core for the very same
 |reason as we also have a master DRBG and per thread DRBG.

I have read [1], but not that thorougly.  I was referring to the
user space interface, anyway.  (The thing is, i would have
preferred reading a one or two pages abstract instead of flying
over 138 pages.  I seem to know he knows.  I have read some
dissertations in my life, and i like the dedication if people
translate a complete system manual to German there, or show in
detail that they know know know their topic.  Having said that,
a very nice such work i have read from the Uni Kaiserslautern, it
was about 30 pages and it had been clear that "he can", shaking
off his hand.  Why need more?  Very good.  Imho.)

  [1] 
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/LinuxRNG/LinuxRNG_EN.pdf?__blob=publicationFile=7

 --End of <20190105221506.ga18...@roeckx.be>

Dr. Matthias St. Pierre wrote in :
 |>|Both manpages got an update during the DRBG rewrite (by me) and I don't
 |>|see any contradiction. You bring it to the point yourself:
 |> 
 |> I had a superficial look yesterday, but i think i have to reread
 |> them in total, anyway.
 |
 |Yes, please start with RAND(7) and RAND_DRBG(7).

Thanks.  I did just now.

 |> That is really bad.  Of course you had to do it like this, and you
 |> surely have looked around to see what servers and other software
 |> which use OpenSSL do with the PRNG after forking (i.e., whether
 |> they reiterate the [RAND_file_name(),] RAND_load_file(),
 |> [:[RAND_add(),] RAND_status()], [RAND_write_file()] dance as
 |> documented, or not).
 |
 |I really don't understand your frustration: the new PRNG was designed
 |to relieve the application from the burden of seeding. It is easier to use,
 |not more 

Re: [openssl-users] Compiling FIPS-cable OpenSSL on Windows Server 2012R2

[Chris Fernando via openssl-users]

> 
> On Jan 7, 2019, at 09:20, Chris Fernando via openssl-users 
>  wrote:
> 
> I perused the list archives for all of 2018 and did not see anything current 
> relating to this problem, so if this is a question that has been asked & 
> answered, please feel free to point me at the relevant location to read about 
> what I'm doing incorrectly. =)
> 
> I'm not at all familiar with Windows & compiling Open Source projects, but I 
> am having no trouble on Linux with OpenSSL + FIPS. On Windows, with Visual 
> Studio 2017 (Community Edition), I am able to compile the FIPS 2.0.16 module 
> and OpenSSL 1.0.2q (NO FIPS) without issue.
> 
> [snip]
> 
> 
> I am doing the following to compile FIPS:
> cd c:\path\to\fips-source
> ms\do_fips no-asm
> 
> I am doing the following to compile OpenSSL+FIPS (Strawberry Perl installed):
> cd c:\path\to\openssl-source
> nmake -f ms\ntdll.mak clean
> nmake -f ms\nt.mak clean
> perl Configure VC-WIN64A fips no-asm --with-fipsdir=c:\path\to\fips-source
> ms\do_win64a no-asm
> nmake -f ms\ntdll.mak
> 
> [snip]


Well, I managed to get the compile to move a bit further by copying "inc32" to 
"include", "util" to "bin", and "out32dll" to "lib" in the FIPS source 
directory, that I was including in --with-fipsdir= .

However, now I am getting the following error during the OpenSSL build process.


cl /Fotmp32dll\fips_premain_dso.obj -DFINGERPRINT_PREMAIN_DSO_LOAD -Iinc
32 -Itmp32dll /MD /Ox -DOPENSSL_THREADS  -DDSO_WIN32 -W3 -Gs0 -Gy -nologo -DOPEN
SSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DUNICODE -D_UNICODE -D_CRT_S
ECURE_NO_DEPRECATE -IC:\Users\cfernando\Downloads\ossl\ossl\openssl-fips/include
 -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_SSL2 -
DOPENSSL_NO_KRB5 -DOPENSSL_FIPS -DOPENSSL_NO_JPAKE -DOPENSSL_NO_WEAK_SSL_CIPHERS
 -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/app -c C:\Users\cfernando\Downloads\
ossl\ossl\openssl-fips\lib\fips_premain.c
fips_premain.c
ml  /c ms\uptable.asm
Microsoft (R) Macro Assembler Version 14.16.27025.1
Copyright (C) Microsoft Corporation.  All rights reserved.

 Assembling: ms\uptable.asm
ms\uptable.asm(9) : error A2006:undefined symbol : rsp
ms\uptable.asm(10) : error A2006:undefined symbol : rsp
ms\uptable.asm(11) : error A2006:undefined symbol : rsp
ms\uptable.asm(12) : error A2006:undefined symbol : rsp
ms\uptable.asm(13) : error A2006:undefined symbol : rcx
ms\uptable.asm(14) : error A2006:undefined symbol : rdx
ms\uptable.asm(16) : error A2006:undefined symbol : rcx
ms\uptable.asm(17) : error A2006:undefined symbol : rdx
ms\uptable.asm(18) : error A2006:undefined symbol : r8
ms\uptable.asm(19) : error A2006:undefined symbol : r9
ms\uptable.asm(20) : error A2006:undefined symbol : rax
ms\uptable.asm(21) : error A2006:undefined symbol : rsp
ms\uptable.asm(22) : error A2006:undefined symbol : rax
ms\uptable.asm(29) : error A2006:undefined symbol : rsp
ms\uptable.asm(30) : error A2006:undefined symbol : rsp
ms\uptable.asm(31) : error A2006:undefined symbol : rsp
ms\uptable.asm(32) : error A2006:undefined symbol : rsp
ms\uptable.asm(33) : error A2006:undefined symbol : rcx
ms\uptable.asm(34) : error A2006:undefined symbol : rdx
ms\uptable.asm(36) : error A2006:undefined symbol : rcx
ms\uptable.asm(37) : error A2006:undefined symbol : rdx
ms\uptable.asm(38) : error A2006:undefined symbol : r8
ms\uptable.asm(39) : error A2006:undefined symbol : r9
ms\uptable.asm(40) : error A2006:undefined symbol : rax
ms\uptable.asm(41) : error A2006:undefined symbol : rsp
ms\uptable.asm(42) : error A2006:undefined symbol : rax
ms\uptable.asm(49) : error A2006:undefined symbol : rsp
ms\uptable.asm(50) : error A2006:undefined symbol : rsp
ms\uptable.asm(51) : error A2006:undefined symbol : rsp
ms\uptable.asm(52) : error A2006:undefined symbol : rsp
ms\uptable.asm(53) : error A2006:undefined symbol : rcx
ms\uptable.asm(54) : error A2006:undefined symbol : rdx
ms\uptable.asm(56) : error A2006:undefined symbol : rcx
ms\uptable.asm(57) : error A2006:undefined symbol : rdx
ms\uptable.asm(58) : error A2006:undefined symbol : r8
ms\uptable.asm(59) : error A2006:undefined symbol : r9
ms\uptable.asm(60) : error A2006:undefined symbol : rax
ms\uptable.asm(61) : error A2006:undefined symbol : rsp
ms\uptable.asm(62) : error A2006:undefined symbol : rax
ms\uptable.asm(69) : error A2006:undefined symbol : rsp
ms\uptable.asm(70) : error A2006:undefined symbol : rsp
ms\uptable.asm(71) : error A2006:undefined symbol : rsp
ms\uptable.asm(72) : error A2006:undefined symbol : rsp
ms\uptable.asm(73) : error A2006:undefined symbol : rcx
ms\uptable.asm(74) : error A2006:undefined symbol : rdx
ms\uptable.asm(76) : error A2006:undefined symbol : rcx
ms\uptable.asm(77) : error A2006:undefined symbol : rdx
ms\uptable.asm(78) : error A2006:undefined symbol : r8
ms\uptable.asm(79) : error A2006:undefined symbol : r9
ms\uptable.asm(80) : error A2006:undefined symbol : rax
ms\uptable.asm(81) : error A2006:undefined symbol : rsp

Re: [openssl-users] Session params output fails via cron

[Jakob Bohm via openssl-users]

On 04/01/2019 22:04, Michael Wojcik wrote:

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Jordan Brown
Sent: Friday, January 04, 2019 13:16
If you want to, what you want is something like:
   int fd;
   do {
   fd = open("/dev/null", O_RDWR);
   } while (fd < 3);
   close(fd);
(That's strictly not quite right, since it leaves 0 open writable and 1 and 2 
open readable,
but that's pretty harmless.)

Behavior is unfortunate if open fails, e.g. because the NFILES limit is reached, or because 
/dev/null is inaccessible (e.g. due to a poorly-configured chroot). You'd be better off with 
(fd >= 0 && fd < 3).

Since source bytes are cheap, though, and there are at most three opens to be 
done, I'd just do it explicitly for the three stdio descriptors. That would 
also make the intention clear. (Yes, the intention of your version is clear to 
old UNIX hands. It might not be to other people.)

I'm ignoring portability considerations, since I personally don't think this 
would be a great thing to implement in the apps, so I'm not going to be 
submitting a PR for it.


A chroot with no other reason to open /dev/null should not contain that
file name, even on unix-like platforms (least privilege chroot design).

Please refer to my previous post about the many other reasons why
opening /dev/null has a high risk of failure.

Stepping back, it is worth investigating if:

 - Running TLS1.3 s_client with -ignoreeof and no stdin actually fails
  earlier than with stdin == /dev/null

 - If this is triggered by a code bug.

P.S.

On some Debian systems, cron runs scripts with stdout and stderr piped
(directly or indirectly) to a mail program that times out if a cron job
runs for a long time.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Compiling FIPS-cable OpenSSL on Windows Server 2012R2

[Chris Fernando via openssl-users]

I perused the list archives for all of 2018 and did not see anything current 
relating to this problem, so if this is a question that has been asked & 
answered, please feel free to point me at the relevant location to read about 
what I'm doing incorrectly. =)

I'm not at all familiar with Windows & compiling Open Source projects, but I am 
having no trouble on Linux with OpenSSL + FIPS. On Windows, with Visual Studio 
2017 (Community Edition), I am able to compile the FIPS 2.0.16 module and 
OpenSSL 1.0.2q (NO FIPS) without issue.

When I try to compile OpenSSL with the FIPS canister, per the User Guide 
instructions, I end up with the following error.

cl /Fotmp32dll\o_fips.obj  -Iinc32 -Itmp32dll /MD /Ox -DOPENSSL_THREADS
 -DDSO_WIN32 -W3 -Gs0 -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN
-DL_ENDIAN -DUNICODE -D_UNICODE -D_CRT_SECURE_NO_DEPRECATE -Ic:\..\openssl-fips/
include -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO
_SSL2 -DOPENSSL_NO_KRB5 -DOPENSSL_FIPS -DOPENSSL_NO_JPAKE -DOPENSSL_NO_WEAK_SSL_
CIPHERS -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL  -DOPENSSL_BUIL
D_SHLIBCRYPTO -c .\crypto\o_fips.c
o_fips.c
.\crypto\o_fips.c(61): fatal error C1083: Cannot open include file: 'openssl/fip
s.h': No such file or directory
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017
\Community\VC\Tools\MSVC\14.16.27023\bin\HostX86\x86\cl.EXE"' : return code '0x2
'
Stop.


I am doing the following to compile FIPS:
cd c:\path\to\fips-source
ms\do_fips no-asm

I am doing the following to compile OpenSSL+FIPS (Strawberry Perl installed):
cd c:\path\to\openssl-source
nmake -f ms\ntdll.mak clean
nmake -f ms\nt.mak clean
perl Configure VC-WIN64A fips no-asm --with-fipsdir=c:\path\to\fips-source
ms\do_win64a no-asm
nmake -f ms\ntdll.mak


I feel like I'm missing something fundamental here and I know the User Guide 
says to install the FIPS files in a protected area. However, as I'm just 
building the source on this device, shouldn't I be able to to do the above and 
have it work?

Any help would be greatly appreciated.


Thanks,

Chris
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] possible C bugs in ecp_nistp521

[Bo-Yin Yang]

Dear all,

we found some counter-examples (examples where wrong answers were 
returned) for field element computations in the C routines for P-521 
(that is, modulo 2^521-1).   The counterexamples, a C test file, a 
Makefile, and a short README are attached.


The routines in question are: felem_square, felem_mul, felem_diff_128_64.

Can someone inform us whether these are in fact a couple of bugs that we 
found, or did we miss something.


Best wishes,
Bo-Yin Yang


P.S.

The counterexamples are:

- for felem_square and felem_mul:
  felem in = {
0x3fd9049d07fdc0ad, 0x3ece5f40, 0x39c5349d6a623811,
0x3bf48f8409415499, 0x3ffdac80c830, 0x3ff3f3de63be6baf,
0x3fa3eff5c6db1743, 0x3dde8d0ddc21079f, 0x3e068b5ec961f8fc
  };

- for felem_diff_128_64:
  largefelem out = {
0,0,0,
0,0,0,
0,0,0
  };
  felem in = {
0x40012270, 0x1000, 0x0010,
0x0400, 0x0800, 0x0020,
0x4000, 0x0002, 0x0004
  };

-- B.Y.

all: check.c $(SRC_DIR)/crypto/ec/ecp_nistp521.c
$(CC) -I$(SRC_DIR) -I$(SRC_DIR)/include -I$(SRC_DIR)/crypto/include \
-pthread -m64 -std=c99 -Wall -fdata-sections 
-ffunction-sections \
-o check check.c $(SRC_DIR)/libcrypto.a -ldl
clean:
rm -f check
#include 
#include 
#include 
#include 

void felem2bn(const felem fe_in, BIGNUM *bn_out);
void largefelem2bn(const largefelem lfe_in, BIGNUM *bn_out);
void print_uint128x(uint128_t n);
void test_felem_square(const felem in);
void test_felem_mul(const felem in1, const felem in2);
void test_felem_diff_128_64(largefelem in1, const felem in2);

# define WIDTH 16


int main() {

  // ///
  //
  //test cases
  // 
  // ///  

  // felem_square: counter-example
  const felem felem_square_ce_in = {
0x3fd9049d07fdc0ad, 0x3ece5f40, 0x39c5349d6a623811,
0x3bf48f8409415499, 0x3ffdac80c830, 0x3ff3f3de63be6baf,
0x3fa3eff5c6db1743, 0x3dde8d0ddc21079f, 0x3e068b5ec961f8fc
  };
  
  // felem_square: passed input
  const felem felem_square_pass_in = {
0x03d9049d07fdc0ad, 0x03ce5f40, 0x03c5349d6a623811,
0x03f48f8409415499, 0x03fdac80c830, 0x03f3f3de63be6baf,
0x03a3eff5c6db1743, 0x03de8d0ddc21079f, 0x03068b5ec961f8fc
  };

  test_felem_square(felem_square_ce_in);
  test_felem_square(felem_square_pass_in);  

  // this set of counter-example and passed example also
  // applies to felem_mul
  test_felem_mul(felem_square_ce_in, felem_square_ce_in);
  test_felem_mul(felem_square_pass_in, felem_square_pass_in);

  /* ***

  // felem_mul: counter-example
  const felem felem_mul_ce_in1 ={
0x1b3e1fbef8001001, 0x7f242123e1c46fde, 0x7f10040641544b02,
0x7fe1d322ad709e50, 0x7faf1f788008, 0x,
0x, 0x, 0x
  };
  const felem felem_mul_ce_in2 = {
0x, 0x7f9893c0f6a10cd6, 0x7fbff2c00f07ec56,
0x7fa01f1d8ab5bb53, 0x75a2b33a238bce82, 0x3fc66780b6dab606,
0x, 0x, 0x
  };

  // felem_mul: passed input
  const felem felem_mul_pass_in1 ={
0x1b3e1fbef8001001, 0x3f242123e1c46fde, 0x3f10040641544b02,
0x3fe1d322ad709e50, 0x3faf1f788008, 0x,
0x, 0x, 0x
  };
  const felem felem_mul_pass_in2 = {
0x, 0x3f9893c0f6a10cd6, 0x3fbff2c00f07ec56,
0x3fa01f1d8ab5bb53, 0x35a2b33a238bce82, 0x3fc66780b6dab606,
0x, 0x, 0x
  };

  test_felem_mul(felem_mul_ce_in1, felem_mul_ce_in2);
  test_felem_mul(felem_mul_pass_in1, felem_mul_pass_in2);

  *** */

  // felem_diff_128_64: counter-example
  largefelem felem_diff_128_64_ce_in1 = {
0,0,0,
0,0,0,
0,0,0
  };
  const felem felem_diff_128_64_ce_in2 = {
0x40012270, 0x1000, 0x0010,
0x0400, 0x0800, 0x0020,
0x4000, 0x0002, 0x0004
  };

  // felem_diff_128_64: passed input
  largefelem felem_diff_128_64_pass_in1 = {
0,0,0,
0,0,0,
0,0,0
  };
  const felem felem_diff_128_64_pass_in2 = {
0x30012270, 0x1000, 0x0010,
0x0400, 0x0800, 0x0020,
0x4000, 0x0002, 0x0004
  };
  
  test_felem_diff_128_64(felem_diff_128_64_ce_in1, felem_diff_128_64_ce_in2);
  test_felem_diff_128_64(felem_diff_128_64_pass_in1, felem_diff_128_64_pass_in2);  


  return 0;
}

void test_felem_square(const felem fe_in) {

  BN_CTX *ctx = BN_CTX_new();  

  // p = 2^521 - 1
  BIGNUM *bn_p = BN_new();
  BN_one(bn_p);
  BN_lshift(bn_p, bn_p, 521);
  BN_sub(bn_p, bn_p, BN_value_one());
  //printf("%s\n", 

Re: [openssl-users] Openssl asynchronous operation in real network

[Ananthu Unnikrishnan]

Hi all,

Adding more details to the previous mail. We have edited the OpenSSL code
for implementing the polling for changed fd's as in OpenSSL speed command.
Attached the code snippet of the same along with this mail.
Mentioned below some observations which found doubtful:

1) We have got prints in ASYNC_FINISH case, before getting print in
ASYNC_PAUSE case. Attaching the log also, so you can understand easily.
2) Shown below the code snippet which we have written to provide a write on
fd.

if ((waitctx = ASYNC_get_wait_ctx((ASYNC_JOB *)job)) == NULL) {
printf("In dynamic engine | waitctx == NULL : %d\n", __LINE__);
return ret;
}

printf("\n- In dynamic engine | After pausing | job is %lx |
waitctx in resume job %lx |-\n", job, waitctx);

if ((ret = ASYNC_WAIT_CTX_get_fd(waitctx, engine_id, ,
  )) > 0) {
if (write(efd, , sizeof(uint64_t)) == -1) {
printf("\nFailed to write\n");
}
}

Here waitctx is getting NULL when we tried to fetch waitctx using
ASYNC_get_wait_ctx(). We have printed data of sizeof(ASYNC_JOB) ie.1176
bytes contained in the job address from the engine,  we got correct data
before calling ASYNC_pause() and but got half data zero data when we tried
to access the same address after ASYNC_pause().

Attaching both job structure contents before and after calling
ASYNC_pause(). Also, we got the correct data in the same address when we
have printed from ssl_start_async_job() before polling starts, where we
have started the async_job
.
The prints starting with "In dynamic engine" are prints inside the engine,
rest prints are from ss/ssl_lib.c. Kindly check this and please point out
if anything is wrong somewhere. Thanks in advance.


On Sun, Jan 6, 2019 at 10:30 AM Ananthu Unnikrishnan 
wrote:

> Hi all,
>
>We have implemented a dynamic engine and tested in the async mode
> using OpenSSL speed command. But in a real network scenario, we have seen
> only starting the async_job(in file ssl/ssl_lib.c, function:
> ssl_start_async_job) in the OpenSSL. We haven't seen polling async_fd's for
> resuming the job as in apps/speed.c(in speed command case).
> So can anyone please suggest any solution for resuming the
> async_jobs in real network scenario? Thanks in advance.
>
>
>
>

-- 
With best Regards,

 Ananthu


ASYNC_JOB_contents_after_pause
Description: Binary data


ASYNC_JOB_contents_before_pause
Description: Binary data


log_async_job
Description: Binary data
static int ssl_start_async_job(SSL *s, struct ssl_async_args *args,
		int (*func) (void *))
{
	int ret;
	static int num_inprogress = 0;
	int job_op_count = 0;
	int total_op_count = 0, async_jobs, i, error;
	size_t num_job_fds = 0;
	OSSL_ASYNC_FD job_fd = 0;
	OSSL_ASYNC_FD efd;
	static ASYNC_JOB *job[3];
	static ASYNC_WAIT_CTX *waitctx[3];
	void *custom = NULL;
	uint64_t buf = 1;

	if (s->waitctx == NULL) {
		s->waitctx = ASYNC_WAIT_CTX_new();
		if (s->waitctx == NULL) {

			printf("\nError on s->waitctx == NULL \n");
			return -1;
		}
	}
	switch (ASYNC_start_job(>job, s->waitctx, , func, args,
sizeof(struct ssl_async_args))) {
		case ASYNC_ERR:
			s->rwstate = SSL_NOTHING;
			SSLerr(SSL_F_SSL_START_ASYNC_JOB, SSL_R_FAILED_TO_INIT_ASYNC);
			return -1;
		case ASYNC_PAUSE:
			printf("\nIn ASYNC_PAUSE | num_inprogress is %d \n", num_inprogress);
			job[num_inprogress] = s->job;
			waitctx[num_inprogress] = s->waitctx;
			++num_inprogress;
			s->rwstate = SSL_ASYNC_PAUSED;
			if (num_inprogress < MAX_JOB) { /* MAX_JOB currently set as 1 */
return -1;
			} else {
break;
			}
		case ASYNC_NO_JOBS:
			s->rwstate = SSL_ASYNC_NO_JOBS;
			return -1;
		case ASYNC_FINISH:
			if (job_op_count == -1) {
error = 1;
printf("\nError on ASYNC_FINISH\n");
			} else {
total_op_count += job_op_count;
			}
			printf("\nIn ASYNC_FINISH | job : %lx | waitctx is %lx | ret: %d \n", s->job, s->waitctx, ret);
			s->job = NULL;
			return ret;
		default:
			s->job = NULL;
			s->rwstate = SSL_NOTHING;
			SSLerr(SSL_F_SSL_START_ASYNC_JOB, ERR_R_INTERNAL_ERROR);
			/* Shouldn't happen */
			return -1;
	}

	while (num_inprogress > 0) {
		int select_result = 0;
		OSSL_ASYNC_FD max_fd = 0;
		fd_set waitfdset;
		ASYNC_WAIT_CTX *waitctx_p;

		FD_ZERO();
		async_jobs = num_inprogress;
		for (i = 0; i < async_jobs && num_inprogress > 0; i++) {
			printf("\n-- job[%d]: %lx waitctx[%d]: %lx ---\n", i, job[i], i, waitctx[i]);
			if (job[i] == NULL)
continue;
			if (!ASYNC_WAIT_CTX_get_all_fds(waitctx[i], NULL, _job_fds) || num_job_fds > 1) {
printf("\n--Too many fds in ASYNC_WAIT_CTX-\n");
break;
			}
			ASYNC_WAIT_CTX_get_all_fds(waitctx[i], _fd, _job_fds);
			printf("\n--- num_job_fds is %d | job_fd is %d | max_fd is %d \n", num_job_fds, job_fd, max_fd);
			FD_SET(job_fd, );
			if (job_fd > max_fd)
max_fd = job_fd;
		}

		select_result = select(max_fd + 1, , NULL,