Writing to /dev/random or /dev/urandom will update the entropy pool with the data written,
but this will not result in a higher entropy count. This means that it will impact the contents
read from both files, but it will not make reads from /dev/random faster.
I assume that the PRNG will just use this to reseed and I suppose that a high quality random number generator would have a positive impact on security.
My question is whether it is a good practice to use Nitrokey as a source of randomness before consuming /dev/urandom.
If that does not work, I guess, one would need a driver to add this source of entropy to the pool.
You can feed the kernel’s /dev/random device like that. Though, it does get reseeded every minute. So, you’d have to do it constantly and that likely is not practical with a low-power usb device. Consider some entropy is permanently needed, e.g. for disk encryption, network encryption, javascript online poker, etc etc.
Another point is that a “positive effect” is arbitrary, because you cannot mathematically prove to enhance or weaken the regular entropy pool. It is a fair point to say the noise of the NXP chip has to meet its certification standards, yet do these enhance on anything the kernel uses? The noise source can theoretically be very similar. I don’t know what the NXP chip uses, I suspect it is jitter from memory io. Do you know?
Taken together, I think the Nitrokey as random source can be very useful in environments where you cannot control how the kernel is configured. For example, imagine you have to generate a new gpg key on a Windows client, or a virtual/hypervised/multiuser/vmware host. You could then perhaps feed the Nitrokey’s entropy into ~/.gnupg/random_seed to make gpg avoid a source you don’t know.
In my opinion the chip is designed to perform its core functionality, i.e. produce the entropy needed to generate on-chip crypto secrets. It’s not designed to enhance or speed up TLS handshakes of your computer. It’s cool that it exposes a random source to tap, but I believe that feature is stipulated by the NIST standard - probably to enable running formal statistical tests.
