Re: 307 digit number factored
Anne Lynn Wheeler wrote: it would be really great to make it an excuse to move away from offline paradigm to real online operation ... getting totally rid of the need for domain name certificates ... DNS serving up both ip-addresses and public keys in single operation. That can't happen until we make sure you can trust DNS, which in turn can't happen until we get a concrete proposal that has clearly defined goals and isn't braindead. As has been amply pointed out, it's not clear that DNSSEC will cut it anytime soon. (These days, the complaints even come with illustrations: http://www.matasano.com/log/772/a-case-against-dnssec-count-2-too-complicated-to-deploy/). -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Russian cyberwar against Estonia?
On 22 May 2007 14:51, Trei, Peter wrote: In fairness, its worth noting that the issue is also mixed up in Estonian electoral politics: http://news.bbc.co.uk/1/hi/world/europe/6645789.stm The timing of the electronic attacks, and the messages left by vandals, leave little doubt that the 'Bronze Soldier' affair is the motivating factor. Whether Russian Government agents were involved in the attacks is not proven, but certainly seems possible. Patriotic script-kiddies have been taking it upon themselves to contribute botnet-driven DDoSen to pretty much every international incident going over the past few years, from the US-vs-China hacker wars back in Code Red days, to the Arab-Israeli conflict, to ... well, everything really. The fact that there's a real diplomatic incident going on may well be their motivation, but it's not evidence that they are in any meaningful sense 'state actors'. Occam's razor suggests that since the script kiddies will do this /regardless/, i.e. spontaneously and unprovoked, there's no need to posit additional sources of DDoS deliberately organized by the government (though of course it doesn't exclude the possibility). Why get your hands dirty when some unpaid volunteer will provide you plausible (because truthful) deniability? Perhaps I should coin the phrase Useful Skiddiots! cheers, DaveK -- Can't think of a witty .sigline today - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
Ivan Krstić wrote: That can't happen until we make sure you can trust DNS, which in turn can't happen until we get a concrete proposal that has clearly defined goals and isn't braindead. As has been amply pointed out, it's not clear that DNSSEC will cut it anytime soon. A big part of the issue is the domain name certification authority has to trust the domain name infrastructure as to the true owner of the domain name ... when they are processing a domain name certificate application for certification (i.e. only the actual domain name owner on file with the domain name infrastructure should be able to apply for domain name certifications). The catch-22 is that the original idea behind domain name certificates were because of integrity issues with the domain name infrastructure. However, the domain name certification industry is dependent on the integrity of the domain name infrastructure in their domain name certification process. As a result they need to improve the integrity of the domain name infrastructure because their dependency on the domain name infrastructure in their process of certification. So one of the proposals (somewhat backed by the domain name certification authority industry) is that domain name owners place a public key on file when they register a domain name with the domain name infrastructure. They all future communication with the domain name infrastructure can be digitally signed ... and the domain name infrastructure verify the digital signature with the onfile public key. This is intended to help improve the integrity of the domain name infrastructure. However, it could also offer benefits to the domain name certification authority industry. The domain name certification authority industry could also then start requiring that domain name certification applications also be digitally signed. The the domain name certification authority industry can do a real-time retrieval of the on-file public key to verify the domain name certification application digital signatures. This provides for turning a time-consuming, error-prone, and expensive identification process into a much simpler, reliable, and less expensive authentication process (enormous benefits for the domain name certification authority industry). The issue is that if the domain name certification authority industry are somewhat two fold: 1) the original justification for domain name certification involved integrity issues with the domain name infrastructure. improving the integrity of the domain name infrastructure would reduce the original justification for having domain name certification 2) if the domain name certification authority industry could start relying on real-time retrieval of public keys ... then possibly the rest of the world could also ... eliminating the need for domain name infrastructure. some collected catch-22 posts http://www.garlic.com/~lynn/subpubkey.html#catch22 long ago and far away, we had been called in to consult with this small client/server startup that wanted to do payment transactions and had this technology called SSL. In addition to doing stuff about working out the payment transaction operation we also had to do a lot of stuff with end-to-end business process investigation of these new business operations called certification authorities. Since then, this has frequently come to be referred to as electronic commerce. some old posts http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 and collection of posts mentioning payment processing and payment gateway http://www.garlic.com/~lynn/subnetworkhtml#gateway Now, the original SSL infrastructure was to verify that the URL that the user entered (into the browser) corresponded to the website that the browser was talking to (i.e. the website that the user thought they were talking to was the website they were actually talking to). However, most electronic commerce sites fairly quickly found that SSL was costing them something like 90percent of their thruput. The result was that most websites transitioned to no longer using SSL for the initial user connection but reserved just for the payment process (to hide the account number information). Now the user clicks on a button (provided by the webserver) which generates a URL (provided by the webserver). Now instead of checking the URL provided by the user against the webserver ... most use of SSL now checks the URL provided by the webserver against the webserver (invalidating the original SSL security assumptions). lots of past posts about ssl digital certificate infrastructure http://www.garlic.com/~lynn/subpubkey.html#sslcert so it could be claimed that the way that the currently deployed SSL for the electronic commerce infrastructure doesn't really cut it either ... it is somewhat a case of the emperor's new clothes ... and the integrity of the domain name infrastructure has to be improved in any case, since it is the
Re: 307 digit number factored
somewhere over the yrs the term certification authority was truncated to certificate authority ... along with some impression that certificates are being sold (as opposed to certification processes). When I pay $14.95 for a certificate, with the investigation of my bona fides limited to clicking through a link in an e-mail, and answering the phone*, entering a short code, and responding to a request to state your name**, it sure seems to me like I'm buying a certificate. The only reason I do it is that for that price it's cheaper than explaining to people why the threat that web certs defend against is stupid. getting totally rid of the need for domain name certificates ... DNS serving up both ip-addresses and public keys in single operation. DKIM does that, you can get the MX and verification key for a domain. But I wouldn't say that was a security improvement except insofar as it makes the process easy enough that people are more likely to use it than they are the more cumbersome systems like S/MIME. R's, John * - any old phone, I've had them call random VoIP numbers in other continents that I was experimenting with ** - so of course I say your name. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
For the math weenies on the list, see the full announcement here: http://listserv.nodak.edu/cgi-bin/wa.exe?A2=ind0705L=nmbrthryT=0P=1019. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
Victor Duchovni [EMAIL PROTECTED] writes: As 1024 RSA keys are not a major risk *today*, I would go further and say that for most applications of PKCs/PKI today, 1024- bit RSA keys are not a risk at all, or more specifically that on a scale of risk they're so far down the list that they're close to negligible. As numerous security HCI studies have shown, user comprehension of PKI is close to zero percent, which means that the security effectiveness of the same is also close to zero. As the multi-billion dollar phishing industry has ably demonstrated, the bad guys are more than aware of this too. So going from x- bit RSA to y-bit RSA on a component with close to zero-percent effectiveness is... well, I'll let you do the maths. Until the hundred other constituent parts required to secure something like web browsing are fixed, changing the key size is just pointless posturing, since it's not fixing anything that anyone is attacking. Once all the other bits are fixed and working as intended, then we can go back to debating whether length is more important than width in key sizes. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
* Victor Duchovni: That's good of you not to expect it, given that zero of the major CAs seem to support ECC certs today, and even if they did, those certs would not work in IE on XP. We are not talking about this year or next of course. My estimate is that Postfix releases designed this year, ship next year, are picked up by some O/S vendors the year after and shipped perhaps a year after that, then customers take a few years to upgrade, ... So for some users Postfix 2.5 will be their MTA upgrade in 2011 or later. So we need to anticipate future demand by a few years to be current at the time that users begin to use the software. But no one is issuing certificates which are suitable for use with SMTP (in the sense that the CA provides a security benefit). As far as I know, there isn't even a way to store mail routing information in X.509 certificates. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
