Thus spake Mirko Vogt (mirko@xxxxxxxxxxx): > On 01/18/2013 01:46 PM, Okhin wrote: > > However, given the relatively limited capability of those devices, 4il wondering if they can have enough entropy to run Tor safely, and if it won't endanger the network. > > So,before going further on the step of propagating those Tor small boxes, I need advices about this entropy. Is it an issue? Is there a way to work around it (generating keys and certificates on a different computer maybe? but then, how?) > > Yes, there is definitely an issue with entropy which should be kept in > mind. Lot's of embedded devices / SoCs do not have enough entropy > sources (or software/drivers which could at least make the most out of > what's there) to ensure cryptographically secure keys. > > You might be surprised how often dropbear (an lightweight SSH server - > used by e.g. OpenWrt) generates the _exact very same_ SSH host keys > during the first boot on some devices. I ran into this issue several > times when I had to flash bunches of devices. > > And that wasn't even the AR7240. The AR7240 - in this manner - is the > worst SoC I've ever seen. They cut it down to its basics, dropping every > kind of source where entropy could be gathered from. > Take a look at /proc/sys/kernel/random/entropy_avail right after boot to > get an idea (and it might be actually higher than it would have been > without you looking at it :)). It might be even 0(!) right after boot[2]. > > There's also this haveged[1] using the havege algorithm. However to me, > as a non-mathematician, this sounds a bit like "we make a lot [of > entropy] out of little". Maybe somebody could shed some light on this.. Disclaimer: I haven't read either the source or the research paper behind haveged. However, based on http://www.irisa.fr/caps/projects/hipsor/misc.php#exectime, it sounds like the underlying assumption is that *any* externally driven interrupt that happens on your system will alter the internal state of the CPU and caches such that a measurement codepath will actually end up taking a variable number of clock cycles, which they then use as their source of entropy. If they're right (critically: their assumption also applies as well to MIPS or ARM CPUs as it does to x86, SPARC, and DEC CPUs. Their docs don't mention interrupt uncertainty stats for ARM or MIPS), then anything that causes an external interrupt on your machine should effectively provide entropy to haveged. But, even with this, it would seem that if you're booting your SoC without any enabled devices from readonly boot media, I would still expect there is a high likelihood that the internal CPU state will still be identical through the boot process, unless you have thermal sensors or a battery monitor or something. On the other hand, if their assumption holds equally well for these CPUs, I would also guess that the interrupts even from passively scanning WiFi should provide enough entropy even without driver support, though. From the table in that that url, it looks like the least amount of entropy they could extract per interrupt was 8Kbit (Itanium I)? Certainly is an interesting idea. -- Mike Perry
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-talk mailing list tor-talk@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk