I’m sorry for the the dumb questions, but I haven’t any knowledge on this argument.
My embedded platform doesn’t have a true entropy source. I think the best I can do is using non-volatile memory as the entropy source.
The application needs random numbers for several things: TCP/IP lwip stack (DNS, DHCP, local TCP port, …), TLS connection, another module that lets a user to pair securily to the device.
Now my first question. Must the entropy (I mean the entropy context) be unique in all the application and shared among all the modules that need random numbers? What are the drawbacks to have two entropy contexts?
altcp_tls_mbedtls is an adaptation layer between lwip TCP/IP stack and mbedTLS libraries. This layer defines and manages already an entropy and a crt_dbrg context. In order to have a single entropy in the application, I have to patch this lwip module.
The second question is about crt_dbrg context to generate random numbers. Is it possible to have multiple random generators in the application that share the same entropy context? Is it better to have a single generator for the application?
Having two different entropies should not have issues, as long as the entropy itself is different and unique between the two contexts, except for additional unneeded resources.
I would suggest you read this article for additional information.
Note that using two contextx with same entropy ( e.g. NV seed ), will result in same “random” vectors, as the ctr_drbg is deterministic according to the seed.
Yes, you can have several ctr_drbg context, however you should be able to protect the NV seed read \ write , in order to have different seeds.
The link I referenced should help you on this matter as well. This article may interest you as well.
However, if you port in the NV seed in the TLS library, as mentioned in the article, you shouldn’t patch your lwip module, if it uses Mbed TLS.
Am I missing something?
lwip allocates, initializes and manages a single entropy and a single random genertor for all TLS connections. It’s usually ok.
However in my case some other modules in the application need random numbers. I think it’s better to have a single entropy context and management for all the modules in the application (that is implemented as a superloop without an OS support).
This is the main reason I need to patch lwip, in order to cut and move entropy management to another “global” module that offers the entropy service to all the modules that need random numbers.
