Re: browser vendors and CAs agreeing on high-assurance certificates
James A. Donald [EMAIL PROTECTED] writes: But is what they are doing wrong? The users? No, not really, in that given the extensive conditioning that they've been subject to, they're doing the logical thing, which is not paying any attention to certificates. That's why I've been taking the (apparently somewhat radical) view that PKI in browsers is a lost cause - apart from a minute segment of hardcore geeks, neither users nor web site admins either understand it or care about it, and no amount of frantic turd polishing will save us any more because it's about ten years too late for that - this approach has been about as effective as Just say no has for STD's and drugs. That's why I've been advocating alternative measures like mutual challenge- response authentication, it's definitely still got its problems but it's nothing like the mess we're in at the moment. PKI in browsers has had 10 years to start working and has failed completely, how many more years are we going to keep diligently polishing away before we start looking at alternative approaches? Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
2005 in review - The Year I lost my Identity
Ian Grigg's blog has a neat tongue-in-cheek review of the year in security. Here's a sample: Browser manufacturers have moved slightly faster than your average glacier. Microsoft moved forward by announcing that phishing was a browser problem (Mozilla and KDE followed 8 months later), and again by putting some tools into the IE7 release. Another big step forward was announcing the switch-off of SSL v2. But Microsoft also moved backwards one step IMO by going for the shared database of phishing alerts idea pioneered by Netcraft. Computer scientists and security gurus are still scratching their heads over how that is ever going to work, given that it never worked the other several hundred times we tried it. There's more there, definitely worth a read: https://www.financialcryptography.com/mt/archives/000588.html Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A small editorial about recent events.
You know, as a security person, I say all the time that the greatest threat is internal threat, not external threat. In my day job, I/we make surveillance tools to prevent data threat from materializing, and to quench it if it does anyhow. I tell clients all day every day that when the opponent can attack location independently, and likely without self identification, your only choice is pre-emption, which requires intell, which requires surveillance, which requires listening posts. And I'm just talking about intellectual property in the Fortune 1000, not the freaking country. --dan, who doesn't like reality any more - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A small editorial about recent events.
David G. Koontz wrote: Yet President Bush as publicly stated it requires a court order to wiretap: Secondly, there are such things as roving wiretaps. Now, by the way, any time you hear the United States government talking about wiretap, it requires -- a wiretap requires a court order. Nothing has changed, by the way. When we're talking about chasing down terrorists, we're talking about getting a court order before we do so. It's important for our fellow citizens to understand, when you think Patriot Act, constitutional guarantees are in place when it comes to doing what is necessary to protect our homeland, because we value the Constitution. http://www.whitehouse.gov/news/releases/2004/04/20040420-2.html Bush didn't say it always requires a court order to wiretap. He said, any time you hear . . . a wiretap requires at court order. So, when don't hear the government talking about a wiretap, the wiretap doesn't require a court order. And he used the present tense. So, he didn't mean . . . any time you hear . . . required a court order. And if you think these by the way words weren't carefully chosen, see the care with which Bush clarified the antecedent of it, so his listeners would not be left with the impression that it requires a court order to hear the US Government talk about a wiretap. When you take Bush at his word (every carefully chosen word) its easy to see how little he cares for things like civil liberties and the rule of law. -Dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RNG quality verification
Philipp =?utf-8?q?G=C3=BChring?= [EMAIL PROTECTED] writes: What is wrong with the following black-box test? * Open browser * Go to a dummy CA's website * Let the browser generate a keypair through the keygen or cenroll.dll * Import the generated certificate * Backup the certificate together with the private key into a PKCS#12 container * Extract the private key from the backup * Extract p and q from the private key * Extract the random parts of p and q (strip off the first and the last bit) * Automate the previous steps with some GUI-Automation system * Concatenate all random bits from all the keypairs together * Do the usual statistical tests with the random bits How would this differentiate between keygen for which the PRNG is SHA1( get_thermal_noise() ) and one where it's SHA1( counter++ )? Or one where it's get_constant_value() and you take the counter++ -th primes as p and q? Or one where ...? In addition the PRNG input to the keygen process has no bearing on the form of the primes generated, look at the IPsec DH primes with their long strings of 1 bits for an example, they'd fail a statistical test because they've been specially constructed to have a certain form, but that makes them stronger, not weaker. Thus both David Wagner's and my comments that the people asking this question/setting this requirement don't understand the problem. So if you want a solution to something originating at the bureaucratic layer, you need to provide the solution at the bureaucratic layer. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RNG quality verification
Hi Peter, Easily solveable bureaucratic problems are much simpler than unsolveable mathematical ones. Perhaps there is some mis-understanding, but I am getting worried that the common conception seems to be that it is an unsolveable problem. What is wrong with the following black-box test? * Open browser * Go to a dummy CA´s website * Let the browser generate a keypair through the keygen or cenroll.dll * Import the generated certificate * Backup the certificate together with the private key into a PKCS#12 container * Extract the private key from the backup * Extract p and q from the private key * Extract the random parts of p and q (strip off the first and the last bit) * Automate the previous steps with some GUI-Automation system * Concatenate all random bits from all the keypairs together * Do the usual statistical tests with the random bits Is this a valid solution, or is the question of the proper usage of random numbers in certificate keying material really mathematically unsolveable? (I am not a RSA specialist yet, I tried to stay away from the bit-wise details and the mathematics, so I might be wrong) But I would really worry, if it is mathematically impossible to attestate the correct usage (to a certain extent, I know about the statistical limitations) of random numbers with the software I am using to get certificates. Best regards, Philipp Gühring - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificat es
| | But is what they are doing wrong? | | | | The users? No, not really, in that given the extensive conditioning that | | they've been subject to, they're doing the logical thing, which is not paying | | any attention to certificates. That's why I've been taking the (apparently | | somewhat radical) view that PKI in browsers is a lost cause - apart from a | | minute segment of hardcore geeks, neither users nor web site admins either | | understand it or care about it, and no amount of frantic turd polishing will | | save us any more because it's about ten years too late for that - this | | approach has been about as effective as Just say no has for STD's and drugs. | | That's why I've been advocating alternative measures like mutual challenge- | | response authentication, it's definitely still got its problems but it's | | nothing like the mess we're in at the moment. PKI in browsers has had 10 | | years to start working and has failed completely, how many more years are we | | going to keep diligently polishing away before we start looking at alternative | | approaches? | I agreed with your analysis when I read it - and then went on to my next mail | message, also from you, which refers to your retrospective on the year and had | a pointer to an page at financialcryptography. So ... I try to download the | page - using my trusty Netscape 3.01, which with tons of things turned off | (Java, Javascript, background images, autoloading of images) remains my | work-a-day browser, giving decent performance on an old Sun box. | | Well, guess what: | | Netscape and this server cannot communicate securely | because they have no common cryptographic algorithm(s). | | So ... we have the worst possible combination: A system that doesn't work, | which is forced on you even when you don't care about it (I can live with | the possibility that someone will do a MITM attack on my attempt to read your | article). | | Sigh. BTW, illustrating points made here, the cert is for financialcryptography.com but your link was to www.financialcryptography.com. So of course Firefox generated a warning -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Standard ways of PKCS #8 encryption without PKCS #5?
Does anyone know of any 'standard' [*] ways of encrypting private keys in the usual PKCS #8 format without using password-based encryption? It is obviously not hard to do, as you can stick whatever you like into the encryptionAlgorithm field, so it would be easy to specify an plain encryption algorithm OID (aes256-cbc, or whatever) plus an IV (and possibly a key check value and/or some optional key label fields). I'm sure this is not the first time someone has needed such a thing - any references would be useful. [*]: Standard in this case being at least one implementation/spec has it, and (preferably) it is reasonably secure/sane Thanks, Jack - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificates
On 12/23/05, Peter Gutmann [EMAIL PROTECTED] wrote: PKI in browsers has had 10 years to start working and has failed completely, how many more years are we going to keep diligently polishing away before we start looking at alternative approaches? There have been several long threads over on the cap-talk list the last few weeks about what to call (still not fully baked) web capability pointers such as WideWords and httpsy urls. The point in those discussions that I think is most relevant to this thread is the fact that there was only a very minor side discussion about the fact that all of these techniques for granting more fine grained permissions on the Web that are in the RD stage use SSL/TLS, but not PKI, and would very often toss up a certificate warning if you didn't pay the cert tax. The point was made that users have been so conditioned to ignore them or click on Ok in general, that that itself was not the biggest barrier to their (potential) future wide deployment, at least not in relation to other UI issues for their use. -David Mercer Tucson, AZ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RNG quality verification
In message [EMAIL PROTECTED], Philipp =?utf-8?q?G=C3=BChrin g?= writes: Hi Peter, Easily solveable bureaucratic problems are much simpler than unsolveable mathematical ones. Perhaps there is some mis-understanding, but I am getting worried that the common conception seems to be that it is an unsolveable problem. What is wrong with the following black-box test? * Open browser * Go to a dummy CA´s website * Let the browser generate a keypair through the keygen or cenroll.dll * Import the generated certificate * Backup the certificate together with the private key into a PKCS#12 container * Extract the private key from the backup * Extract p and q from the private key * Extract the random parts of p and q (strip off the first and the last bit) * Automate the previous steps with some GUI-Automation system * Concatenate all random bits from all the keypairs together * Do the usual statistical tests with the random bits Is this a valid solution, or is the question of the proper usage of random numbers in certificate keying material really mathematically unsolveable? (I am not a RSA specialist yet, I tried to stay away from the bit-wise details and the mathematics, so I might be wrong) But I would really worry, if it is mathematically impossible to attestate the correct usage (to a certain extent, I know about the statistical limitations) of random numbers with the software I am using to get certificates. It's really unsolvable, in several different ways. First -- you just cannot tell if a single number is random. At best, you can look at a large selection of numbers and see if they fit certain randomness tests. Even that isn't easy, though there are several packages that will help. The best-known one is DIEHARD; ask your favorite search engine for diehard random. However -- and it's a big however -- numbers that are random enough for statistical purposes are not necessarily good enough for cryptographic purposes. As several people have pointed out already, there are processes involving cryptographic algorithms that produce very random sequences, but are in fact deterministic to someone who knows a secret. In other words, if you don't control the generator, it's not possible to distinguish these two cases. In fact, any cipher or hash function whose output was easily distinguishable from a true- random source would be rejected by the cryptographic community. Furthermore, even if the generator is good, if the machine using the certificates has been compromised it doesn't matter, because the malware can steal the secret key. What this boils down to is that you either trust the endpoint or you don't. Finally, even if it were possible for you to verify that p and q were random, you *really* don't want to do that -- you *never* want to see users' secret keys, because that exposes the keys to danger and hence you to liability. Let me make an alternative suggestion. Pick two or three key generation packages -- as I recall, both Firefox and IE have such -- generate a lot of keys, and run them through DIEHARD. Then warn your users to use only approved mechanisms for generating their certificate requests -- you just can't do any better. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificat es
BTW, illustrating points made here, the cert is for financialcryptography.com but your link was to www.financialcryptography.com. So of course Firefox generated a warning Indeed and even if that gets fixed we still have to contend with: * the blog software can't handle the nature of a TLS site (internal problems like non-working trackbacks, internal links, posts, ...) * the cert has to be shared with 3 other sites * Firefox will still warn about it being a CAcert signed certificate * ... I'm sure there's more. Hopefully over the next year, the webserver (Apache) will be capable of doing the TLS extension for sharing certs so then it will be reasonable to upgrade. iang PS: SSL v2 must die! Wot, you mean you haven't turned it off in your browser yet? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A small editorial about recent events.
[EMAIL PROTECTED] writes: You know, as a security person, I say all the time that the greatest threat is internal threat, not external threat. In my day job, I/we make surveillance tools to prevent data threat from materializing, and to quench it if it does anyhow. I tell clients all day every day that when the opponent can attack location independently, and likely without self identification, your only choice is pre-emption, which requires intell, which requires surveillance, which requires listening posts. Are you saying we need to carefully surveil our government and pre-empt it from attacking us, or that our government should carefully surveil us and pre-empt us from attacking it? And I'm just talking about intellectual property in the Fortune 1000, not the freaking country. Let's hope society as a whole never resembles life inside the Fortune 1000 too closely. -- https://www.eff.org/about/staff/#chris_palmer pgpq538D5dQfM.pgp Description: PGP signature
