How to get a random seed for a random number generator? - Page 1
Forum section: electronics / general

author: Connecteur
author_rank: Frequent Contributor
timestamp: June 29, 2025, 03:18:42 pm
content: The problem I have is that any time I want to produce a pseudorandom number, I need to use a seed number. I can enter it manually by making one up, but I want to make it autonomous. Is there a way to pull a random number from somewhere that won't generate the same sequence of numbers each time? I'm thinking that something could be done with the time intervals between keystrokes.

author: nctnico
author_rank: Super Contributor
timestamp: June 29, 2025, 03:25:52 pm
content: Use the time if you have a clock. Otherwise a few ADC samples are a good source of noise.

author: TimFox
author_rank: Super Contributor
timestamp: June 29, 2025, 03:50:20 pm
content: How many bits/digits do you require for the seed?

author: hexreader
author_rank: Frequent Contributor
timestamp: June 29, 2025, 04:05:14 pm
content: Response removed

author: Connecteur
author_rank: Frequent Contributor
timestamp: June 29, 2025, 04:25:07 pm
content: Quote from: TimFox on June 29, 2025, 03:50:20 pmWhy does that matter?

author: TimFox
author_rank: Super Contributor
timestamp: June 29, 2025, 04:26:50 pm
content: Quote from: Connecteur on June 29, 2025, 04:25:07 pmSo, 1 bit would work?If not, then 2?It’s a fair question.

author: Connecteur
author_rank: Frequent Contributor
timestamp: June 29, 2025, 04:27:49 pm
content: I read somewhere that slot machines receive a secret seed number from some central server each day. Is this BS or what? Surely they wouldn't need to do that. A seed number can be obtained when someone first touches a button.

author: voltsandjolts
author_rank: Unknown
timestamp: June 29, 2025, 04:29:08 pm
content: https://medium.com/@dheeptuck/how-to-generate-true-random-numbers-in-a-microcontroller-b0c65903ae84https://www.eevblog.com/forum/microcontrollers/resolving-contention-create-a-uniquerandom-sequence-from-a-96-bit-id/

author: artag
author_rank: Super Contributor
timestamp: June 29, 2025, 05:13:30 pm
content: https://xkcd.com/221/

author: TimFox
author_rank: Super Contributor
timestamp: June 29, 2025, 05:26:02 pm
content: 3 bits, then.

author: Connecteur
author_rank: Frequent Contributor
timestamp: June 29, 2025, 05:30:33 pm
content: I don't think it does matter,one bit, heh.

author: TimFox
author_rank: Super Contributor
timestamp: June 29, 2025, 06:18:54 pm
content: Two choices.

author: bson
author_rank: Unknown
timestamp: June 29, 2025, 07:19:53 pm
content: Just read the LSB of an ADC set to a high sampling rate. Obviously if you need 256 bits you just repeat this 256 times. It's probably fine for "soft" cryptographic uses, meaning it's likely not that hard to defeat with access to the hardware, but for most uses it's probably sufficiently unpredictable. E.g. creating a TLS session secret. With access to the hardware it's easy to ground the ADC pin. It might be possible to not route the ADC input to a pin in a microcontroller and still collect samples, but I'm not sure how random they would be. Should be easy to test - just collect a few hundred thousand 10-bit numbers and plot a histogram to eyeball. Calculate the std dev and see if it's close to what should be expected.

author: ejeffrey
author_rank: Super Contributor
timestamp: June 29, 2025, 07:22:50 pm
content: Quote from: TimFox on June 29, 2025, 04:26:50 pmIf you can get one bit, presumably you can get more by just doing it again. It might be slow, but you can collect as much randomness as you want.The question is not how many bits are needed, but how "random" does it need to be. Something like time stamps is enough to avoid repeating the same sequence every startup but it's very predictable. Random noise in an ADC is generally unpredictable but could be subject to deliberate interference. A lot of physical randomness sources can be biased so some outcomes are much more likely than others. If you need a uniform distribution you will need to run a debiasing algorithm first.

author: bson
author_rank: Unknown
timestamp: June 29, 2025, 07:29:56 pm
content: If you already have reasonable randomness from one source, like an ADC, then there's no point adding another source like an RTC. It doesn't become more random by doing so, and it's easier to just collect more from the former.

author: ejeffrey
author_rank: Super Contributor
timestamp: June 29, 2025, 07:37:02 pm
content: Quote from: Connecteur on June 29, 2025, 04:27:49 pmI'm not sure how they work, but:A) casinos would never willngly put the randomness in the literal hands of the player. There are a few traditional table games like craps where the players throw the dice but I can't imagine them doing that on an electronic machine.andB) the gambling machines need to not just be random they need to be auditable to make sure they are playing fair.

author: MK14
author_rank: Super Contributor
timestamp: June 29, 2025, 08:06:11 pm
content: Quote from: hexreader on June 29, 2025, 04:05:14 pmGoing back to your original post (IIRC) and if you are still following this thread. The Z80, had an R register (refresh counter), which could be used as a sort of true random number generator.As its 7 bits, gets incremented, each dram refresh cycle (approximately).Best to access the R register, where the timing will be relatively random rather than deterministic, such as where you suggested previously, the keystroke has just been received section of the program.Most modern processors these days have built in true random number generators. Such as Intel/AMDs, RDRAND and the improved RDSEED, instructions.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: June 29, 2025, 09:13:50 pm
content: Quote from: Connecteur on June 29, 2025, 03:18:42 pmYou have not said what you are running on ?Anything analog can be used as a seed.That can be time between strokes, or key bounce noise, or an ADC or if you have a MCU with multiple oscillators, you can measure the frequency ratio.Or you could add a RC to a pin, and time that, using a deliberately 'poor' choice of cap that has wide voltage and temperature variations.

author: Nominal Animal
author_rank: Super Contributor
timestamp: June 29, 2025, 10:22:23 pm
content: All you need is a large enough monotonically increasing counter. Apply a few rounds of e.g. Xorshift64*, and use the 32 high bits as the seed.For example, if you want a 64-bit seed, and you have a 32- to 64-bit unique ID for the MCU, and a boot counter or timer of some kind, apply a few rounds of a suitable hash or PRNG function to each, then combine them (using either addition or exclusive-or), and finally apply a few rounds of the same hash or PRNG function.I like to use Xorshift64* as my PRNG. It has 64 bits of state, and all states except zero are valid. Of the output, I only use 32 to 40 high bits. This sequence passes basically all randomness tests, so is "better" than e.g. the industry standard, Mersenne Twister 19937. There are other similarly good generators, some based on linear shift register like Xorshift, some on linear congruence likePCG. This one is just my preference on 32-bit and 64-bit architectures with fast bit shifts and 32/64-bit multiplication, based on my particular needs. Yours likely differ.Each round onuint64_t statewith Xorshift64* isstate ^= state >> 12;state ^= state << 25;state ^= state >> 27;and therefore very, very fast. The above three lines are repeated in a loop a few to a few dozen times to convert a counter to a pseudorandom seed.Ifstatewas nonzero, it will be nonzero after the above three steps too; only zero will yield zero. This is why zerostateis not allowed.To use the state as an output valueuint32_t result, you doresult = (state * UINT64_C(2685821657736338717)) >> 32;which mixes the state bits into the result, then discards all but the most significant 32 bits.If you need 64 bits, do the above four lines twice, and combine the results. Or, you can generate a 64-bit nonzero seed asstate, and use it as your PRNG, generating 32 random bits per each invocation of the four lines above.How good is this scheme? Good enough to be used in scientific simulations.Is this scheme secure? It is notcryptographically secure, no. For that, we'd need to apply a cryptographic hash function onresultand use its results instead, so that even if someone obtains a relatively long sequence of consecutive (cryptographically hashed) generated values, they cannot infer or predict the value ofstate. This is onlyrandom, in the sense that if someone does any kind of analysis on a sequence of consecutive generated values, they cannot tell from the output if it is generated by this algorithm or from a physically random source like whitened diode avalanche noise.

author: rf-fil
author_rank: Regular Contributor
timestamp: June 30, 2025, 12:07:56 am
content: If you are using an MCU, and can choose which one, just pick a type with a built-in true hardware based RNG.Otherwise, there are Lava lamps, ADC LSBs, reverse biased zener diodes, drifty clocks, etc..

author: Psi
author_rank: Super Contributor
timestamp: June 30, 2025, 12:21:08 am
content: I don't know what you intended use is. but consider if you actually want a random number. Sometimes people think they want a random number but don't. They want something that 'looks' random, but sometimes in order to get that you have to make it not random.eg. Truly random number generation will sometimes give you the same number 2,3,4.. times in a row which isn't always what you want depending on application.

author: Nominal Animal
author_rank: Super Contributor
timestamp: June 30, 2025, 01:25:02 am
content: If you do not have a counter you can use at MCU startup, but have an unused input pin, you can use an external oscillator circuit. I'd also use an output pin to disable the external oscillator when no longer needed. The external oscillator does not need to have 50% duty cycle, but the shorter state duration should be long enough for your code to sample it at least a dozen times.The idea is that you write a loop that counts the cycles (or number of samples) the external oscillator output stays in the same state. If this is sufficiently long compared to the sampling interval, the least significant bit of the count depends on the jitter and frequency drift between the two external oscillator and the MCU clock.To get a 64-bit seed, you sample the durations of the high and low states over 32 consecutive cycles, and use the least significant bit of each count.The simplest logic-level oscillator I'd use is a simple Schmitt inverter oscillator, followed by another inverter whose output is read by the MCU. Thus, you only need a dual Schmitt trigger inverter with output logic levels compatible with your MCU, one resistor, and one capacitor. I'd prefer a frequency above 40 kHz, just to ensure no audible whine; say between 40 kHz and 200 kHz. The resistor and capacitor values depend on the rising and falling trigger voltages, though.For the high-side switch (to control VCC to the inverters), a logic-level P-channel MOSFET like BSS84, DMP3125L, or NX3008 should do the job fine.If you don't have any GPIO pins left, you need to find some other randomness source. For keypresses, and other similarly low-frequency events, you can use the least significant bit of some high-resolution timer, essentially doingseed= (seed<< 1) | (timer& 1);and not using it before the most significant bit ofseedis set. The randomness is then based on the jitter in the event timing at the scale of the timer tick duration. The base logic is the same as with the external oscillator.

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 30, 2025, 01:51:07 am
content: Apparently still without context, the thread can go on like this for weeks.Since the OP talked about keystrokes, one can at least guess that he's considering a system with somes keys. Who knows.Many modern MCUs have some kind of TRNG peripheral. Use that if it's there.If on a typical desktop computer, in C, the classic way of seeding the pseudorandom generator is to seed it with time(NULL). The probability of getting twice the exact same value right when this call executes is pretty low, so unless it's a critical cryptographic application, it's usually good enough.Otherwise, there are all the methods suggested earlier, and more.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: June 30, 2025, 10:04:43 am
content: Quote from: SiliconWizard on June 30, 2025, 01:51:07 amThat's what often happens if OP refuses to give a simple answer to a direct (and relevant) question. Apparently he's living in is own (smallish) bubble. I have very little motivation to contribute to such a thread.

author: peter-h
author_rank: Super Contributor
timestamp: June 30, 2025, 11:46:08 am
content: Exactly.However, I've done this many times. The requirement tends to be one of two- To ensure that two boxes don't do the same thing at the same time. In this case implement a product S/N and use either that or some CRC or hash of it. Or even the S/N directly, loaded into a timer, etc.- For some crypto related purpose. In this case you need to do it properly. But also in most cases of an embedded IOT device, the need for strong crypto is illusory because by the time somebody is attacking this, they are already inside your box - because they bought one

author: iMo
author_rank: Super Contributor
timestamp: June 30, 2025, 11:55:25 am
content: This will give you a random seed (at least 5bit) via ADC input - a zener and 2 transistors..

author: MK14
author_rank: Super Contributor
timestamp: June 30, 2025, 11:58:46 am
content: Quote from: Connecteur on June 29, 2025, 04:27:49 pmThat might be because the laws of some countries, need such features. So that they can keep careful checks, on the true randomness of slot machines. So that the owners/operators of the slot machines, DON'T mess around with the randomness, in order to increase their profits and rip off the users (customers).Although slot machines are usually carefully designed to have rather precisely controlled, average payouts. So that they can make specific profit (percentage) levels, in the longer term.

author: Nominal Animal
author_rank: Super Contributor
timestamp: June 30, 2025, 12:03:35 pm
content: Quote from: iMo on June 30, 2025, 11:55:25 amWouldn't it be better to swap the resistor and Zener, R1 and Z1, so that you get more of the avalanche (current) noise instead of the voltage noise?

author: jpanhalt
author_rank: Super Contributor
timestamp: June 30, 2025, 12:07:17 pm
content: Quote from: Connecteur on June 29, 2025, 03:18:42 pmWould it be possible for the TS to tell us how he is generating the sequence of pseudo-random numbers. The fact that the same seed gives the same sequence is suspicious. For one thing, are numbers repeated within that sequence?

author: iMo
author_rank: Super Contributor
timestamp: June 30, 2025, 12:13:24 pm
content: Quote from: Nominal Animal on June 30, 2025, 12:03:35 pmYep, there are many variants, as you wrote, also with reverse biased base-emitter as the source, etc, etc.OP shall simply search for "noise generator avalanche" or "noise generator zener" and he gets dozens of pictures with wirings..

author: jpanhalt
author_rank: Super Contributor
timestamp: June 30, 2025, 01:31:10 pm
content: If you can generate a pretty good random seed, why do you need to process it again with an inferior algorithm?

author: SteveThackery
author_rank: Super Contributor
timestamp: June 30, 2025, 01:35:03 pm
content: Quote from: jpanhalt on June 30, 2025, 12:07:17 pmIsn't that what always happens?

