WP_Term Object
(
    [term_id] => 14
    [name] => Synopsys
    [slug] => synopsys
    [term_group] => 0
    [term_taxonomy_id] => 14
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 696
    [filter] => raw
    [cat_ID] => 14
    [category_count] => 696
    [category_description] => 
    [cat_name] => Synopsys
    [category_nicename] => synopsys
    [category_parent] => 157
)
            
800x100 Efficient and Robust Memory Verification
WP_Term Object
(
    [term_id] => 14
    [name] => Synopsys
    [slug] => synopsys
    [term_group] => 0
    [term_taxonomy_id] => 14
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 696
    [filter] => raw
    [cat_ID] => 14
    [category_count] => 696
    [category_description] => 
    [cat_name] => Synopsys
    [category_nicename] => synopsys
    [category_parent] => 157
)

True Random Number Generation

True Random Number Generation
by Bernard Murphy on 01-27-2016 at 4:00 pm

Random numbers are central to modern security systems. The humble password, perhaps the  least profound application, is encrypted and verified against using SHA or MD algorithms with a random number salt. You probably remember a college class on how to generate pseudo-random numbers algorithmically, some very sophisticated. But most of these techniques have been consigned to the trashcan of crypto-history because they simply aren’t random enough (survivors live on in low-security applications).

Why is not-random-enough a problem? Because it means that your random numbers are distributed over a much smaller state-space than you think, and therefore brute-force guessing is much more likely to succeed when using a powerful machine and reasonable assumptions about likely seeds (time of day for example). Worse yet, our intuition on what is truly random seems to be quite weak, so our attempts to correct for biases are typically much less effective than we think.

The hardware engineer in us jumps next to what we think are high-entropy sources on-chip: shot noise, process variations amplified through ring oscillators and so on. These are good starting points but preserving randomness in conversion to a number (or stream of numbers) requires a lot of care to not re-introduce bias. Is the distribution really uniform, or does digitization introduce bias? Worse yet, are you using a source which seems like it should be random but may instead be quite predictable, such as the power-up state of a RAM?

And then there are other factors you need to consider. Can the operation of the generator be observed through a side-channel attack (observing power consumption or timing or EM radiation)? There are even sophisticated statistical methods to learn behavior profiles of how a function behaves, especially under environment changes, without needing to understand why it behaves that way, and these can be used to hack the device.

There’s a huge amount of subtlety to getting this right and a lot of standards to which you will need to show compliance if you want to be taken seriously: NIST SP 800- 22 and SP 800-90 and (FIPS) 140-2. This is a domain for experts only. Enjoy trying to understand all the complexity but build your designs around professional True Random Number Generators (TRNGs).
You can learn more about the Synopsys TRNG IPs HERE.

More articles by Bernard…

Share this post via:

Comments

0 Replies to “True Random Number Generation”

You must register or log in to view/post comments.