Re: Five Theses on Security Protocols
On Sun, Aug 01, 2010 at 11:20:51PM +1200, Peter Gutmann wrote: But, if you query an online database, how do you authenticate its answer? If you use a key for that or SSL certificate, I see a chicken-and-egg problem. What's your threat model? My threat model is practice. I assume Perry assumed that you have some pre-established trust relationship with the online database. However, I do not see myself having much of those. Yes, my browser comes preloaded with a set of root certificates, but Verisign is as much a third party to me as any SSL protected website I want to visit. Anyway, suppose we do all trust Verisign. Then everybody needs its public key on their computers to safely communicate with it. How is this public key distributed? Just like those preloaded root certs in the browser? What if their key gets compromised? How do we revoke that key and get a new one? We still have all the same problems with the public key of our root of trust as we have with long-lived certificates. Perry says we should do online checks in such a case. So which online database can tell us if Verisign's public key is still good? Do we need multiple trusted online databases who can vouch for each other, and hope not all of them fail simultaneously? Another issue with online verification is the increase in traffic. Would Verisign like it if they get queried for a significant fraction of all the SSL connections that are made by all users in the world? -- Met vriendelijke groet / with kind regards, Guus Sliepen g...@sliepen.org signature.asc Description: Digital signature
Re: Is this the first ever practically-deployed use of a threshold scheme?
(In a threshold cryptosystem, the shares would be used in a protocol to perform the desired cryptographic operation [e.g., signing] without ever reconstructing the real secret.) Has real threshold cryptography never been used anywhere? Yes, the root key for the SET consortium was done this way. The technology was developed by Banker's Trust Electronic Commerce, which was spun off into a company called CertCo. They also had a method of re-splitting a key; think of a trade group that votes out one of the members without that entity's consent. The code to do all that was on the HSM cards. Both techniques are patented. CertCo failed and I don't know who ended up with the IP. (As a souvenir from the wind-down, I have a co-branded CertCo/Chrysalis HSM. :) /r$ -- STSM, WebSphere Appliance Architect https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: init.d/urandom : saving random-seed
On Aug 1, 2010, at 10:34 AM, Henrique de Moraes Holschuh wrote: (Please keep all CCs). On Sun, 01 Aug 2010, Jerry Leichter wrote: file might be reused: Stir in the date and time and anything else that might vary - even if it's readily guessable/detectable - along Well, yes, we have several *guessable* sources of variable data available during early userspace that we could use. We can also distill them through sha256. But it would add very little variation across reboots of the same box, and that variation is easily guessable I discussed this in the rest of my message. Apparently I wasn't explicit enough. Consider the overall situation. We have a large number of systems out there. They reboot here and there. Each of them saves their previous PRNG state, and uses it on reboot. Sometimes, the PRNG state is not saved, and a second reboot uses the same state. Attackers do *not* have access to the saved state. They *can*, however, observe the values produced by the PRNG. (In practice, they get a noisy, incomplete sampling through things like generated keys, but let's make the safe assumption that they see the complete stream.) Thus, they can easily check that a given system is generating the same sequence of values, so presumably didn't update its state. Thus, it will continue to produce the same values for a while (until it can gather enough entropy). Now consider the situation where a rebooting system stirs in the date and time, the MAC and IP addresses of the first couple of messages it sees, whatever. Given a properly implemented PRNG, the output stream will look nothing like the output stream it produced the last time around. (Flipping one bit of input to something like SHA-1 flips, on average, about half the output bits.) Sure, an attacker who *knew* the saved state could easily *guess* the low-entropy inputs, match what the system emits, and break security. But the problem here is entirely different: Recognizing that the stream it's seeing is the result of a small tweak applied to an unknown previous state. If someone an show a solution to that problem, I'll withdraw my suggestion. But I doubt any simple attack of this sort exists. If an attacker can't recognize systems that are re-using state, it has to try attacking all of them. Think about what that attack looks like. When the system works as it's supposed to, the state is saved over the reboot, so the reboot effectively never occurred. The extra guessable state makes no difference: In this situation, we're assuming that the PRNG is secure. When a restart does occur, the attacker is seeing two (or more) continuations from the same *unknown* internal state, using different guessable - assume known - small tweaks, and he must predict the future outputs. It's kind of a related-key attack, and doesn't look easy. In fact, if the number of tweaked bits is small, it doesn't look like there's even enough information available to solve it in principle. (With enough reboots without a state update, the bits accumulate.) But there are likely situations it's plausible. In those - use a true RNG. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Is this the first ever practically-deployed use of a threshold scheme?
Thierry Moreau thierry.mor...@connotech.com writes: With the next key generation for DNS root KSK signature key, ICANN may have an opportunity to improve their procedure. What they do will really depend on what their threat model is. I suspect that in this case their single biggest threat was lack of display of sufficient due diligence, thus all the security calisthenics (remember the 1990s Clipper key escrow procedures, which involved things like having keys generated on a laptop in a vault with the laptop optionally being destroyed afterwards, just another type of security theatre to reassure users). Compare that with the former mechanism for backing up the Thawte root key, which was to keep it on a floppy disk in Mark Shuttleworth's sock drawer because no-one would ever look for it there. Another example of this is the transport of an 1894-S dime (worth just under 2 million dollars) across the US, which was achieved by having someone dress in somewhat grubby clothes and fly across the country in cattle class with the slabbed coin in his pocket, because no-one would imagine that some random passenger on a random flight would be carrying a ~$2M coin. So as this becomes more and more routine I suspect the accompanying calisthenics will become less impressive. (What would you do with the DNSSEC root key if you had it? There are many vastly easier attack vectors to exploit than trying to use it, and even if you did go to the effort of employing it, it'd be obvious what was going on as soon as you used it and your fake signed data started appearing, c.f. the recent Realtek and JMicron key issues. So the only real threat from its loss seems to be acute embarassment for the people involved, thus the due-diligence exercise). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On 07/28/2010 08:55 AM, Anne Lynn Wheeler wrote: disclaimer: the inventor of domain name infrastructure did a stint at the science center a decade earlier ... working on various and sundry projects. other public key science center trivia; former RSA CEO also at science center ... following recent entry from his blog: http://smartphonestechnologyandbusinessapps.blogspot.com/2010/05/bob-creasy-invented-virtual-machines-on.html lots of past posts mentioning science center, 4th flr, 545 tech sq http://www.garlic.com/~lynn/subtopic.html#545tech a couple old emails from 1981 ... discussing a certificate-less, PGP-like implementation for the internal network http://www.garlic.com/~lynn/2007d.html#email810506 http://www.garlic.com/~lynn/2006w.html#email810515 ... aka the internal network was larger than the arpanet/internet from just about the beginning until sometime late '85 or early '86. one big difference from arpanet/internet was corporation required all links to be encrypted ... and in the mid-80s there was the claim that the internal network had over half of all hardware link encryptors in the world ... only practical solution at the time. I was running multiple T1 links in the period ... and DES-encryption processing for sustained full-duplex traffic from a single T1 link was more than enough to consume multiple mainframe processors. old email on the subject (regarding doing some benchmarking of DES software encrypt/decrypt) http://www.garlic.com/~lynn/2006n.html#email841115 past posts mentioning internal network http://www.garlic.com/~lynn/subnetwork.html#internalnet -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