author: peter-h
author_rank: Super Contributor
timestamp: June 30, 2025, 01:36:24 pm
content: If you have an ADC, why not build a properly working oscillator, either sinewave (but those have problems maintaining amplitude unless you have feedback) or an astable square wave one followed by a 2nd order passive filter to produce a sort of sinewave, and sample this at some frequency not related to the oscillator frequency. Then do a CRC on the resulting ADC values, say the last 10 of them, and the result is going to be as random as anybody can tell. And it will work reliably, not relying on transistor gains, etc.

author: jpanhalt
author_rank: Super Contributor
timestamp: June 30, 2025, 01:36:47 pm
content: @SteveTI don't know about "always" but we may have cross-posted. John

author: Nominal Animal
author_rank: Super Contributor
timestamp: June 30, 2025, 02:00:58 pm
content: Quote from: jpanhalt on June 30, 2025, 01:31:10 pmTo clarify this for others:A good pseudo-random number generatorseedis one that does not repeat. The seed itself does not need to be random.This is why a monotonically increasing startup counter is perfectly good seed for good PRNGs like Xorshift variants and PCG, especially if you discard the first few generated values. For Xorshift64*, using only the 32 to 40 most significant bits of each 64-bit result after multiplicative mixing, discarding a dozen or so states suffices.If you have an inferior algorithm that has both "strong" and "weak" seeds, the situation is different. For Xorshift family and many other linear shift register PRNGs, all seeds except zero are valid, and produce equally random sequences.With cryptographically secure pseudo-random number generators the situation is somewhat different, because we assume that an attacker can obtain a sequence of outputs, knows the algorithm used, and can therefore find out the initial seed used (at least by brute force, testing all candidate seed values). Then, the seed itself needs to be cryptographically secure random number.In any case, if you do cryptography, you better have a reliable hardware random number or entropy source. I myself am experimenting with Microchip ATECC608B ICs, which are a cheap and secure way to offload the hard parts (connection handshaking, key storage and verification), and they have not only an internal secure RNG, but also two high-endurance 72-bit counters and other goodies, eliminating the entire problem posed in the title. Mouser sells these for about 0.80€ apiece in singles, so they're quite affordable too. A good option if you have I²C available on your MCU. Even the I²C address can be changed (exactly once).

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 30, 2025, 02:30:04 pm
content: Quote from: jpanhalt on June 30, 2025, 01:31:10 pmI suppose that you are wondering why not use what generates this seed as the random generator itself.There are two reasons: one, the way you get a non-repeating seed (that's all that really matters here) may not make a good pseudorandom sequence. For instance, if you use some kind of timer, even if at the time you get its value *once* as a seed, the probability of having twice the same seed could be very low, the sequence a timer generates is monotonic, so not appropriate for any kind of decent pseudorandom sequence.A second reason is that of throughput: if you use a reasonably good "random" source, such as something based on electronic noise, sure, you may use it directly as your "random" generator with better results than just seeding a pseudorandom generator, but it can be relatively slow. So when needing high throughput, it's a relatively common approach to seed a pseudorandom generator (which can be extremely fast) from a noise source.

author: nctnico
author_rank: Super Contributor
timestamp: June 30, 2025, 03:49:58 pm
content: Quote from: SteveThackery on June 30, 2025, 01:35:03 pmI agree. Numeric random number generators always provide the same sequence. So you'll need a random seed to make the random generator truly random (if that is required *). Another requirement for a random number generator is an even distribution. If you take 10000 random numbers from 1 to 10, each number should pop up the same number of times. So from the 10000 numbers, you should end up with 1000 times a 1.* For testing purposes I like to use a random generator which produces the same sequence for each test run. That way I know that when a test failed at a certain iteration, the problem got fixed when it doesn't fail at that point.

author: Connecteur
author_rank: Frequent Contributor
timestamp: June 30, 2025, 04:51:59 pm
content: A pseudorandom number may not repeat, but it's not good enough for my purposes.I need a truly random seed to prevent the same sequence of numbers from being produced each time the device is turned on.I had a windows based casino application back in the 80s. The same spots would always hit on the roulette board, because it generated the same numbers each time. A truly random seed should produce a truly random number.

author: TimFox
author_rank: Super Contributor
timestamp: June 30, 2025, 05:02:56 pm
content: As pointed out above, you want anon-repeatingseed, not necessarily a random seed.That's why I asked about the size of the seed you require, to which you replied insincerely.A two-bit seed will repeat often.

author: Nominal Animal
author_rank: Super Contributor
timestamp: June 30, 2025, 05:03:56 pm
content: Quote from: Connecteur on June 30, 2025, 04:51:59 pmNo. You do not need arandomseed. You need a seed that changes each time the device is turned on, and does not repeat. A sufficiently large turn-on counter would work absolutely fine as a seed if you use a good PRNG, especially so if different devices are flashed with different initial counter values.If you use a poor PRNG, then "whiten" the counter value with dozen or two cycles of Xorshift64* shifting before using it as a seed, at which point it is also statistically random.

author: jpanhalt
author_rank: Super Contributor
timestamp: June 30, 2025, 05:38:18 pm
content: Quote from: Connecteur on June 30, 2025, 04:51:59 pm1) Then, why not just use the seed?2) It depends on how you use it and how your pseudorandom number operates. In typical use of an LFSR (at least the ones I used), just one instance of each value to the limit of bits used is generated. That is not random. If you are really good at counting cards/numbers your probably of guessing the next value increases with each value produced. That's why "card counters" get banned permanently from casinos in Las Vegas, USA when they get caught.

author: jpanhalt
author_rank: Super Contributor
timestamp: June 30, 2025, 05:42:50 pm
content: Quote from: nctnico on June 30, 2025, 03:49:58 pmI just use a counter and test every value with my math routines. A pseudo-random, repetitive sequence probably add little to that.

author: Connecteur
author_rank: Frequent Contributor
timestamp: June 30, 2025, 05:56:34 pm
content: Quote from: TimFox on June 30, 2025, 05:02:56 pmI don't know where you got lost, but I can't help you get back.

author: TimFox
author_rank: Super Contributor
timestamp: June 30, 2025, 06:11:22 pm
content: Quote from: Connecteur on June 30, 2025, 05:56:34 pmThat makes even less sense than your first reply to me.

author: nctnico
author_rank: Super Contributor
timestamp: June 30, 2025, 06:16:44 pm
content: Quote from: jpanhalt on June 30, 2025, 05:42:50 pmIf you are testing more complex software / systems which also communicate to third party systems, connects with a databases, etc a much better test is one which also simulates a variable system load. Using a pseudo random interval between starting transactions helps a lot. When developing such systems, a typical way of testing is to get it working OK with 1000 transactions, 10k transaction, 100k transactions, 1M transactions and then 10M transactions. At every step you'll typically find new problems.

author: jpanhalt
author_rank: Super Contributor
timestamp: June 30, 2025, 06:44:41 pm
content: I'm just simple Simon and am happy when my BCD math routines work.

author: Nominal Animal
author_rank: Super Contributor
timestamp: June 30, 2025, 08:13:46 pm
content: Quote from: jpanhalt on June 30, 2025, 05:38:18 pmThat is why I do recommend MSBs-only Xorshift64*. The period is 2⁶⁴-1 = 18,446,744,073,709,551,615, and each 32-bit result is generated 2³² = 4,294,967,296 times (except zero one fewer times) during the full period. The sequences pass all statistical tests (even the couple that MT19937 fails), all valid seeds yield good subsequences, and only seed 0 is invalid (among 64-bit unsigned integers). No "weak" seeds. Plus it is ridiculously fast.It is a very good starting point if one has used the horrible LGCs that the standard C libraries'rand()and similar are. They're so horrible because of historical compatibility reasons. When they were initially written, we didn't know enough of PRNGs and related math yet, you see. Even Numerical Recipes used to have one or two horrible suggestions for a LCG PRNG. The related math has evolved a LOT, even if programming languages haven't kept up.When you have more experience with these, you can examine and experiment with other Xorshift/Xorwow/etc. LFSR PRNGs, and good LGCs likePCG family, expanding your pseudo-random toolkit so you can pick the most suitable tool for each task at hand.I like to tell about this one because it is so simple that you're unlikely to mess it up (just don't fiddle with the shift constants!), ridiculously efficient/fast, and if only the 32 to 40 most significant bits of each 64-bit multiply-mixed result is used, passes all statistical randomness tests we have that most other PRNGs do fail at (at least one or two sub-tests).At its simplest:Code:// SPDX-License-Identifier: CC0-1.0 (Public Domain dedication)#include <stdint.h>static volatile uint64_t prng_state; // Any seed value except 0 is good!uint32_t prng_u32(void) {uint64_t tmp = prng_state;tmp ^= tmp >> 12;tmp ^= tmp << 25;tmp ^= tmp >> 27;prng_state = tmp;return (tmp * UINT64_C(2685821657736338717)) >> 32;}// Related function that does not use prng_state, but the supplied state instead:uint64_t prng_advance(uint64_t state, uint_fast16_t count) {while (count-->0) {state ^= state >> 12;state ^= state << 25;state ^= state >> 27;}// Add output whitening step, like in Xorshift64*.return (state * UINT64_C(2685821657736338717));}which works just fine if you initializeprng_stateto a simple nonzero counter at startup, like the number of times the device has been started up.Theprng_advance()is a 64-bit "whitening" function you can use to generate 64-bit nonzero seeds for other PRNGs. You supply it with a nonzero 64-bit unsigned integer, and the number of iterations; a dozen suffices, a hundred is silly overkill. The result is the same as using that state for a Xorshift64*, then generating that many pseudorandom numbers, and returning the last full 64-bit one. If you do useprng_u32(), you don't needprng_advance()at all, because even a boot counter will work fine as an initialprng_statevalue. Just make sure you never set it to zero, for example usingprng_state += !prng_state;after setting it. It will never become zero on its own, only if you explicitly set it to zero, or if you implemented the functions wrong.If you have multiple devices, and they have an at least 32-bit unique nonzeroidentifier, and some kind of boot counter, then usingprng_state = prng_advance(prng_advance(identifier,16) + prng_advance(counter, 16), 16);gives you a seed that is both nonrepeating and random. It is utter overkill for MSB-only Xorshift64* as shown above, but works well if you want to seed some other PRNG.If you have a real-time clock, then you can seed the MSB-only Xorshift64* usingprng_state = prng_advance(YYYYMMDDhhmmss, 1);, whereYYYYMMDDhhmmssis either the number of seconds since the RTC epoch, or the unsigned 64-bit decimal number obtained by multiplying years by 10,000,000,000, months by 100,000,000, days by 1,000,000, hours (in 24h clock) by 10,000, minutes by 100, and adding all those and seconds together. Or some other similar non-repeating calculation based on time in seconds.You can use the above identifier-like mixing steps with small counts (down to one is just fine), if you have a MAC or other unique identifier that you want to mix in, so that two devices won't generate the same sequences at the same time.I cannot stress enough howstatistically randomthe values this generates are. Just because it is ridiculously simple and fast, does not make it at all weak. To repeat, it is statistically stronger and thus "better" than even Mersenne Twister, which fails one or two statistical randomness tests that this sequence passes.I find it regrettable that developers generally aren't familiar with this.

author: jpanhalt
author_rank: Super Contributor
timestamp: June 30, 2025, 08:16:39 pm
content: I don't do C, bit that does not look too hard to convert of PIC-ASM. Thanks. John

author: Siwastaja
author_rank: Super Contributor
timestamp: July 01, 2025, 06:35:38 am
content: Nowadays most new microcontrollers have "true random number" generator peripherals, which are basically well-engineered noise sources. Use those if available instead of rolling your own. If they are specified for uniform distribution, you can also use it directly (for every number you need) instead of as a seed for pseudo-RNG, but that might, as SiliconWizard pointed out, have a significant performance penalty. These peripherals have some quite low throughput.If the pseudo-RNG sequence is truly good, then seeding it with a random number - or even just unique, like Nominal Animal points out! - works, and the output sequence is as good as it would be if every number was generated with perfect true random number generator. Good pseudo-RNGs can still be computationally lightweight, so this combines good sides of both. And you can do as nctnico suggests, use fixed seed for debug/test to generate repeatable sequence.

author: cv007
author_rank: Frequent Contributor
timestamp: July 01, 2025, 09:29:02 am
content: An mcu has ram that is 'random' when powered on. There are bits that tend to start up in a particular state, but there are enough that do not have a preference so you cannot predict their power up state.There is plenty of uninitialized ram available to come up with a seed, so it can even be done after startup where data/bss is initialized. From the top of the stack down to where data/bss end you can pick out as many bytes/words as you wish and do something like xor a small/large handful. There will be enough ram bits that were 'random' on power up to make the resulting seed random enough for uses where true random wasn't necessary.I use this for 'random'-https://www.analog.com/en/resources/design-notes/random-number-generation-using-lfsr.htmlwhere it generates a 16 bit value so for 32bit it needs to assemble two 16bit 'random' values. I used to run through uninitialized ram to create the starting point for the two vars, but now I just create the two vars in .noinit section so on power uo they are random enough for my use (and even if not, doesn't really matter), and any reset will keep using the same vars so the lfsr continues on from where it was.edit- I should add that these vars have to be checked for 0.

author: felixd
author_rank: Regular Contributor
timestamp: July 01, 2025, 09:32:29 am
content: Check that project:https://github.com/waywardgeek/infnoise

