CPRNGs and assurance...
I'd like to expand on a point I made a little while ago about the "just throw everything at it, and hope the good sources drown out the bad ones" entropy collection strategy. The biggest problem in security systems isn't whether you're using 128 bit or 256 bit AES keys or similar trivia. The biggest problem is the limited ability of the human mind to understand a design. This leads to design bugs and implementation bugs. Design and implementation flaws are the biggest failure mode for security systems, not whether it will take all the energy in our galaxy vs. the entire visible universe to brute force a key. So, if you're designing any security system, the biggest thing on your mind has to be how to validate that the system is secure. That requires ways to know your design was correct, and ways to know you actually implemented your design correctly. "Just throw the kitchen sink at it" impedes both. As just one trivial example, say that your code is buggy and instead of throwing in eight entropy sources, you're really throwing out #1-#7 and only using #8, perhaps because of some overwriting that you thought was an xor or some similar stupidity. How are you going to notice this on the other end of your SHA-256 pool mashing? Will you look at the output by hand and magically see that the numbers aren't as random as they should be? Probably not. Lets then say #8 turned out to be a less than random source. Is this sort of stupid move theoretical? Ask the guys at Debian how theoretical it is. At the very least, you need to have a very good set of tests attached to your software that get run every time any sort of change (no matter how trivial) is made to it, and even that is not necessarily enough. If you're doing all of this properly (and few people do it properly), you need to have a good way of knowing that your system works right. This is especially hard to do properly at the best of times -- when the product of your algorithm is supposed to look like nonsense, it becomes especially important that you have a well understood design that has turned into a well validated implementation. "Throw the kitchen sink at it" often ends up kicking up enough dust that you can't distinguish something good from something bad. That can be a problem. Always bear in mind that security systems fail because of people, and that as a security system designer or implementor, you are the first and most likely point of failure in the entire process. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: CPRNGs are still an issue.
On Wed, 17 Dec 2008 13:02:58 -0500 Jerry Leichter wrote: > On Dec 16, 2008, at 4:22 PM, Charles Jackson wrote: > > I probably should not be commenting, not being a real device guy. > > But, > > variations in temperature and time could be expected to change SSD > > timing. > > Temperature changes will probably change the power supply voltages > > and shift > > some of the thresholds in the devices. Oscillators will drift > > with changes > > in temperature and voltage. Battery voltages tend to go down over > > time and > > up with temperature. In addition, in some systems the clock > > frequency is > > purposely swept over something like a 0.1% range in order to > > smooth out the > > RF emissions from the device. (This can give a 20 or 30 dB > > reduction in > > peak emissions at a given frequency. There is, of course, no > > change in > > total emissions.) > > > > Combine all of these factors, and one can envision the SSD cycles > > taking > > varying numbers of system clock ticks and consequently the low > > order bits of > > a counter driven by a system clock would be "random." However, > > one would > > have to test this kind of entropy source carefully and would have > > to keep > > track of any changes in the manufacturing processes for both the > > SSD and the > > processor chip. > > > > Is there anyone out there who knows about device timing that can > > say more? > I'm not a device guy either, but I've had reason to learn a bit more > about SSD's than is widely understood. > > SSD's are complicated devices. Deep down, the characteristics of > the underlying storage are very, very different from those of a > disk. Layers of sophisticated hardware/firmware intervene to make a > solid- state memory look like a disk. To take a very simple > example: The smallest unit you can read from/write to solid state > memory is several times the size of a disk block. So to allow > software to continue to read and write individual "disk blocks", you > have to do a layer of buffering and blocking/deblocking. A much more > obscure one is that the throughput of the memory is maximum when you > are doing either all reads or all writes; anywhere in between slows > it down. So higher- performance SSD's play games with what is > essentially double buffering: Do all reads against a segment of > memory, while sending writes to a separate copy as well as a > look-aside buffer to satisfy reads to data that was recently > written. Switch the roles of the two segments "at some point". > But what is the *physical basis* for the randomness? http://www.springerlink.com/content/gkbmm9nuy07kerww/ (full text at http://world.std.com/~dtd/random/forward.pdf) explains why hard drive timings are considered random; are their comparable phenomena for SSDs? (Of course -- that's a '94 paper; hard drive technology has changed a lot. Would they still get the same results?) --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: CPRNGs are still an issue.
Jerry Leichter writes: > SSD's are complicated devices. Complexity makes it hard to understand the security characteristics of relying on the timing of the devices. > So ... use with extreme caution. Estimate conservatively. Mix any > apparent entropy you get with other sources. The longer I'm in this field, the more the phrase "use with extreme caution" seems to mean "don't use" to me. More and more, I think that if you don't have a really good way to test and get assurance about a component of your security architecture, you should leave that component out. That's one reason I recommended "just use AES in counter mode" as the best way to generate random numbers in a low cost embedded context -- it is easy to get assurance simply by running AES validation tests, and you confine your risk to one easily examined part of the process, the key generator in the factory. I'm reminded of Tony Hoare's old saw about systems: "There are two ways of constructing a software design: One way is to make it so simple there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." Perry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: CPRNGs are still an issue.
On Dec 16, 2008, at 4:22 PM, Charles Jackson wrote: I probably should not be commenting, not being a real device guy. But, variations in temperature and time could be expected to change SSD timing. Temperature changes will probably change the power supply voltages and shift some of the thresholds in the devices. Oscillators will drift with changes in temperature and voltage. Battery voltages tend to go down over time and up with temperature. In addition, in some systems the clock frequency is purposely swept over something like a 0.1% range in order to smooth out the RF emissions from the device. (This can give a 20 or 30 dB reduction in peak emissions at a given frequency. There is, of course, no change in total emissions.) Combine all of these factors, and one can envision the SSD cycles taking varying numbers of system clock ticks and consequently the low order bits of a counter driven by a system clock would be "random." However, one would have to test this kind of entropy source carefully and would have to keep track of any changes in the manufacturing processes for both the SSD and the processor chip. Is there anyone out there who knows about device timing that can say more? I'm not a device guy either, but I've had reason to learn a bit more about SSD's than is widely understood. SSD's are complicated devices. Deep down, the characteristics of the underlying storage are very, very different from those of a disk. Layers of sophisticated hardware/firmware intervene to make a solid- state memory look like a disk. To take a very simple example: The smallest unit you can read from/write to solid state memory is several times the size of a disk block. So to allow software to continue to read and write individual "disk blocks", you have to do a layer of buffering and blocking/deblocking. A much more obscure one is that the throughput of the memory is maximum when you are doing either all reads or all writes; anywhere in between slows it down. So higher- performance SSD's play games with what is essentially double buffering: Do all reads against a segment of memory, while sending writes to a separate copy as well as a look-aside buffer to satisfy reads to data that was recently written. Switch the roles of the two segments "at some point". Put all this together and the performance visible even at the OS driver level will certainly show all kinds of variation. However, just because there's variation doesn't mean there's entropy to be had! You'd need to have a sufficiently detailed model of the inner workings of the SSD to be confident that the variations aren't predictable. However, you're not likely to get that: Getting good performance out of SSD's is a black art. The techniques are highly proprietary right now, because they are what make an SSD competitive. Further, of course, anything you did learn would likely apply to one manufacturing run of one model - just about anything could change at any time. So ... use with extreme caution. Estimate conservatively. Mix any apparent entropy you get with other sources. -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: CPRNGs are still an issue.
=?ISO-8859-1?Q?Joachim_Str=F6mbergson?= writes: >Damien Miller wrote: >> 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. This is only going to be a problem if your RNG is... well, to be blunt, stupid enough to rely entirely on HDD timings as an entropy source. I would hope that any well-designed entropy polling system would use as many sources as possible for the simple reason that otherwise a single failure can destroy the security of your entire system. In other words an entropy polling mechanism should see the change from HDD to SSD as nothing more than a small glitch for its fault-tolerant front-end to accomodate and continue as before. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: CPRNGs are still an issue.
Bill Frantz 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 ARM family are particularly problematic for entropy gathering because anything that'd help you is (a) locked away so it can't be accessed and (b) not easily ascertainable at runtime. For the x86 equivalent you just do a CPUID (and you can in turn check whether the architecture supports that before you use it if you're on an old-enough system) and from there can execute further instructions to determine hardware capabilities and read/use them via MSRs as required. For the ARM the equivalent is a CP15 read (and then further accesses to the ARM equivalent of x86 MSRs), e.g.: asm volatile ( "mrc p15, 0, r0, c0, c0, 0\n\t" "str r0, %0\n" : "=m"(processorID) : : "cc", "r0"); but this is only accessible in supervisor mode so for any normal app it's an instant illegal instruction fault. Furthermore, even in supervisor mode there's no way to bootstrap your way up as you can for x86 and tap the amazing store of hard-to-predict information that most ARM cores make available because each ARM implementation adds its own oddball registers and the only way to know whether they're present and usable is if you know in advance which specific core and stepping you're working with. In other words you can't get there from here and even if you could you wouldn't know what to do when you got there. So everything you need is there, you just can't use it. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Why the poor uptake of encrypted email?
StealthMonger writes: >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. ... to a statistically irrelevant bunch of geeks. Watch Skype deploy a not- terribly-anonymous (to the people running the Skype servers) communications system. Watch the entire world not care, and flock to it in droves. Heck, the entire business model for social networking, one of the biggest Internet phenomena in the last few years, is built around users being as non-anonymous as possible. So Alec's argument still stands. It's pretty hard selling anonymity and privacy to people who think nothing of sending Twitter updates of everything they do all day long to anyone prepared to listen and posting videos of their drunken antics to MyFace. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: CPRNGs are still an issue.
On Tue, 16 Dec 2008, mhey...@gmail.com wrote: > On Thu, Dec 11, 2008 at 8:42 PM, 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. > > > 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 > - 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. I think you have it quite backwards - in the absence of good evidence that transaction timings on SSDs are dependent on some physically unpredictable process (air turbulence, shot noise, etc.) then they should not be considered suitable for cryptographic use, no matter how "random looking" they are. -d - 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:28 PM, Joachim Strömbergson wrote: ...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? They don't seem to be doing very much yet - and the problems are very real. All sorts of algorithms assume that an instance of a running OS has some unique features associated with it, and at the least (a) those will be fairly stable over time; (b) there will never be two instances at the same time. In different contexts and uses, virtualization breaks both of these. The virtual image captures everything there is to say about the running OS and all its processes. Nothing stops you from running multiple copies at once. Nothing stops you from saving an image, so replaying the same machine state repeatedly. Conversely, if something in the underlying hardware is made available to provide uniqueness of some kind, the ability to stop the VM and move it elsewhere - typically between almost any two instructions - means that you can't rely on this uniqueness except in very constrained ways. People move to virtualization with the idea that a virtual machine is just like a physical machine, only more flexible. Well - it's either "just like", or it's "more flexible"! It can't be both. In fact, "more flexible" is what sells virtualization, and the effects can be very subtle and far-reaching. We don't really understand them. -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: CPRNGs are still an issue.
On Dec 16, 2008, at 12:10 PM, Simon Josefsson wrote: ...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). Configuration at installation seems to be worth considering. It's a matter of making that as easy as possible. Asking users for the AES key is not easy - people aren't good at generating, or even entering, random 128-bit strings. However, you might be able to get them to push a reset button - or even connect and disconnect the device - a number of times and use the timing as a source of entropy. For something like a network interface, it might be reasonable to assume that an attacker is unlikely to be present at exactly the time of initial configuration, so simply pulling bits off the wire/out of the air during initialization isn't unreasonable. In general, given the assumption that it's easier to keep the initialization environment reasonably secure than it is the general fielded environment, and that you can afford much more time during initial configuration than is likely during normal operation, all kinds of things that are marginal if used operationally may be workable for initial configuration. (Also, of course, operational use may be unattended, but in most cases you can assume that initial configuration is attended.) -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
RE: CPRNGs are still an issue.
-Michael Heyman Wrote: Before we give up on using drive timings [as an entropy source], does anyone have evidence to verify this assertion [that SSD drives will have much less variation in read/write timing]? 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 - 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. == I probably should not be commenting, not being a real device guy. But, variations in temperature and time could be expected to change SSD timing. Temperature changes will probably change the power supply voltages and shift some of the thresholds in the devices. Oscillators will drift with changes in temperature and voltage. Battery voltages tend to go down over time and up with temperature. In addition, in some systems the clock frequency is purposely swept over something like a 0.1% range in order to smooth out the RF emissions from the device. (This can give a 20 or 30 dB reduction in peak emissions at a given frequency. There is, of course, no change in total emissions.) Combine all of these factors, and one can envision the SSD cycles taking varying numbers of system clock ticks and consequently the low order bits of a counter driven by a system clock would be "random." However, one would have to test this kind of entropy source carefully and would have to keep track of any changes in the manufacturing processes for both the SSD and the processor chip. Is there anyone out there who knows about device timing that can say more? Chuck Jackson - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Why the poor uptake of encrypted email?
On Tue, Dec 16, 2008 at 03:06:04AM +, StealthMonger wrote: > Alec Muffett 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. The subject is "[w]hy the poor uptake of encrypted email?". Alec's answer shows that "encrypted email" when at rest is not easy to use. Providing a suitable e-mail security solution for the masses strikes me as more important than providing anonymity to the few people who want or need it. Not that you can't have both, unless you want everyone to use PGP or S/MIME as a way to hide anonymized traffic from non-anonymized traffic. Nico -- - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
