Re: CPRNGs are still an issue.
Aloha! Damien Miller wrote: On Thu, 11 Dec 2008, James A. Donald wrote: If one uses a higher resolution counter - sub microsecond - and times multiple disk accesses, one gets true physical randomness, since disk access times are effected by turbulence, which is physically true random. Until someone runs your software on a SSD instead of a HDD. Oops. That is a very good observation. I would bet loads of GM stocks that very few people realise that moving from 0ld sk00l HDD to SSD would affect their entropy sources. Does anybode have any idea if this has been discussed among OS Dev groups? One could probably do a similar comparison to the increasingly popular idea of building virtual LANs to connect your virtualized server running on the same physical host. Ethernet frame reception time variance as well as other real physical events should take a hit when moving into the virtualization domain. After all, replacing physical stuff with SW is the whole point of virtualization. Does anybody know what VMware, Parallels etc do to support entropy for sources like this, or is it basically a forgotten/skipped/ignored feature? -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. Kryptoblog - IT-säkerhet på svenska http://www.strombergson.com/kryptoblog - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
Damien Miller wrote: On Thu, 11 Dec 2008, James A. Donald wrote: If one uses a higher resolution counter - sub microsecond - and times multiple disk accesses, one gets true physical randomness, since disk access times are effected by turbulence, which is physically true random. Until someone runs your software on a SSD instead of a HDD. Oops. How would software that attempted to measure the entropy of the incoming seek times behave when an SSD replaced an HDD? Would the reduction in measured entropy be proportional to the reduction in entropy from the attacker's point of view? -- __ \/ o\ Paul Crowley /\__/ www.ciphergoth.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
Bill Frantz fra...@pwpconsult.com wrote: Short of building special random number generation hardware, does anyone have any suggestions for additional sources? Any unused input device with noise can be used. Examples: Soundcard: http://www.av8n.com/turbid/ Camera: http://www.lavarnd.org/ If anything in the system changes a lot, like processes starting and stopping or files opening closing, periodically hashing the tables that describe that state is useful. Is your threat model one-sided? e.g. for a home router, attacks from the Internet side might be more of a worry than attacks from the LAN. In that case, things like packet timing on the LAN side are unknown to the feared attacker. Also, if you are doing NAT, the port numbers on the LAN side since those are not sent outside. If the device does any crypto, mixing ciphertext into the pool is nowhere near ideal since you would not be encrypting unless some enemy might get the text and using things an an enemy can get is exactly what you do not want here. However, it is cheap and random-looking, and the volume is proportional to the amount of crypto done, so it might help in some cases. -- Sandy Harris, Quanzhou, Fujian, China - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
On Dec 15, 2008, at 2:09 PM, Perry E. Metzger wrote: Bill Frantz fra...@pwpconsult.com writes: I find myself in this situation with a design I'm working on. I have an ARM chip, where each chip has two unique numbers burned into the chip for a total of 160 bits. I don't think I can really depend on these numbers being secret, since the chip designers thought they would be useful for DRM. It certainly will do no harm to hash them into the pool, and give them a zero entropy weight. The system will be built with SSD instead of HDD, so Damien's comment hits close to home. I hope to be able to use timing of external devices, the system communicates with a number of these, along with a microsecond counter to gather entropy from clock skew between the internal clock and the clocks in those devices. Unfortunately the system doesn't normally have a user, so UI timings will be few and far between. Short of building special random number generation hardware, does anyone have any suggestions for additional sources? Given the usual threat model for a device like this, I'd just store an AES key at the factory and use it in counter mode (or something very similar) as your PRNG. Agree in general. Just one point: One big issue might be that if you can't store the counter across device resets, you will need a new layer of indirection -- the obvious one is to generate a new AES key at boot, perhaps by CBCing the real time clock with the permanent AES key and use the new key in counter mode for that session. This strikes me as additional complication for little purpose. Keep the same AES key - in fact, it might even be useful to either store the generated key schedules or even to generate open code for the particular device-specific key. Take the real time clock's value for the upper 64 bits of a the input to AES, and use a counter starting at 0 for the lower 64 bits. As long as the precision of the RTC is sufficient that you can never have two boots with the same value, you're fine. (If you actually have a bigger RTC values you can throw away low-order bits.) Given that we *are* assuming an SSD, of course, you could presumably store values across boots - though there are advantages to the RTC, since it avoids having to have special cases for things like the initialization of the stored value and recovery if the SSD is replaced. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Why the poor uptake of encrypted email?
Alec Muffett alec.muff...@sun.com writes: In the world of e-mail the problem is that the end-user inherits a blob of data which was encrypted in order to defend the message as it passes hop by hop over the store-and-forward SMTP-relay (or UUCP?) e- mail network... but the user is left to deal with the effects of solving the *transport* security problem. The model is old. It is busted. It is (today) wrong. But the capabilities of encrypted email go beyond mere confidentiality and authentication. They include also strongly untraceable anonymity and pseudonymity. This is accomplished by using chains of anonymizing remailers, each having a large random latency for mixing with other traffic. Connection-based communication such as Skype and OTR do not provide this capability. The hop by hop store-and-forward email network does. This is not busted or wrong. It's essential. stealthmail: Scripts to hide whether you're doing email, or when, or with whom. mailto:stealthsu...@nym.mixmin.net -- StealthMonger stealthmon...@nym.mixmin.net stealthmon...@nym.panta-rhei.eu.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
Perry E. Metzger wrote: [Snip admirably straightforward threat and requirements analysis] Yes, you can attempt to gather randomness at run time, but there are endless ways to screw that up -- can you *really* tell if your random numbers are random enough? -- and in a cheap device with low manufacturing tolerances, can you really rely on how consistent things like clock skew will be? Given the previous discussion on combining entropy, it shouldn't hurt, as long as it's testable during manufacture. Lets contrast that with AES in counter mode with a really good factory installed key. It is trivial to validate that your code works correctly (and do please do that!) It is straightforward to build a device to generate a stream of good AES key at the factory, and you need only make sure that one piece of hardware is working correctly, rather than all the cheap pieces of hardware you're churning out. Ah, here's the rub. I like this testing requirement. The recent FreeBSD Security Advisory was merely a simple failure of initialization -- yet wasn't caught for the longest time, because it wasn't readily testable. One big issue might be that if you can't store the counter across device resets, you will need a new layer of indirection -- the obvious one is to generate a new AES key at boot, perhaps by CBCing the real time clock with the permanent AES key and use the new key in counter mode for that session. As long as the testing procedure validates the key and key+RTC separately. This does necessitate an extra manufacturing step in which the device gets individualized, but you're setting the default password to a per-device string and having that taped to the top of the box anyway, right? If you're not, most of the boxes will be vulnerable anyway and there's no point... Recently, I was pleasantly surprised that the ATT U-verse box had this! Unlike the ATT 2wire boxes we were installing just this summer. If we could only get Linksys, et alia on board - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
On Thu, Dec 11, 2008 at 8:42 PM, Damien Miller d...@mindrot.org wrote: On Thu, 11 Dec 2008, James A. Donald wrote: If one uses a higher resolution counter - sub microsecond - and times multiple disk accesses, one gets true physical randomness, since disk access times are effected by turbulence, which is physically true random. Until someone runs your software on a SSD instead of a HDD. Oops. Before we give up on using drive timings, does anyone have evidence to verify this assertion? The reviews I have seen using tools like HD Tune and HD Tach seem to show timing noise reading and writing SSDs. I don't know where the noise comes from - it is probably not turbulence grin/ - but it may be random enough that a long series of tests, say for a second or so (don't forget, these drives are fast), could provide a nice pool of unguessable bits. -Michael Heyman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
Perry E. Metzger pe...@piermont.com writes: This does necessitate an extra manufacturing step in which the device gets individualized, but you're setting the default password to a per-device string and having that taped to the top of the box anyway, right? If you're not, most of the boxes will be vulnerable anyway and there's no point... Not quite, you can optimize that. Some software (e.g., OpenWRT) forces users to access the device via (local) ethernet before wireless is enabled. This enables security aware people to configure wireless security, and avoid a period of insecure wireless network. Incidentally, this approach also enables devices to collect entropy from the user session. That could be useful when generating SSH private keys. (Although I believe, unfortunately, OpenWRT generates the SSH key directly after the first boot. It seems unclear what kind of entropy it can hope to have at that point?) I agree with your recommendation to write an AES key to devices at manufacturing time. However it always comes with costs, including: 1) The cost of improving the manufacture process sufficiently well to make it unlikely that compromised AES keys are set in the factory. 2) The cost of individualizing each device. Each of these costs can be high enough that alternative approaches can be cost-effective. (*) My impression is that the cost and risks in 1) are often under-estimated, to the point where they can become a relatively cheap attack vector. /Simon (*) In case anyone doubts how the YubiKey works, which I'm affiliated with, we took the costs in 1) and 2). But they are large costs. We considered to require users to go through an initial configuration step to set the AES key themselves. However, the usability cost in that is probably higher than 1) and 2). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
