Reply to post: Hey El Reg Peeps, Paper Author Here

Boffin: Dump hardware number generators for encryption and instead look within

jvroig

Hey El Reg Peeps, Paper Author Here

Hi El Reg!

This is JV Roig, the cited paper author. Glad to be back! (Some of you may remember me from the Password Research article of Tom a few months ago: https://www.theregister.co.uk/2018/05/10/smart_people_passwords/)

I was going to join the comments section earlier (Tom FYI'd me about this article a day ago), but I was busy updating the supplementary site. It's done. If you visit https://research.jvroig.com/siderand now, it contains a lot of new information that deals with the problem better.

I've separated the concepts into two more palatable sections - first is the paradigm ("Virtual Coin Flip"), and the specific implementation ("Micro-Benchmark Timing Aggregation", which replaces the SideRand name). Please give that page a visit. Not only does it have a good discussion of those two concepts, it also contains all experimental data - for those of you interested in checking it out.

It also deals more with previous work such as HAVEGE/haveged, Jitter Entropy, and Maxwell, particularly in how they adhere to my trust criteria for sources of randomness, and key differences with my MBTA.

A note on reproducibility. The C code, by nature, must not be optimized. Remember, we are trying to make the CPU do work. The optimization removes this work, so there's nothing for us to measure. This is a C limitation, and you'll find that this is exactly also necessary for Stephan Mueller's Jitter Entropy.

However, you'll find that the PHP, Ruby and Python prototypes don't need such handholding. Download those prototypes from the webpage, and you can also download the tools I used to gather and profile the resulting entropy. That's all you need to see how much entropy it can gather in your system. And of course, none of these are production codes - I imagine these will mostly be intact and similar to actual production-grade code, but primarily these are prototypes for gathering data to measure how much entropy is there.

A final note on embedded devices: How confident am I that this works even on embedded? 100% confident. It's not included in the pre-print you've read as it still needs to be updated with newer results, but I've tested using a bunch of the original RPi 1 (700MHz ARM11, very old in-order-processing CPU), and it still works.

In fact, I've also tested on an Arduino Uno - that's a microcontroller with a very slow, simple 16MHz processor, and a low res timer (4-microseconds). The optimized MBTA code there was able to extract 3,000 bits of entropy per second. That's overkill for seeding, even in such a worse environment (combo of simple CPU + low res timer).

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019