[top_darjeeling] RNG integration

[tjaychen]

desc

If an RNG source already contains health checks and conditioning functions, how should it be integrated? There are two options

1. Keep the RNG source as it is now and conform to AST's entropy interface. Configure entropy_src to bypass both its conditioner and its health checks. We can consider adding parameters to move these options out, or keep them as a just in case. This has the benefit of keeping the definition of the "entropy complex" consistent, while simply allowing the external RNG capability to change.

2. Allow the RNG source to replace entropy_src completely. This means instead of having entropy_src -> csrng -> edn, we would instead have rng source -> csrng -> edn. This changes the structure somewhat but removes the redundant definition. To pursue this option we would need another DV model that emulates the behavior of the new rng / entropy_src.

[tjaychen]

@martin-lueker @mwbranstad @cdgori @moidx

[martin-lueker]

Hi @tjaychen, Either one of these options is probably fine, though if the route of 2 is chosen it could require a thin adapter layer.
A security review would be required in the case of 1 to make sure that all these features can be turned off (or mandated to stay on in the former case where health tests are still needed). Also in case 1 it should be noted that leaving all these features on, but unused is not very practical in terms of area efficiency. One last point to keep in mind: For FIPS certification, the CSRNG requires that the RNG satisfies the conditions for "full entropy" meaning that it almost certainly requires the use of an internal conditioner approved by SP 800-90B.

[tjaychen]

thanks @martin-lueker! yes regarding area, we were thinking we either keep in just in case (as a backup) or we add some parameters to allow the functionality to be stubbed out. We haven't really settled on one decision or another, so wanted some general feedback.

I was originally thinking of keeping the entropy_src there in a "thin way", and just allowing a parameter to say whether the upstream source already has health checks and conditioning. That way we keep the entropy pipeline / complex "looking" the same. However I can also definitely understand if we prefer the top level approach as well.

@andreaskurth @vogelpi

[andreaskurth]

Should we also take the blind trust risk into account? As in, if the RNG source with integrated health checks and conditioning functions is not open source, one has to blindly trust the conditioning and health checks it implements. Would that be OT-compliant? If not, it may be worth doing the health checks again in entropy_src, but I don't know if the conditioning can be checked?

[martin-lueker]

Should we also take the blind trust risk into account? As in, if the RNG source with integrated health checks and conditioning functions is not open source, one has to blindly trust the conditioning and health checks it implements. Would that be OT-compliant? If not, it may be worth doing the health checks again in entropy_src, but I don't know if the conditioning can be checked?

It's an interesting question, but if we only have access to the conditioned data the tests will be not that meaningful. We would need access to the the raw data, and information about how much entropy per raw bit we are supposed to be expecting in order to set appropriate thresholds. SP 800-90B requires the tests be performed on the raw data, as once it is conditioned, the entropy is hopefully so close to ideal that no health check could detect any statistical anomalies.