author: 5U4GB
author_rank: Super Contributor
timestamp: July 01, 2025, 12:38:24 pm
content: Quote from: Connecteur on June 29, 2025, 04:27:49 pmSlot machines operate under an extremely strict regulatory regime where, for example, the payout has to be set at a certain verifiable level. So it's not so much "where does the entropy come from" but "has this device been certified to work as required". Any technical details are very tightly guarded so no-one can try and exploit them, but in general there's no one magic approach to doing it.

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 01, 2025, 03:16:18 pm
content: Quote from: felixd on July 01, 2025, 09:32:29 amIt is a very interesting analog voltage multiplier approach, somewhat analogous to a SAR ADC, indeed.The authors did leave out one attack/problem scenario: an external source inducing an AC/pulsed voltage in VREF (the reference voltage used for the analog comparator) or the analog signal voltage at point A (or across capacitor C8), perhaps by drawing current from VCC in a specific pattern. If that is possible, it would determine the output states in the corresponding regular pattern. It is much harder to detect that than e.g. the Zener noise voltage going out of expected bounds, which is the risk scenario described for those; and also why I like the idea of reading the Zener noise output using an ADC that covers the entire expected range (so that if 0 or maximum is obtained, it is detected as an error), and only using the least significant bit of each ADC reading.I am only a hobbyist on the electronics side, and shielding/grounding is my weakest point, so I do not know if these are realistic fears at all.When constructed as shown in the schematics, the circuit runs on 3.3V generated by the FT240XQ from USB 5V, and this is the only thing it does, so none of those fears apply to the full schematic; only if one adapts the right side part of it for ones own use. (It is licensed under CC0-1.0, so we're explicitly allowed to do that.)Using a separate linear regulator for the noise circuit rather than sharing it with the MCU might be a good solution.I am personally not worried about somebody attacking the device physically (since it is easier to just replace the output signal pins with a fake one that generates a known pseudorandom sequence instead), but it happening by accident, due to e.g. a borderline USB supply having sufficient ripple/AC component to "overpower" the analog noise, or other work done on the MCU causing sufficient current draw and VCC swing to affect the comparator output.The external oscillator scheme I outlined inreply #21is robust against most attacks/risks, because it derives the randomness (entropy) from the frequency drift and jitter between the MCU clock and the external oscillator frequency. It is several orders of magnitude slower, though. A successful attack would require the external oscillator to be synchronized to the MCU clock. It is easy to ensure that does not happen, by using a separate linear regulator to the external oscillator, decoupling it from the MCU (except for the single data line output to the MCU via a Schmitt trigger inverter), and the two having over an order of magnitude difference in their frequencies. Plus, I would only use it at startup and maybe occasionally later on (say, at resets or similar), to generate a 64-bit nonzero random seed for 32-MSB-only Xorshift64* or one of PCG variants, when no "client work" is done on the MCU.

author: bson
author_rank: Unknown
timestamp: July 03, 2025, 08:51:46 pm
content: Quote from: peter-h on June 30, 2025, 11:46:08 amAh, yes, "die number seniority" - oldest die wins...

author: kjellkt
author_rank: Newbie
timestamp: July 21, 2025, 02:00:32 pm
content: I recently needed a completely random seed (and fairly good randomness) on a project. To solve that I gathered one raw measurement for each ADC channel (I had 8 external measurements on my board and 2 internal measurements) and stored them all into a buffer. Then I calculated a 32-bit CRC of that buffer. This 32 bit CRC was my random number for various purposes. Since I needed more than 32 bits of random values, I repeated the process multiple times to get enough random values.I also tried this code on a devkit (in a low noise environment) where none of the 8 external measurements was connected to anything (just floating), and it also consistently provided random values every time. All channels was varying some few ADC counts randomly every time and the 32-bit checksum was always completely different. So this seems to be a feasible approach when a proper hardware random number generator isn't available, but an ADC is.

author: radiolistener
author_rank: Super Contributor
timestamp: July 21, 2025, 08:19:34 pm
content: I'd be cautious relying on ADC noise for randomness, especially for security purposes. The problem is that ADC results, even with noise, are fundamentally limited in entropy - each reading gives you only a few noisy bits (often just 1-2 effective noisy bits), and in low-noise environments, the possible outcomes become even more constrained and potentially predictable with brute-force modeling.CRC helps mix bits but doesn't add entropy. The CRC result is as predictable as the inputs.A better alternative (when no true hardware RNG is available) is to measure timing jitter between two asynchronous clocks, for example, capture the period of a pulse generated from one clock using a counter running on a different clock source. Since clocks are independent, their phase jitter introduces true physical randomness. You can use the least significant bits of measured intervals as noise.Gathering a sequence of such jitter-based measurements gives you real entropy, which can be mixed and then used to seed a xorshift or other PRNG to generate high-quality random numbers.Typically, microcontrollers include an internal RC oscillator and at least one external crystal oscillator (sometimes even two or more). This allows you to exploit the natural asynchrony between these independent clock sources as a source of physical randomness.

author: SteveThackery
author_rank: Super Contributor
timestamp: July 21, 2025, 10:36:41 pm
content: Quote from: radiolistener on July 21, 2025, 08:19:34 pmSo, couldn't you repeatedly read those couple of bits and keep left-shifting them until you've filled up your 32-bit seed (or whatever)? Would that not be a suitably random seed?This is a genuine question, not a suggestion. 😁

author: radiolistener
author_rank: Super Contributor
timestamp: July 21, 2025, 11:05:54 pm
content: Repeatedly reading a few bits from the ADC and shifting them into a seed is theoretically possible, however, due to the limited entropy in each measurement, the overall randomness will be low. Moreover, predictable or low-amplitude noise in the ADC often causes strong correlations between bits, which significantly reduces the quality of the resulting seed. It may appear that the values are random, but they typically exhibit a certain dependence on the input signal.

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 21, 2025, 11:27:26 pm
content: Quote from: SteveThackery on July 21, 2025, 10:36:41 pmYes, asbson suggested in reply #12already. Often, a longer sequence of the bits is used, and checked for randomness, and oftenwhitened(to distribute the bits and make ones and zeros equally probable; taking the CRC of the sequence is one method, cryptographic hashes considered the "best", and applying a few rounds of a suitable PRNG a fast-but-good middle ground).As to measuring the drift between two oscillators (one the MCU clock, the other an external oscillator, like a Schmitt inverter one), I already outlined that inreply #21.As noted many times before in this thread, a seeddoes not need to be random; it suffices that it does notrepeat. The seed simply picks the starting point of the HUGE sequence good PRNGs generate. For good pseudo-random number generators, the entire sequence is good, so all valid seeds are good.

author: radiolistener
author_rank: Super Contributor
timestamp: July 22, 2025, 12:25:41 am
content: Quote from: Nominal Animal on July 21, 2025, 11:27:26 pmJust to clarify, the statement that a seed "does not need to be random, only unique" mainly applies when you don’t need to protect against attackers who might predict or reproduce the sequence. If cryptographic security or resistance to attacks is a concern, the seed must have sufficient entropy and unpredictability. However, for many general applications where security is not critical, your approach relying on uniqueness rather than true randomness is suitable.

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 22, 2025, 02:22:55 am
content: Quote from: radiolistener on July 22, 2025, 12:25:41 amYes, exactly as I said inreply #18, and expanded on inreply #34already.In the latter, I also already noted that for cryptographic uses we have dedicated chips likeMicrochip ATECC608B(including a cryptographically secureNIST SP 800-90A/B/CPRNG), which Mouser sells in singles forunder 0.80€ apiece. Crypto is one of the easiest things to fuck up, you see.

author: Psi
author_rank: Super Contributor
timestamp: July 22, 2025, 02:43:47 am
content: There's often multiple items connected to the ADC internally that you can combine to get more noise bits.eg, multiple bandgap voltage references, a CPU temp sensor.Sometimes you can get ADC access to the configurable resistor ladder connected to the MCU comparator input. There's lots of individual resistors (ladder settings) you can measure to get more noise bits since the resistors values will have some error from one mcu to another (Obviously depending if the MCU in question gives you ADC access to it).You can also make the noise floor higher if you output a fast square wave (or random pwm) on any GPIO that is internally powered by the same VCC pin as the ADC. Or just set one of the unused ADC inputs to digital output and use that etc.. Is it really adding more noise, or just superimposing the waveform on the adc readings, your free to argue about it

author: JoeyG
author_rank: Regular Contributor
timestamp: July 22, 2025, 02:56:51 am
content: add an I2C random number generatorhttps://www.microchip.com/en-us/product/rng90Data sheethttps://ww1.microchip.com/downloads/aemDocuments/documents/SCBU/ProductDocuments/DataSheets/RNG90-CryptoAuthentication-Data-Sheet-DS40002499.pdfLibraryhttps://microchiptech.github.io/cryptoauthlib/

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 22, 2025, 01:39:16 pm
content: Quote from: JoeyG on July 22, 2025, 02:56:51 amNice device - cryptographic level, a 72-bit unique number, very low consumption, and inexpensive (for what it is).

author: peter-h
author_rank: Super Contributor
timestamp: July 23, 2025, 08:58:46 am
content: Another chip which will sink your company if we again get covid type hoardingI wonder how they "prove" their randomness? What is it they are doing which you can't knock up with some zener or whatever noise source, an amplifier, perhaps with AGC, and ADC?The main criticism of DYI solutions seems to be the lack of provable entropy. Now if you could get say 10independent12-bit ADC readings of good noise, and do a hash, that should do it.

author: John Coloccia
author_rank: Super Contributor
timestamp: July 24, 2025, 03:24:39 am
content: Quote from: peter-h on July 23, 2025, 08:58:46 amIt tells you right in the datasheet the standards and test criteria they use.

author: ejeffrey
author_rank: Super Contributor
timestamp: July 24, 2025, 04:12:03 am
content: Quote from: peter-h on July 23, 2025, 08:58:46 amEasy way to avoid that is to never design anything interesting or useful. Otherwise definitely do supply chain evaluation, but if you have a requirement for a secure random number generator definitely consider chips like this.QuoteRead the data sheet. It doesn't specify the physical mechanism of the entropy source itself, Presumably it's some kind of shot noise junction source with an ADC. But that's just the first part. The physical random source is then sent to a determenistic hashing function to remove bias, and the system has been characterized to make sure it is producing enough entropy. If you request a random number before it's produced enough entropy the request stalls. It also has some level of tamper detection.QuoteSure. You just have to do the work to characterize it. Across temperature, voltage, and process variations. And make sure you are using the hash function correctly. It's not really difficult. I actually built one in grad school using a high speed avalanche photodiode for very high speed random generation. But getting it all right isn't trivial either and if if a $.40 part will do the job why wouldn't you?That said, there are some downsides to any device like this. It's tamper resistance claims probably need to be taken a bit skeptically. Sure the device itself might be reasonably tamper resistant, but as a discrete chip it's going to be vulnerable to board level spoofing. So you have to imagine using it in a device which is physical secure but an adversary could mess with the temperature or voltage or something. Plausible but microcontrollers and SoCs designed for secure applications usually have random number generators built in, and much better protected. It's also not super fast, so some applications will need use this to seed a cryptographic PRNG. But for $.40 i'd say its still a really good deal if it works for your application.

author: peter-h
author_rank: Super Contributor
timestamp: July 24, 2025, 05:37:23 am
content: Yes, exactly, you could just emulate it on the board. Cut the tracks and put in something else.Admittedly there are applications where the attacker cannot get hold of the product; then it's OK.Tamper protection is difficult. Many years ago I was sort of involved in that. Various weird methods are used e.g. wrapping the board in fine wire (a break of this wipes the keys) and encapsulating in glass. Maybe the smartcard chips are better now but historically they were not fully trusted. AFAIK cash dispensers still contain such a module.

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 24, 2025, 08:22:58 am
content: All useful security solutions boil down totrust.As an example, I don't like the idea of relying on an external IC for cryptographically secure RNG, because it splits my "trust zone" between the MCU and an external IC. In comparison, an external chip that contains the cryptographically secure RNG, secure key storage, and key exchange/authentication algorithm implementations, fully comprises my "trust zone", so that is absolutely fine for me: that way I outsource the entire "trust zone" to a large vendor like Microchip.I consider the security implications of each possible combination ofbroken trust, systematically, in each possible combination of broken "zone", to find out the ways the system can be subverted/exploited. It is a lot of rote examination, and there is always the temptation ofassumingsomething, but for me, the key is to switch to "nefarious thinking mode", as if my life depended on being able to exploit the system itself. If you've ever enjoyed role playing games, you know what I mean.

author: DiTBho
author_rank: Super Contributor
timestamp: July 24, 2025, 11:22:23 am
content: Quote from: Nominal Animal on July 24, 2025, 08:22:58 amumm I am not sure about this, a few "secure chips" which integrated everything (so, good for securing everything from fw-boot up), showed more weaknesses than solutions in which the CPU executes the algorithms, and the external chip simply stores the keys and provides entropy.Not sure

author: DiTBho
author_rank: Super Contributor
timestamp: July 24, 2025, 11:30:06 am
content: But if you think about it... take the old PowerBook G4 Titanium (~2001) for example... it was possible to use the FireWire port on the back of the laptop to write code into the RAM or dump the RAM content.This is a significant hardware flaw. Essentially, it's similar to DMA without any protection. The CPU in this case can't do anything; its access to the bus is physically blocked in "high impedance" when the FireWire port initiates its read/write cycles, and an external Fw-device can act as bus master.A terrible idea, in this case

author: peter-h
author_rank: Super Contributor
timestamp: July 24, 2025, 01:09:00 pm
content: It's the same debate as distributing encrypted firmware updates.If you assume that the attacker can buy one of your boxes, you can't actually do it, unless the decryption and flash programming is wholly internal to the chipandthe chip is secure from the "chip whispering" attacks which seem to be effective against almost all MCUs. IMHO we must assume all "classic" MCUs can be hacked in this way.Having any sort of smartcard security chip in your box doesn't work. All those chips must be for where- the attacker cannot obtain your product, or- your product is physically tamperproof

author: DiTBho
author_rank: Super Contributor
timestamp: July 24, 2025, 02:34:38 pm
content: The good old days, when Nintendo secured QA-approved NES cartridges with a custom 4-bit chip...QA meant that only high-quality, Nintendo-approved games could run on the NES! This solution was arrived at after several software houses had attempted in the early days to market junk games that risked damaging the reputation of Nintendo's playground!So they created a pair of chips. One chip on the motherboard, one chip on the cartridge!If the motherboard chip didn't read the correct "nible" sequence from the cartridge chip, it forced the console into a perpetual reset.Hackers tried dissolving the chip in acid and reading the ROM and some clues, and it turned out to be a Motorola chip because their logo was in a corner of the die, but it wasn't one of the catalog ones, like the 68HC11 or 68xx; the 63xxx wasn't available and, even then, was too expensive. It was later discovered that the chip was Motorola, but the CPU design was from another company; Motorola had only produced the chip.The algorithm was not clear, and it took 20 years to decode it.Oddly enough, the only existing clone capable of running a non-Nintendo-approved cartridge game was the "Rabbit" chip, a solution based on early PICs, created not through hacking but through a legal exploit!And since we're talking about highly sophisticated solutions... that solution has been around for a good 30 years ...

author: Siwastaja
author_rank: Super Contributor
timestamp: July 24, 2025, 03:09:07 pm
content: Quote from: DiTBho on July 24, 2025, 02:34:38 pmTo be fair, "unlicensed" games were commonplace, so there clearly were workarounds. I had "Action 52" for NES as a kid, for example. I do remember how it sometimes looped in reset cycles for a variable number of times, and sometimes took quite long (possibly requiring power cycling, I don't remember) to get running, so their reverse-engineered solution against this DRM clearly was... flaky.Many of these games were done with shoestring budget with obviously serious lack of skill in programming, so probably they did not have super geniuses reverse-engineering the "security" chip either, so it probably wasn't very difficult to circumvent after all. Action 52 for example, AFAIK, was developed by total amateur trainees within a few months, and that is very apparent from the end-result which was horrible enough to become some sort of cult thing.

author: radiolistener
author_rank: Super Contributor
timestamp: July 25, 2025, 01:34:21 am
content: Quote from: Nominal Animal on July 22, 2025, 02:22:55 amQuote from: Nominal Animal on July 24, 2025, 08:22:58 amAs far as I know, the NIST SP 800-90A/B/C standards include support for Dual_EC_DRBG - a generator that was shown to contain a backdoor, allegedly introduced by the NSA. For example seeDual EC: A Standardized Back Door - Daniel J. Bernstein, Tanja Lange, Ruben NiederhagenIf the presence of a government-inserted backdoor isn’t a critical concern for your application, then using such chips can still be a practical choice. However, I believe it's important to be mindful of the historical context and carefully consider the level of trust placed in external cryptographic components.

author: peter-h
author_rank: Super Contributor
timestamp: July 25, 2025, 07:15:39 am
content: Very interesting reading, but what kind of embedded product is going to be attacked in this way?In most cases the attacker canbuyit, usually for peanuts, and take it apart.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 25, 2025, 07:38:13 am
content: Quote from: peter-h on July 25, 2025, 07:15:39 amYou should indeed assume that: the product can be freely accessed, any MCU flash protections bypassed, and program disassembled and investigated. Sometimes this is trivially easy, sometimes it takes skill and effort, but is eventually doable in 99.99% cases, even if designer was certain theirs would be different.Therefore, "security by obscurity" only works if your product is uninteresting and niche; it can buy you some time. But your security solution should be solid enough that one can't find bugs (the sort of allowing bypassing authentications) in it even with disassembling the program; any authentication/encryption should be then based on unique keys so that getting the key out of the device only sacrifices that device, not other customers.If you need to protect against the case of attacker physically modifying a device and returning it to service (or swapping devices), then it's going to be very hard to protect against that.

author: peter-h
author_rank: Super Contributor
timestamp: July 25, 2025, 08:20:52 am
content: If the device is an httpsclientthen it doesn't need to store any private keys.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 25, 2025, 09:00:09 am
content: Quote from: peter-h on July 25, 2025, 08:20:52 amI don't understand how you could authenticate a device without any private key. Of course, if you don't need to authenticate, then no problem.

author: peter-h
author_rank: Super Contributor
timestamp: July 25, 2025, 09:20:28 am
content: I am trying to work out a scenario where one of these "secure storage" chips are useful.I guess the one you mention is one, where some sequence of numbers is stored in that chip, and the server knows the sequence. Or a challenge-response. Then, the fact that an attacker can monitor (or tamper with) the data retrieved from the said chip, doesn't matter.Just like those banking keypads

author: John Coloccia
author_rank: Super Contributor
timestamp: July 25, 2025, 04:20:10 pm
content: Quote from: peter-h on July 25, 2025, 09:20:28 amConsumable/accessory authentication, for example, preventing counterfeit.With a chip on both devices, it's very easy to do a diversified key challenge.

author: TimFox
author_rank: Super Contributor
timestamp: July 25, 2025, 05:47:30 pm
content: The President of the US always carries a key-thing to respond to the challenge from the Pentagon when he orders a nuclear strike through the “football” communications device carried by an aide.

author: John Coloccia
author_rank: Super Contributor
timestamp: July 25, 2025, 05:59:32 pm
content: Quote from: Siwastaja on July 25, 2025, 09:00:09 amBy definition, https requires the server to store a private/public key (i.e. your certificate). You don't need any MORE keys than that, but that is the minimum that's required to accept a connection. The client uses the public key to initiate negotiation/creation of the symmetric key for the actual session. So the client doesn't need to store anything.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 25, 2025, 06:42:39 pm
content: Quote from: John Coloccia on July 25, 2025, 05:59:32 pmSo, no client authentication in this. One can be added "on top" e.g. by password, two-factor authentication etc. For embedded devices that just need to work, that is often not practical. If you then need authentication, a private key, from which a certificate is signed, is obvious.It is difficult to have a generic discussion about security, because every application is different. Some need just encryption for the session; some need authentication; some need automatic authentication; some can ask for password plus send an SMS for 2FA, and so on.

author: peter-h
author_rank: Super Contributor
timestamp: July 25, 2025, 06:48:28 pm
content: QuoteThe client however needs to have the root certificate(s) file - cacert.pem is the usual name. The box I've done has a daily task to keep this updated. It's about 250k and we modded MbedTLS to not need 256k RAM (which is a dumb shortcoming of MbedTLS)QuoteBut that bit will then be open to attack because it needs to be stored inside the client. Even if you keep it in a fancy secure chip. AIUI.Maybe one could store something in the secure chip which uniquely identifies the client, as a part of the challenge-response. That means a) production programming this token and b) the server keeps a list of all boxes you sold. That would also guard against somebody swapping the chip for the same device from mouser.comActually this "server keeps track of..." issue is the same as one might do for OTA firmware updates. If a customer of yours has bought 10k or 100k of your box, you don't want them all to get brickedIt's another debate (done in another thread) but it does involve unique client authentication.

