3 ms·

It's clear that a lot of thought went into this write-up, but this is not a design that I would use or recommend. (Because you probably don't anything about me

by kwantam 10y ago

It's clear that a lot of thought went into this write-up, but this is not a design that I would use or recommend. (Because you probably don't anything about me: I have background in both circuit design and applied crypto, and I have published research on hardware random number generators. I'm not saying this to bully you into believing me, but rather to give you some motivation to think critically.) The main problem is that the noise sources are implicit: the designer has no control over the spectrum or the relative magnitude of the various noise sources, and there's no attempt at rejecting power supply ripple or RF disturbances. (The claim that "it naturally defends against influence from outside signals" is not substantiated, and as I argue below, there is a strong possibility that it is false.) It's also worrisome that the author doesn't bother to distinguish between "noise" in the technical sense and "noise" in the some-arbitrary-signal sense (e.g., power supply ripple). Only the former has useful statistical properties. The latter is useless at best, and an attack vector at worst. As an concrete example of what worries me: this is a discrete time, positive feedback loop. We are presented with evidence that it has a mode of operation in which its output looks random. Critically, this does not eliminate the possibility that it has another mode that's essentially a limit cycle. My intuition tells me there's a very good possibility that if the output of the circuit has a heavy enough capacitive load, and the circuit's power supply is sufficiently high impedance, the whole thing would lock up into a steady-state oscillation. This is related to the analog design adage: oscillators don't, everything else does :) So what's the "right" approach (at least, in my opinion)? First, simplicity: fewer moving parts means there's less that can go wrong. Second, pick an explicit noise source; the best choice is a diode in avalanche breakdown (this is sometimes conflated with Zener breakdown; they're different phenomena, and avalanche is louder). Avalanche generates enough noise that it requires very little amplification, and unlike thermal noise, avalanche is quite insensitive to temperature. Third, make it insensitive to external influences by design: shield it from RF, take special care to ensure power supply insensitivity, etc. Fourth, run wellness tests whenever you sample from the RNG. Intel's procedures are a good example [1]. Finally, a lot of other comments in this thread have covered this, but under standard cryptographic assumptions there is no reason to run this RNG continuously. Sample a few thousand bits, hash them into a key, and use AES-256 as your PRNG. For a really nice take on randomness mythbusting, see "Recommendations for randomness in the operating system" by Corrigan-Gibbs and Jana [2]. [1] http://www.rambus.com/wp-content/uploads/2015/08/Intel_TRNG_Report_20120312.pdf http://www.rambus.com/wp-content/uploads/2015/08/Intel_TRNG_... [2] https://www.henrycg.com/pubs/hotos15recommendations/ https://www.henrycg.com/pubs/hotos15recommendations/

nickpsecurity 10y ago
Interesting write-up. I get really, mixed reviews on all these analog designs from various EE's. So, what do you think about BitBabbler's analysis and design while you're at it? http://www.bitbabbler.org/how.html http://www.bitbabbler.org/how.html EDIT: Now I know the name. Interesting to run into a person whose team independently invented a verifiable ASIC strategy very similar to my own of a year or so ago. I learned digital at a high-level, generalist way of thinking with no hands-on ability and definitely no analog. So, I have to work at that level. Started learning risk areas from insiders like this [1]. My initial strategy enumerated problem space to tackle it head on [2]. Yet, I switched gears to follow how provers work: combine untrusted EDA tools and main CPU's with traces produced for trusted, verification tools on inspectable CPU's. Similar to what I did for high-assurance, guard designs at protocol level without formal methods. I determined by maybe Jan2015 based on my Schneier.com posts that trusted ASIC's should be 0.35 micron or above because they're still visually inspectable. If ever funded, I'd modify VAMP CPU to be more like SAFE or CHERI to do the job. If too hard to do visual on, I'd start with a Forth or JOP-like processor before that. Even considered FM9001 & Piton haha. Also, replicating computation on diverse, fast CPU's from various vendors, fabs, and countries with optical communication & EMSEC isolation. The old, diverse, voter scheme I did pre-silicon for things like build systems. Anyway, props on being ahead of me in implementation and more impressive design in general. Great work. That we converged on similar approach means it's probably worth me putting more effort into among the many ideas I'm juggling. I still gotta learn analog and hands-on formal methods, though, before I can do something like yours or provably solve the analog portion. (sighs) My gut has been telling me since I studied TEMPEST and RobertT's analog subversions that the solution will have strong analog component past diverse review of gates and such I was leaning on. [1] https://www.schneier.com/blog/archives/2013/09/surreptitiously.html#c1744173 https://www.schneier.com/blog/archives/2013/09/surreptitious... [2] https://news.ycombinator.com/item?id=10468624 https://news.ycombinator.com/item?id=10468624
- kwantam 10y ago
  So, what do you think about BitBabbler's analysis and design while you're at it? The problem with BitBabbler is that they have a lot of text but, as far as I can tell, no circuit diagrams and no real discussion of what they're doing. It may just be that their wall of text makes me go cross-eyed, but my snakeoil detector goes off whenever I start reading their web page. For example, the talk about sample-and-hold circuits as "analog shift registers" and worrying about quantization seems slightly unhinged (for one, if you need more resolution, just use a bigger sampling cap). Apologies to the BitBabbler people if they're on the up-and-up, but a page that talks about auditability and verifiability but doesn't show a schematic seems slightly dishonest. (Sorry... rant mode off.) Thanks for the kind words regarding verifiable ASICs! You are absolutely right that there's a ton of complexity to worry about here. But I sincerely hope that the world makes more headway on this problem, so I'm really glad you're thinking about it.

by kwantam 10y ago

nickpsecurity 10y ago

Interesting write-up. I get really, mixed reviews on all these analog designs from various EE's. So, what do you think about BitBabbler's analysis and design while you're at it? http://www.bitbabbler.org/how.html http://www.bitbabbler.org/how.html EDIT: Now I know the name. Interesting to run into a person whose team independently invented a verifiable ASIC strategy very similar to my own of a year or so ago. I learned digital at a high-level, generalist way of thinking with no hands-on ability and definitely no analog. So, I have to work at that level. Started learning risk areas from insiders like this [1]. My initial strategy enumerated problem space to tackle it head on [2]. Yet, I switched gears to follow how provers work: combine untrusted EDA tools and main CPU's with traces produced for trusted, verification tools on inspectable CPU's. Similar to what I did for high-assurance, guard designs at protocol level without formal methods. I determined by maybe Jan2015 based on my Schneier.com posts that trusted ASIC's should be 0.35 micron or above because they're still visually inspectable. If ever funded, I'd modify VAMP CPU to be more like SAFE or CHERI to do the job. If too hard to do visual on, I'd start with a Forth or JOP-like processor before that. Even considered FM9001 & Piton haha. Also, replicating computation on diverse, fast CPU's from various vendors, fabs, and countries with optical communication & EMSEC isolation. The old, diverse, voter scheme I did pre-silicon for things like build systems. Anyway, props on being ahead of me in implementation and more impressive design in general. Great work. That we converged on similar approach means it's probably worth me putting more effort into among the many ideas I'm juggling. I still gotta learn analog and hands-on formal methods, though, before I can do something like yours or provably solve the analog portion. (sighs) My gut has been telling me since I studied TEMPEST and RobertT's analog subversions that the solution will have strong analog component past diverse review of gates and such I was leaning on. [1] https://www.schneier.com/blog/archives/2013/09/surreptitiously.html#c1744173 https://www.schneier.com/blog/archives/2013/09/surreptitious... [2] https://news.ycombinator.com/item?id=10468624 https://news.ycombinator.com/item?id=10468624

kwantam 10y ago
So, what do you think about BitBabbler's analysis and design while you're at it? The problem with BitBabbler is that they have a lot of text but, as far as I can tell, no circuit diagrams and no real discussion of what they're doing. It may just be that their wall of text makes me go cross-eyed, but my snakeoil detector goes off whenever I start reading their web page. For example, the talk about sample-and-hold circuits as "analog shift registers" and worrying about quantization seems slightly unhinged (for one, if you need more resolution, just use a bigger sampling cap). Apologies to the BitBabbler people if they're on the up-and-up, but a page that talks about auditability and verifiability but doesn't show a schematic seems slightly dishonest. (Sorry... rant mode off.) Thanks for the kind words regarding verifiable ASICs! You are absolutely right that there's a ton of complexity to worry about here. But I sincerely hope that the world makes more headway on this problem, so I'm really glad you're thinking about it.