CSRNG

Mon Aug 23, 2021 10:51 pm

Recently, some developments have been made in the field of (network level) encryption support (TLS, SSH).
Therefore, the need for a CSRNG (Cryptographically Secure Random Number Generator) has arisen.

According to the literature I have seen, the only sensible way is to place it inside the kernel, where it has access to the required entropy sources.
I am definitely no expert in the field, but unless someone else steps forward, it seems like I will have to implement it myself

I found the Fortuna PRNG quite promising and seemingly manageable even for me to implement.

Anyone thoughts?

Tue Aug 24, 2021 3:11 am

Рустем (rgimad) уже находи некоторые источники энтропии и использовал их в программе http://websvn.kolibrios.org/listing.php ... eb65c8c626

rgimad has already found some sources of entropy and used them in the program http://websvn.kolibrios.org/listing.php ... eb65c8c626

Tue Aug 24, 2021 8:53 am

Doczom: I am talking already about the next level

Tue Aug 24, 2021 11:02 pm

You hardly expected anything except 'looks great, why not', so here it is. Looks great, why not.

It is a common practice for mature systems to have such a syscall. And its implementation seems to be quite compact. It is probably the best we can do without being crypto experts.

I could cover your implementation with unit tests using my UMKa tool.

Wed Aug 25, 2021 12:18 am

Of course, there is no such thing as a free meal.
If we want to have great random numbers, they must be paid in CPU time.

The idea is to collect entropy at the following places:
- At set_keyboard_data in keyboard.inc (current hpet/rdtsc timer value (least significant bits) and scancode on keyboard event)
- At irq_serv_h.main in irq.inc (current hpet/rdtsc timer value (least significant bits) on various non-keyboard interrupts)
- At set_mouse_data in mousedrv.inc (from cursor xpos, ypos (least significant bits), buttons on mouse event)

I believe anyone here can see that we will need some computational time at those crucial parts in kernel, to collect that entropy.
The proposed algorithm(s) try to keep this cost at a minimum and postpone most of the CPU-heavy tasks until someone actually requests some random data, but still..

PS: Some other popular entropy sources are seek time for mechanical hard-disks and audio input devices.

Mon Aug 30, 2021 8:24 pm

а если получать случайные числа прочтением некоторого участка памяти и производя например рандомные бинарные операции (рандом для этого находим в другом месте например количество принятых пакетов по сети)

Mon Aug 30, 2021 8:51 pm

Doczom: What you propose is considered unsafe for security purposes, because it is deterministic.

CSRNG

Who is online