author: John Coloccia
author_rank: Super Contributor
timestamp: July 25, 2025, 08:00:45 pm
content: Quote from: peter-h on July 25, 2025, 06:48:28 pmThis is what the diversified key challenge/response is meant to address.the server/consumer (you have a small number of these)1) has a master encryption keythe consumable/client/whatever (you have a lot of these)1) has a "diversified key" created by encrypting publicly known information (like my serial number) with the master keyGenerally, no one has access to these keys, not even the device itself. You can't retrieve, but you CAN ask them to perform operations.To authenticate:client -> server: here's my serial numberserver calculates diversified key (internal in the chip...completely inaccessible and unknowable)server -> client: here's a random challenge....encrypt it with your diversified key, and tell me what you gotserver: also encrypts the challenge with the calculated diversified keyserver takes client response and asks the chip "does this response match what you calculated?"If they match, I know the thing I'm talking to is authentic because it proved that it's diversified key was encrypted with my master key.You don't NEED these fancy chips to do this, but the chips guarantee:1) the keys are absolutely inaccessible by anyone2) the intermediate calculations are also inaccessible, other than than one true, correct challenge the client does, so no chance of leaking anythingWithout the hardware, you have to be very careful of memory/debugger attacks, how you store the keys, etc

author: radiolistener
author_rank: Super Contributor
timestamp: July 25, 2025, 10:05:53 pm
content: Quote from: John Coloccia on July 25, 2025, 05:59:32 pmIt's actually a bit more complex than just needing a single key on the server. HTTPS involves several layers of encryption and key usage. Yes, the server has to store a private key, but there are also temporary session keys generated during each connection, and in mutual TLS, the client must also have its own private key and certificate and needs to store it in safe storage.More importantly, for a client to trust a server’s certificate, it relies on a set of trusted Certificate Authorities (CA) - which are private companies. These companies hold special signing keys that validate certificates. The issue is that governments and intelligence agencies have access to, or cooperate with, these CA. That means they can, if needed, issue fake certificates that appear completely legitimate to the client. This allows them to impersonate any server and silently intercept HTTPS traffic without triggering any warnings.The TLS protocol that underpins HTTPS is, in principle, capable of establishing secure and well-protected communication channels. It offers flexibility through a variety of handshake modes, key exchange mechanisms, and encryption algorithms, many of which provide strong cryptographic assurances when properly configured. However, there are notable weaknesses - for example, the Client Hello message in a standard TLS handshake includes sensitive metadata (such as the Server Name Indication and supported cipher suites) that is sent in plaintext. This unencrypted information can be used for traffic analysis, surveillance, or censorship - even without access to any private keys. Emerging solutions, such as Encrypted Client Hello (ECH), aim to mitigate this by encrypting that handshake metadata, but adoption is still limited.However, in practice, the situation is more constrained. Most real-world deployments rely on a limited set of standardized cipher suites and default configurations. More critically, authentication of the remote endpoint almost always depends on the Public Key Infrastructure (PKI) model - specifically, on trusted CA to validate certificates.This reliance on a small number of commercial CA introduces a significant structural vulnerability. If any trusted CA is compromised or coerced - it becomes possible to issue fraudulent certificates that appear fully legitimate to clients. As a result, despite the theoretical strength of TLS itself, the overall security of HTTPS is only as strong as the integrity and trustworthiness of the CA ecosystem - which has historically proven to be a weak point.So, while HTTPS gives strong protection in theory, in practice it depends on a global chain of trust - and that trust can be compromised by a small number of powerful actors.Beyond concerns related to cipher suite selection, reliance on CA, and the exposure of metadata in the unencrypted Client Hello, there are also indirect vulnerabilities that affect TLS security. One notable example is implementation fingerprinting: different TLS libraries and clients often produce subtly different handshake sequences, message structures, and extension usage patterns. These differences can be used to fingerprint specific implementations (for example JA3 fingerprint), allowing observers to infer client or server identity, application type, or even the nature of encrypted traffic - despite strong cryptographic parameters, proper use of ephemeral keys, and minimal reliance on CA-based trust. This side-channel exposure underscores the fact that secure protocol design alone is insufficient.

