6
\$\begingroup\$

We always like to reset registers in a synchronous digital circuit just after power up so they are in a known state before device operation begins.

Pseudo random number sequences make use of a seed value. The rest of the sequence generated by the generator then relies on this seed value in a predictable way.

Is it a good idea (say in FPGA or some other device) to use the initial state of group of registers (that are never reset) as the seed value in pseudo random number sequence?

\$\endgroup\$
2
  • 5
    \$\begingroup\$ Not if you have any real need for randomness. \$\endgroup\$ Jul 27, 2020 at 22:55
  • \$\begingroup\$ @ChrisStratton Not quite true. Search 'PUF-TRNG'. \$\endgroup\$
    – Paul Uszak
    Dec 17, 2020 at 15:06

4 Answers 4

12
\$\begingroup\$

Though the imbalance of transistor conductivity, and the imbalance of metal_metal capacitance and metal_active capacitance, and imbalance of load capacitance, are what determine the powerup "state", these imbalances are very consistent. You will not get much randomness.

That is bad.

If you want to explore randomness, then design a clocked Comparator that initially resides in Metastability, and disrupt the Metastability with random noise from a broadband amplifier, and then CLOCK the Comparator from Track mode into Hold mode.

\$\endgroup\$
4
  • \$\begingroup\$ I see, I now understand why I did not see this being used anywhere yet. \$\endgroup\$ Jul 27, 2020 at 23:05
  • 3
    \$\begingroup\$ please don't gratuitously toss around concepts like metastability when they aren't needed, it confuses people. \$\endgroup\$
    – Neil_UK
    Jul 28, 2020 at 5:04
  • 3
    \$\begingroup\$ @Neil_UK Au contraire, this gives me a fresh cue for research :) \$\endgroup\$
    – orithena
    Jul 28, 2020 at 9:30
  • 1
    \$\begingroup\$ Anyone wanting to use this method as an RNG for actual applications, please de-bias your results. The whole metastable comparator also gives a lot less randomness than this answer implies. Then again, if you didn't know that, you probably shouldn't be designing your own random generators. \$\endgroup\$
    – DonFusili
    Dec 17, 2020 at 15:35
6
\$\begingroup\$

It depends what you want to use the random numbers for.

If you want numbers that are not certain to be the same each run, then use the power-up state of registers. You will find that many runs will in fact be the same, but without the certainty that a power-on reset gives you.

If you want numbers that are very likely to be different each time, then you need to go another way. Even though registers are designed to be nominally symmetrical, and you can't predict before testing any particular chip which way each of its registers is going to power up, the accidental asymmetries of line size, capacitance to ground, transistor width, resistance etc etc that they are manufactured with, will mean that you are likely to get the same power-up state essentially every time.

There are various other ways to get good randomness.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ I use LabView to create very long random numbers, but hexadecimal is more dense, and base64 is more dense per 'n' characters. Base85 is most dense but LabView, Python and javascript do not treat it the same way. Normally I use base64. \$\endgroup\$
    – user105652
    Jul 28, 2020 at 7:15
  • 1
    \$\begingroup\$ @VTNCaGNtdDVNalUy Decimal, hexadecimal, base64...none of this matters. The flip flops are always binary. \$\endgroup\$ Jul 28, 2020 at 23:34
0
\$\begingroup\$

Yes if you make the leap, register = RAM. As:-

pufkey

There is a common (now) technique of using indeterminate S/D/RAM start up states or transitions (meta-stability) as a seed source for cryptographically secure pseudo random number generators (CSPRNGs). They're usually associated with a physical unclonable function (PUF) used in security/authentication applications. In essence they're physical circuits that are impossible to replicate exactly due to non deterministic behaviour.

It's pretty deep, but have a look at An Overview of DRAM-Based Security Primitives, specifically §2.2.2. Random Number Generators. You can them trawl the links to TRNGs. Or PUFKEY: A High-Security and High-Throughput Hardware True Random Number Generator for Sensor Networks, which is the source of my image above.Or Design of True Random Numbers Generators with Ternary Physical Unclonable Functions.

\$\endgroup\$
0
\$\begingroup\$

You basically reinvented FPGA PUFs. As other answers already mentioned, this is a really bad source of randomness.

How bad?

Bad enough that the consistency of the results you get here is used to uniquely identify FPGAs.

Don't use this for any serious cryptographic key generation. In fact, as with everything cryptography related: if you think you found a new solution to one of the problems related to anything in cryptography, you're probably wrong and should let experts break it for a few years before you actually use it.

If you need randomness to make your post-covid disco-light party that little bit more geeky, this is an ideal solution, though.

\$\endgroup\$
5
  • \$\begingroup\$ Are you sure? author line1 et al do not instil confidence really. See my links above. The non-determinism that creates a PUF is exactly that which creates the TRNGs. It's just a different implementation and the other curve on the Hamming distance chart. \$\endgroup\$
    – Paul Uszak
    Dec 26, 2020 at 16:44
  • \$\begingroup\$ @PaulUszak The first half of my master's dissertation was identifying FPGA's by their "random" RAM content and we reached >80% accuracy across >50 devices with the same product code, so yes, I'm sure. But I'm not going to link my real life dissertation to my SE account, so I'm fine with people not believing this. I'll remove the link though, because I can't say that I've read this specific article in detail. \$\endgroup\$
    – DonFusili
    Dec 28, 2020 at 7:52
  • \$\begingroup\$ What grade did you get? No, but really, what about the other 20% and the reason for the fuzzy extractors/training data that you no doubt covered? \$\endgroup\$
    – Paul Uszak
    Dec 28, 2020 at 21:13
  • \$\begingroup\$ @PaulUszak What?... Mate, my grades were perfectly fine. If 80% accuracy where you'd expect less than 2% with random initialization makes you ask "What about the other 20%", you're simply not arguing in good faith. Go ahead and use RAM PUFs for random values in the stuff you design, but there are way better extraction methods of environment noise. \$\endgroup\$
    – DonFusili
    Dec 29, 2020 at 7:51
  • \$\begingroup\$ @PaulUszak Anyway, what we did was make a single design that filled all the block RAMs in an FPGA, read them all out a bunch of times and during testing we just read the same data out and "guessed" the one that had the training measurement with the smallest Levenshtein distance to the measured block. The fact that you don't even need fuzzy extractors should tell you enough about how shitty the whole system is. No idea if it works for every FPGA, but for me it's enough that it worked for a single device family to discredit the idea. \$\endgroup\$
    – DonFusili
    Dec 29, 2020 at 8:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.