[Cryptography] Duh, why aren't most embedded TRNGs designed this way?

Arnold Reinhold agr at me.com
Sun May 16 17:25:54 EDT 2021



> On May 15, 2021, at 9:31 PM, Ron Garret <ron at flownet.com> wrote:
> 
> 
> On May 14, 2021, at 1:02 PM, Arnold Reinhold via cryptography <cryptography at metzdowd.com <mailto:cryptography at metzdowd.com>> wrote:
> 
>> 
>> 
>>> On May 13, 2021, at 11:48 AM, Ron Garret <ron at flownet.com <mailto:ron at flownet.com>> wrote:
>>> 
>>> 
>>> On May 5, 2021, at 10:00 AM, Arnold Reinhold via cryptography <cryptography at metzdowd.com <mailto:cryptography at metzdowd.com>> wrote:
>>> 
...
>>> Theoretically what you say is true.  But as a practical matter it is largely irrelevant because good sources of entropy are ubiquitous nowadays. Make an audio recording of yourself making pretty much any sound (saying “hisssssss” would be particularly effective) for a few seconds and you will have all the entropy you need for even the most demanding application.  You don’t need to understand the details of how your audio system works to be able to rely on it.  All you need is to be able to verify that the recording you get bears some resemblance to the sound you made in order to produce it (to verify that it is working at all).
>>> 
>>> The hard part is not finding good sources of entropy.  The hard part is protecting that source against tempest attacks and other forms of eavesdropping.
>>> 
>> 
>> There are plenty of situations where entropy is required and there is no microphone nor camera (my favorite) nor other analog input and no human to hiss into a microphone if there is one. I believe this thread started as a discussion of TRNGs embedded in microprocessors and SOCs.  When they are present, it is likely that many developers will rely on them, even though there may be alternatives. Hence it is important to get them designed well and to provide ways to assure that all been done properly and there are no shenanigans. It can’t be said often enough, random number generation is a silent, single point of failure for cryptographic systems.
> 
> Yes, I agree with all that, but I don’t see why it’s relevant.  Either you trust your hardware supplier or you don’t.  Either way, the physical details of the TRNG don’t matter, at least not to you.  You should hope that they matter to your supplier, and maybe you’ll want to inquire about them as part of your vetting process, but again, at the end of the day it all still comes down to trust.  It would be easier for you to build your own TRNG from raw materials than to verify that the story that your hardware supplier told you about the TRNG you bought from them is actually true.
> 
> By way of very stark contrast, it is borderline trivial to verify that a recording you made of yourself bears some resemblance to the sounds that you recorded and so with very high probability contains a certain minimal level of entropy per unit time.  You don’t have to trust anyone to implement that strategy.  IMHO that is the overriding consideration.
> 


We seem to be talking past each other. Your model seems to be a knowledgeable user trying to secure a personal computer. My model is building secure systems that can be used by anyone or even in situations where there is no human involved.

I agree that modern personal computers have lots of potential sources of entropy (though one major source, rotating memory, has largely gone away), but even there some care is needed. You better protect that audio file, for example.

In my model, your first comment "Either you trust your hardware supplier or you don’t.” begs the question. One first has to select a hardware supplier. Normal engineering practice is to get data sheets explaining how components work. Since random number generation is so critical, exactly that is done might be a major basis for processor selection. So lack of clear TRNG design specs is a problem. In addition, for any mission critical system one would like to check that a supplier's product works as advertised, ideally on a periodic basis during operations. Post-whitening in hardware with no direct access to generated bits, which US and EU guidelines seem to demand, prevents such verification. 

Arnold Reinhold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210516/dc718c35/attachment.htm>


More information about the cryptography mailing list