Re: traffic analysis
On Thu, Aug 28, 2003 at 08:06:07AM -0400, John S. Denker wrote: [...] The solution I outlined is modelled after procedures that governments have used for decades to defend against traffic analysis threats to their embassies and overseas military bases. More specifically, anybody who thinks the scheme I described is vulnerable to a timing attack isn't paying attention. I addressed this point several times in my original note. All transmissions adhere to a schedule -- independent of the amount, timing, meaning, and other characteristics of the payload. Different models. You state in your previous note that it is important that all the endpoints be trusted. Traffic between military bases, embassies etc all involve trusted endpoints. A public website is intrinsically not a trusted endpoint. Moreover, addition of cover browsing by the hub to random websites doesn't add any significant protection if the goal is to provide real-time access. -- Kent Crispin Be good, and you will be [EMAIL PROTECTED],[EMAIL PROTECTED] lonesome. p: +1 310 823 9358 f: +1 310 823 8649 -- Mark Twain - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Trusting the Tools - was Re: Open Source ...
On Sun, Oct 12, 2003 at 08:25:21AM -0600, Anne Lynn Wheeler wrote: It wouldn't have been impossible ... but quite unlikely. It is somewhat easier in C-based programs since there are additional levels of indirection and obfuscations between the statements in a C program and the generated machine code. Hmm. While I agree with your assessment of likelihood, I think you understate the seriousness of the issue in both the C case and the assembler case -- they are not really that different. It's not just a matter of indirection and obfuscation -- there can be large blocks of code generated for which there is no external visibility whatsoever (ie, the map files and other traces of generated code can simply not show the hidden code. This is true both for C and assembler. The only way you can really tell is if you capture *all* of the live memory of the computer, and disassemble it with a verified disassembler. (eg, what shows as bss 0 in the assembler listing is really code; what shows as one set of instructions in the listing is in reality different.) Kent -- Kent Crispin Be good, and you will be [EMAIL PROTECTED],[EMAIL PROTECTED] lonesome. p: +1 310 823 9358 f: +1 310 823 8649 -- Mark Twain - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: DNSSEC to be strangled at birth.
On Thu, Apr 05, 2007 at 04:49:33PM -0700, Paul Hoffman wrote: At 7:26 PM -0400 4/5/07, Thor Lancelot Simon wrote: On Thu, Apr 05, 2007 at 07:32:09AM -0700, Paul Hoffman wrote: Control: The root signing key only controls the contents of the root, not any level below the root. That is, of course, false, This is, of course false. In order to control the contents of the second level of the DNS, they have to either change the control of the first level (it's kinda obvious when they take .net away from VeriSign) or they have to sign across the hierarchy (it's kinda obvious when furble.net is signed by someone other than .net). You're arguement is that DHS couldn't do this covertly, but that's only part of the picture. I can imagine scenarios where they do things *overtly*. [...] Because I believe that ISPs, not just security geeks, will be vigilant in watching whether there is any layer-hopping signing and will scream loudly when they see it. AOL and MSN have much more to lose if DHS decides to screw with the DNS than anyone on this list does. Having said that, it is likely that we will be the ones to shoot the signal flares if DHS (or ICANN, for that matter) misuses the root signing key. But it won't be us that causes DHS to stand down or, more likely, get thrown off the root: it's the companies who have billions of dollars to lose if the DNS becomes untrusted. 1) It's untrusted now. 2) The argument could be that they are doing it to make it more trusted. I agree: highly unlikely. But not impossible. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of opportunistic encryption
On Thu, Jun 01, 2006 at 01:47:06PM +1200, Peter Gutmann wrote: Grab OpenVPN (which is what OpenSWAN should be), install, point it at the target system, and you have opportunistic encryption. Forgive my doltishness, but could you expand on that just a bit, please (or point at the right place in the docs)? I've used openvpn to set up dedicated tunnels, but it isn't immediately obvious to me how it would be configured to do opportunistic encryption. -- Kent Crispin [EMAIL PROTECTED]p: +1 310 823 9358 f: +1 310 823 8649 [EMAIL PROTECTED] SIP: [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: full-disk subversion standards released
Hi Peter, Apart from the obvious fact that if the TPM is good for DRM then it is also good for protecting servers and the data on them, In which way, and for what sorts of protection? And I mean that as a serious inquiry, not just a Did you spill my pint? question. At the moment the sole significant use of TPMs is Bitlocker, which uses it as little more than a PIN-protected USB memory key and even then functions just as well without it. To take a really simple usage case, how would you: - Generate a public/private key pair and use it to sign email (PGP, S/MIME, take your pick)? I had this working using openCryptoki, the trousers TSS and Mozilla Thunderbird on openSUSE Linux. If the setup instructions aren't in the various readmes of those projects I can help you set it up if you'd like. - As above, but send the public portion of the key to someone and use the private portion to decrypt incoming email? A simple PKCS#11 app to extract the public key is all that's needed with the above tools. (for extra points, prove that it's workable by implementing it using an actual TPM to send and receive email with it, which given the hit-and-miss Done. :-) Last time I tested this it worked fine... Circa 2006... Kent functionality and implementation quality of TPMs is more or less a required second step). I've implemented PGP email using a Fortezza card (which is surely the very last thing it was ever intended for), but not using a TPM... Mark Ryan presented a plausible use case that is not DRM: http://www.cs.bham.ac.uk/~mdr/research/projects/08-tpmFunc/. This use is like the joke about the dancing bear, the amazing thing isn't the quality of the dancing but the fact that the bear can dance at all :-). It's an impressive piece of lateral thinking, but I can't see people rushing out to buy TPM-enabled PCs for this. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: full-disk subversion standards released
On Thu, Mar 5, 2009 at 12:13 PM, Kent Yoder shpedoi...@gmail.com wrote: Hi Peter, Apart from the obvious fact that if the TPM is good for DRM then it is also good for protecting servers and the data on them, In which way, and for what sorts of protection? And I mean that as a serious inquiry, not just a Did you spill my pint? question. At the moment the sole significant use of TPMs is Bitlocker, which uses it as little more than a PIN-protected USB memory key and even then functions just as well without it. To take a really simple usage case, how would you: - Generate a public/private key pair and use it to sign email (PGP, S/MIME, take your pick)? I had this working using openCryptoki, the trousers TSS and Mozilla Thunderbird on openSUSE Linux. If the setup instructions aren't in the various readmes of those projects I can help you set it up if you'd like. - As above, but send the public portion of the key to someone and use the private portion to decrypt incoming email? A simple PKCS#11 app to extract the public key is all that's needed with the above tools. (for extra points, prove that it's workable by implementing it using an actual TPM to send and receive email with it, which given the hit-and-miss Done. :-) Last time I tested this it worked fine... Circa 2006..- The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Computer health certificate plan indistinguishable from Denial Of Service attack.
I'd love to know how they plan to validate my Linux boxes. OpenPTS [1] + TrouSerS [2] + Grub-IMA [3] + IMA [4] ;-) Kent [1] http://openpts.sourceforge.jp/ [2] http://trousers.sourceforge.net/ [3] http://sourceforge.jp/projects/openpts/wiki/GRUB-IMA [4] http://linux-ima.sourceforge.net/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
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
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
[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] 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
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
[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] 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
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
