Well,
After looking at /dev/random, I noticed that it's not being updated as
fast as /dev/urandom...
So I just thought to force libgcrypt to use /dev/urandom.
To do this I changed the libgcrypt configure file (lines 13082:13803) from
*NAME_OF_DEV_RANDOM="/dev/random"**
**NAME_OF_DEV_URANDOM=***"/dev/urandom"**
**to**
**
*NAME_OF_DEV_URANDOM="/dev/urandom"
NAME_OF_DEV_RANDOM=NAME_OF_DEV_URANDOM*****
so effectively forcing the lib to use */dev/urandom*.
I recompiled all in a moment and it seems it works fine !
Now libssh2 starts sending files from the first seconds after boot.
Thanks Peter !
Simon
On 6/22/21 5:36 PM, Simone Azzalin wrote:
> Hello Peter,
>
> Thank for your useful information. Yes this is an embedded system.
> I will try the solution that you suggest as soon as possible and give
> you a feedback.
>
> Simon
>
> On 6/22/21 4:24 PM, Peter Stuge wrote:
>> Simone Azzalin wrote:
>>> I have noticed that during the first minutes after boot, the
>>> libssh2_session_handshake execution remains stuck blocking the
>>> execution of the program.
>> Is that an embedded system, without a strong entropy source?
>>
>>
>>> Is this a known issue ? Do you have any possible suggestion to
>>> determine the cause of it ?
>> The session handshake includes among other things a key exchange,
>> which requires random numbers.
>>
>> When the system has little entropy, such as after boot when not much
>> has happened, then when the crypto library that libssh2 uses (so not
>> libssh2 itself) reads /dev/random that read will hard block until
>> more entropy becomes available.
>>
>> One ideal solution would be a dedicated hardware entropy source.
>>
>> The most basic workaround is to save a /dev/random seed across reboots
>> by saving the /dev/random contents to a file when shutting down and
>> writing it back to /dev/random on boot.
>>
>>
>> If you neglect this issue and choose not to implement any solution to
>> the lack of entropy problem then your /dev/random becomes predictable
>> across boots, rendering any asymmetric encryption on the system useless;
>> allowing MITM attacks and perhaps even worse extraction of the SSH
>> authentication credentials.
>>
>>
>> //Peter
>> _______________________________________________
>> libssh2-develhttps://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
>
> --
> *Simone Azzalin*
> *Embedded Systems Engineer | DARES TECHNOLOGY*
> Esteve Terrades, 1 | Edificio RDIT, Parc UPC – PMT | E – 08860
> Castelldefels, Barcelona
> +34 93 514 1652 | sazzalin_at_dares.tech <mailto:sazzalin_at_dares.tech> |
> www.dares.tech <http://www.dares.tech/> | Legal notice
> <http://dares.tech/legal-notice/>
>
> _______________________________________________
> libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
-- *Simone Azzalin* *Embedded Systems Engineer | DARES TECHNOLOGY* Esteve Terrades, 1 | Edificio RDIT, Parc UPC – PMT | E – 08860 Castelldefels, Barcelona +34 93 514 1652 | sazzalin_at_dares.tech <mailto:sazzalin_at_dares.tech> | www.dares.tech <http://www.dares.tech/> | Legal notice <http://dares.tech/legal-notice/>
_______________________________________________
libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2021-06-23