author: 5U4GB
author_rank: Super Contributor
timestamp: July 26, 2025, 02:44:47 am
content: Quote from: peter-h on July 25, 2025, 09:20:28 amDRM. Years ago we were trying to figure out WTF you were supposed to do with the ATECC chips, i.e. what was the thinking behind the feature set in there, and how could you possibly use it as a GP crypto chip. An external guy who happened to be there for lunch said they were originally designed to DRM laser printer cartridges, at which point the architecture suddenly made sense. The vendors have become a lot more open about it since then, documenting their use as "IP protection" and "authenticate disposable goods" (meaning ensure you can't drop in a $5 replacement for the same thing that costs $200 once it has the vendors name on it) and similar. Others, e.g. the TI ones, are there to DRM battery packs, same reason.Same with TPMs, peddled as "secure crypto chips" or whatever but their entire functionality is for DRM. Oh, and storing a single Bitlocker key, because you may as well use them for something to make them seem useful.

author: peter-h
author_rank: Super Contributor
timestamp: July 26, 2025, 07:01:38 am
content: OK, but surely if this chip is in the toner cartridge, the printer CPU will have code in it which will interrogate it. So somebody must be assuming that the printer firmware is secure, too.In practice this will work because almost nobody will spend time working out how to re-flash the printer CPU...QuoteIt is also possible for someone to break into your house and hack your web browser's root certificate store...

author: Nominal Animal
author_rank: Super Contributor
timestamp: July 26, 2025, 07:17:05 am
content: Quote from: 5U4GB on July 26, 2025, 02:44:47 amYes, but one that the end user controls. Think IoT devices, microcontrollers with sensors and displays, network-connected to your own servers. No need for "cloud", can expose the devices to internet access without an edge relay, with just a simple firewall. Stuff where physical access defeats security anyway.The ones I use have no preinstalled keys or certificates, so are completely under user/systems integrator (that would be me) control.Remember: I personally do not do commercial devices at all, I only do hobbyist end-user-truly-owns-it stuff.(I probably should have emphasized it earlier, because many views here are from people who create commercial devices, and those have a different security risk model. I am only interested in having local user full control and block external threats, whereas commercial providers must juggle control and security balance between themselves and end users, plus protect the product itself too.)(Woohoo! My 7777'th post!)

author: John Coloccia
author_rank: Super Contributor
timestamp: July 26, 2025, 07:27:42 am
content: I do medical devices. We worry about things like unsafe counterfeits getting into the supply chain. Also unauthorized things, like calibration.The FDA has very much started focusing quite seriously on cybersevurity, and other threats. These chips are very useful and really make an almost impossible (or at least EXTREMELY difficult to get perfectl} problem quite simple.