Re: [Cryptography] Why is emailing me my password?
On 10/01/2013 10:28 AM, Greg wrote: This falls somewhere in the land of beyond-the-absurd. I noticed the password would be mailed in the clear when I signed up, but even if I had not, I would not have been bothered to later discover it. What is the harm? The sensitivity of this password is extremely limited. That is, unless you are someone who recycles one password in other places. You wouldn't do that, though, would you? -kb ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Gilmore response to NSA mathematician's make rules for NSA appeal
On 09/18/2013 01:31 PM, Walter van Holst wrote: What makes me a tad bitter is that we apparantly live in a world with two classes: US citizens and the subhuman rest of it. NSA-style blanket surveillance violates the fundamental right to privacy and ultimately also the fundamental right to freedom of expression. These are not rights that are solely vested in the exceptional Americans. You foreigners actually have a really big vote here. All those US internet companies want your business, and as you get no protections, in the current scheme, not even lip-service, you should look for alternatives. As you do, this puts pressure on the US internet companies, and they have the economic clout to put pressure on Feinstein and Polosi and all the others. Sad that economic clout matters so much, but voters in the US are astoundingly ignorant of reality (pick a topic--other than sports and celebrity gossip--and we are ignorant), and so many can't be bothered to vote. We kind of get the government we deserve. Do what you can to save us, please. -kb ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Broken RNG Generating Taiwanese Citizen Digital Certificates
Broken RNG-time again: In looking 2.2 million certificates, researchers found reused primes in 103 of them. News story: http://arstechnica.com/security/2013/09/fatal-crypto-flaw-in-some-government-certified-smartcards-makes-forgery-a-snap/ Original paper: http://smartfacts.cr.yp.to/smartfacts-20130916.pdf -kb ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] real random numbers
On 09/15/2013 10:19 AM, John Kelsey wrote: But those are pretty critical things, especially (a). You need to know whether it is yet safe to generate your high-value keypair. For that, you don't need super precise entropy estimates, but you do need at least a good first cut entropy estimate--does this input string have 20 bits of entropy or 120 bits? Yes, the time I was part of designing a physical RNG product (for use in real gambling, for real money) we made sure to not only sweep up all the entropy sources we could, and not only mixed in fixed information such as MAC addresses to further make different machines different, our manufacturing procedures included pre-seeding the stored pool with data from Linux computer that had a mouse and keyboard and lots of human input. We did not try to do entropy accounting, but did worry about having enough. We also were going way overboard on security thinking, far exceeding regulatory requirements for any jurisdiction we looked at. I don't know if it every shipped to a customer, but we got all the approvals necessary so it could have... I do agree that, though a Linux box might make keys on its first boot, it should be used interactively first, and then generate keys. Again Ubuntu (at least a desktop install) doesn't include sshd by default, you have to decide to install it, and at that point, if there is a human setting up things with a keyboard and mouse, there should be a lot of entropy. Ubuntu server installations might be different, and I would be very worried about automatic provisioning of server machines in bulk. -kb ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] real random numbers
John Kelsey wrote: I think the big problem with (b) is in quantifying the entropy you get. Maybe don't. When Bruce Schneier last put his hand to designing an RNG he concluded that estimating entropy is doomed. I don't think he would object to some coarse order-of-magnitude confirmation that there is entropy coming in, but I think trying to meter entropy-in against entropy-out will either leave you starved or fooled. -kb ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] real random numbers
On 09/14/2013 03:29 PM, John Denker wrote: Things like clock skew are usually nothing but squish ... not reliably predictable, but also not reliably unpredictable. I'm not interested in squish, and I'm not interested in speculation about things that might be random. I see theoretical the enemy of the good here. The term squish is entertaining, but be careful that once you paint away with your broad brush that you don't dismiss engineering realities that matter. I can see there is an appeal to entropy sources that you can work back to some quantum origin, but even they will fail horribly if you don't build a larger system that is secure, and secure at some non-trivial radius. (How much Tempest-hardening are you going to do?) And once we have built such vaguely secure systems, why reject entropy sources within those systems, merely because they you think they look like squish? If there is a random component, why toss it out? You seem to respect using hashing to condition and stretch entropy--though why any existing hash shouldn't also fall to your squish generalization, I don't know. It seems that you would reject using a coin toss as a source of entropy because coins are not perfectly fair and there are biases in their results. So? You respect hashing, why not clean the output with a good hash? You dismiss things like clock skew, but when I start to imagine ways to defeat interrupt timing as an entropy source, your Johnson noise source also fails: by the time the adversary has enough information about what is going on inside the GHz-plus box to infer precise clock phase, precise interrupt timing, and how fast the CPU responds...they have also tapped into the code that is counting your Johnson. There are a lot of installed machines that can get useful entropy from existing sources, and it seems you would have the man who is dying of thirst die, because the water isn't pure enough. Certainly, if hardware manufacturers want to put dedicated entropy sources in machines, I approve, and I am even going to use rdrand as *part* of my random numbers, but in the mean time, give the poor servers a sip of entropy. (And bravo to Linux distributions that overruled the purist Linux maintainer who thought no entropy was better than poorly audited entropy, we are a lot more secure because of them.) -kb ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Finding Entropy Isn't That Hard
On 09/11/2013 07:18 PM, Perry E. Metzger wrote: the world's routers, servers, etc. do not have good sources, especially at first boot time, and for customer NAT boxes and the like the price points are vicious. I agree that things like consumer NAT boxes have a tricky problem, and anything that needs high bandwidth random data, but otherwise routers and servers are not as bad off as people say. At least in the case of modern servers that are running enough of an OS to include a good entropy-pool RGN (like Linux's urandom*). These boxes have GHz-plus clocks, so fast that the box doesn't have that clock, it only exists on-chip. It is multiplied up from a lower frequency external crystal oscillator by an analog PLL which is also on-chip. This fastest clock is commonly used to drive an on-chip counter. These chips also have interrupts from the outside world. There is real entropy in the interaction between the two. What is that value of that counter when the interrupt is serviced? I assert there is entropy in the LSB of that value. A GHz-plus clock is running just too fast for someone meters (or kilometers) away to know its exact value. And every time the observer might get the LSB wrong, a bit of entropy got by: Use that data to stir an entropy pool. How do we know it is hard to know the value of a GHz-plus counter? Because of the engineering problems suffered by people trying to build fast systems. Clock distribution is difficult--there is a reason that high speed clock doesn't exist off-chip, the skew becomes great. Even on-chip clock distribution is tricky and requires careful layout rules when designing the chip. And even on this fast chip, the uses of the fastest clock are limited and any functions that will work on a slower clock will get a slower clock. Clock distribution is hard. Hard within a large IC, hard on a circuit board, hard between circuit boards, hard between boxes, hard between equipment racks, hard between buildings...how far away is this nefarious observer, the one who you worry might be able to infer the LSB? I think more than a few cm is too far away and if you don't have security at that radius, you don't have security. [* Until Linux kernel 3.6 the person maintaining urandom was busily turning off interrupts as a source of entropy, I think because he didn't know how much entropy he was getting so better not to get it at all (huh?). In 3.6 this was changed to use all interrupts as entropy sources, which is good. This means earlier kernels aren't so good--though I notice that Ubuntu's kernel has the 3.6 improvement in their version of 3.2, so individual distributions will vary.] -kb ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Finding Entropy Isn't That Hard
On 09/12/2013 10:41 AM, Kent Borg wrote: routers and servers are not as bad off as people say. Not that more sources is bad. A new trustworthy HW entropy source would be good. Even a suspect rdrand is worth XORing in (as Linux does on the machine I am using right now). But if you thirst for more entropy keep looking in your current hardware, server boxes are particularly good hunting grounds for a few more dribs of entropy: - current RPM of all the fans (the proverbial entropy-starved server can have a lot of fans) - temperatures - voltages - disk (SMART) statistics (temperatures and error counts, multiplied by the number of disks) These are all things that could wear out or go wrong, which means they need monitoring because...you can't otherwise know what they are. Cool, that's a decent definition of entropy. Sample them regularly and hash them into your entropy pool. Not a lot of bandwidth there, but if your RNG does a good job of hiding its internal state, and you are mixing in a dozen more bits here and a dozen more bits there...pretty soon you have made the attacker's job a lot harder. Maybe not as sexy as a lavalamp or radioactive gizmos, but more practical and available now. -kb ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Finding Entropy Isn't That Hard
On 09/13/2013 11:59 AM, Marcus Leech wrote: Any physical-world sensor driver, where the sensor inherently has a bit of noise, I think has a moral obligation to contribute bits to the kernel entopy pool. Within limits. Mixing the entropy pool on Linux takes work and battery power. Looking at some random Android kernel source code (git commit c73c9662) it looks like add_interrupt_randomness() is happening for every interrupt (your Android device's kernel may vary), so there is probably plenty of entropy. And add_interrupt_randomness() throttles to only feed the randomness once a second, not wasting our time or battery. Don't carry moral obligation beyond what is reasonable! -kb ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Techniques for malevolent crypto hardware
On 09/08/2013 11:56 PM, Jerry Leichter wrote: Which brings into the light the question: Just *why* have so many random number generators proved to be so weak. Your three cases left off an important one: Not bothering to seed the PRNG at all. I think the Java/Android cryptographic (!) library bug that just came up was an instance of that. I think the root of the problem is that programs are written, and bugs squashed, until the program works. Maybe throw some additional testing at it if we are being thorough, but then business pressures and boredom says ship it. That won't catch a PRNG that wasn't seeded, nor a hashed password that wasn't salted, the unprotected URL, the SQL injection path, buffer overflow, etc. Computer security is design, implementation, and skepticism. But unless you can sell it with a buzzword... -kb ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Techniques for malevolent crypto hardware
On 09/08/2013 06:16 PM, John Kelsey wrote: I don't think you can do anything useful in crypto without some good source of random bits. I don't see the big worry about how hard it is to generate random numbers unless: a) You need them super fast (because you are Google, trying to secure your very high-speed long lines), or b) You are some embedded device that is impoverished for both sources of entropy and non-volatile storage, and you need good random bits the moment you boot. On everything in between, there are sources of entropy. Collect them, hash then together and use them to feed some good cryptography. If you seem short of entropy, look for more in your hardware manual. Hash in any local unique information. Hash in everything you can find! (If the NSA knows every single bit you are hashing in, no harm, hash them in anyway, but...if the NSA has misunderestimated any one of your bits...then you scored a bit! Repeat as necessary.) I am thinking pure HW RNGs are more sinful than pure SW RNGs, because real world entropy is colored and hardware is the wrong place to fix that. So don't buy HW RNGs, buy HW entropy sources (or find them in your current HW) and feed them into a good hybrid RNG. On a modern multi-GHz CPU the exact LSB of your highspeed system counters, when the interrupt hits your service routine, has uncertainty that is quite real once the you push the NSA a few centimeters from your CPU or SoC. Just sit around until you have a few network packets and you can have some real entropy. Wait longer for more entropy. In case you did notice, I am a fan of hybrid HW/SW RNGs. -kb P.S. Entropy pools that are only saved on orderly shutdowns are risking crash-and-playback attacks. Save regularly, or something like that. P.P.S. Don't try to estimate entropy, it is a fool's errand, get as much as you can (within reason) and feed it into some good cryptography. P.P.P.S. Have an independent RNG? If it *is* independent, no harm in XORing it in. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Techniques for malevolent crypto hardware
On 09/08/2013 09:15 PM, Perry E. Metzger wrote: Perhaps you don't see the big worry, but real world experience says it is something everyone else should worry about anyway. I overstated it. Good random numbers are crucial, and like any cryptography, exact details matter. Programmers are constantly making embarrassing mistakes. (The recent Android RNG bug, was that Sun, Oracle, or Google?) But there is no special reason to worry about corrupted HW RNGs because one should not be using them as-is, there are better ways to get good random data, ways not obvious to a naive civilian, but still well known. Snowden reassured us when he said that good cryptography is still good cryptography. If that includes both hashes and cyphers, then the fundamental components of sensible hybrid RNGs are sound. Much more worrisome is whether Manchurian Circuits have been added to any hardware, no matter its admitted purpose, just waiting to be activated. -kb ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
