Re: Another entry in the internet security hall of shame....
James A. Donald wrote: But does not, in fact, prevent. Let me rephrase that. Are we now at a point where we must admit that PKI isn't going to happen for the Web and that we therefore must face the rewriting of an unknown (but presumably large) number of lines of code to accomodate PSKs? If that's so, I believe that PSKs will have deployment problems as large as PKI's that will prevent their widespread acceptance. That's because PSKs (as I have understood them) have storage and management issues that CA certificates don't have, four of which are that there will be a lot more PSKs than CA certificates, that you can't preinstall them in browsers, that the issue of how to exchange PSKs securely in the first place is left as an exercise for the reader (good luck!), and that there is a revocation problem. To resolve any of those issues, code will need to be written, both on the client side and on the server side (except for the secure exchange of PSKs, which is IMHO unresolvable without changes to the business workflow). The client side code is manageable, because the code will be used by many people so that it may be worthwhile to spend the effort. But the server side? There are many more server applications than there are different Web browsers, and each one would have to be changed. At the very least, they'd need an administrative interface to enter and delete PSKs. That means that supporting PSKs is going to cost the businesses money (both to change their code and to change their workflow), money that they'd rather not spend on something that they probably perceive as the customer's (i.e., not their) problem, namely phishing. Some German banks put warnings on their web pages that they'll never ask you for private information such as passwords. SaarLB (http://www.saarlb.de) even urges you to check the certificate fingerprint and provides well-written instructions on how to do that. In return, they'll assume no responsibility if someone phishes your PIN and TANs. They might, out of goodwill, reimburse you. Then again, they might not. I believe that SaarLB could win in court. So where is the incentive for SaarLB to spend the money for PSK support? Fun, Stephan begin:vcard fn:Stephan Neuhaus n:Neuhaus;Stephan org;quoted-printable:Universit=C3=A4t des Saarlandes;Department of Informatics adr;quoted-printable:;;Postfach 15 11 50;Saarbr=C3=BCcken;;66041;Germany email;internet:[EMAIL PROTECTED] title:Researcher tel;work:+49-681/302-64018 tel;fax:+49-681/302-64012 x-mozilla-html:FALSE url:http://www.st.cs.uni-sb.de/~neuhaus version:2.1 end:vcard
Re: Fwd: Tor security advisory: DH handshake flaw
Simon Josefsson wrote: Btw, could you describe the threat scenario where you believe this test would be useful? Well, that's an interesting question. I have to admit that I am no longer sure there is any point. If people do an appropriate number of rounds of Miller-Rabin whenever they're handed a number that is supposedly prime, they're pretty safe. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fwd: Tor security advisory: DH handshake flaw
Werner Koch [EMAIL PROTECTED] writes: On Mon, 29 Aug 2005 17:32:47 +0200, Simon Josefsson said: which are Fermat pseudoprime in every base. Some applications, e.g. Libgcrypt used by GnuPG, use Fermat tests, so if you have control of the random number generator, I believe you could make GnuPG believe it has found a prime when it only found a Carmichael number. 5 Rabin-Miller tests using random bases are run after a passed Fermat test. If you control the random number generator, you control which Miller-Rabin bases that are used too. Of course, it must be realized that the threat scenario here is slightly obscure. The scenario I have been thinking about is when an attacker has gained control of the hardware or kernel. The attacker might then be able to see when a crypto library requests randomness, and return carefully constructed data to fool the user. The constructed data should be so the RSA/DH parameters become weak [for the attacker]. The attacker may not be in a position to send the generated prime back home over the network, and doing that may also be detected by firewalls. The target system might not even be networked. Designing this fake random number generator is not trivial, and must likely be done separately for each crypto library that is used. If software only used prime numbers that came with a prime certificate, you combat this attack. Too bad you can't mathematically certify that real randomness was used in choosing the prime too. Although perhaps you get pretty close with algorithms that both generate a prime and a prime certificate in one go. Regards, Simon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
At 9:39 AM +0200 9/1/05, Stephan Neuhaus wrote: Are we now at a point where we must admit that PKI isn't going to happen s/happen/happen in a widely useful fashion/ for the Web s/Web/Web and email/ and that we therefore must face the rewriting of an unknown (but presumably large) number of lines of code to accomodate PSKs? Self-signed certificates that are fingerprinted out-of-band are better than PSKs in some situations, worse in others. If that's so, I believe that PSKs will have deployment problems as large as PKI's that will prevent their widespread acceptance. Bingo. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
If I may inject my humble opinion(that isn't necessarily a response to this peticular email), I may not be as informed as some but While I admit that PKI is flawed, I don't see anyway that PSK could used effectively. How are PSKs going to be shared in a secure way? are we talking about generating a new key for every connection? if so how do you validate the key? if not, how do you validate that the key hasn't been compromised by someone who put up a phishing site? In my opinion, PSK has the same problems as all symmetric encryption, its great if you can share the secret securely, but distribution to the masses makes it infeasible. >From the way I see it, if site logins were done using a client certificate, like the USPS electronic postmark site allows and should enforce, then the security issues wouldn't be issues, as there would be nothing usable handed off to an attacker. Furthermore the site could be sure of the users identity, something none of the other solutions I have seen address. -- Pengdows eMail Signature Alaric Dailey Everyone deserves privacy. Thawte Web of Trust Notary CAcert Web of Trust Assurer Notary Public ATTENTION USERS OF MICROSOFT OUTLOOK AN MICROSOFT OUTLOOK EXPRESS: Some versions of these products have trouble replying to digitally signed emails, like this one. For more information on this error, and how to fix it please visit Mark Nobles website here. Stephan Neuhaus wrote: James A. Donald wrote: But does not, in fact, prevent. Let me rephrase that. Are we now at a point where we must admit that PKI isn't going to happen for the Web and that we therefore must face the rewriting of an unknown (but presumably large) number of lines of code to accomodate PSKs? If that's so, I believe that PSKs will have deployment problems as large as PKI's that will prevent their widespread acceptance. That's because PSKs (as I have understood them) have storage and management issues that CA certificates don't have, four of which are that there will be a lot more PSKs than CA certificates, that you can't preinstall them in browsers, that the issue of how to exchange PSKs securely in the first place is left as an exercise for the reader (good luck!), and that there is a revocation problem. To resolve any of those issues, code will need to be written, both on the client side and on the server side (except for the secure exchange of PSKs, which is IMHO unresolvable without changes to the business workflow). The client side code is manageable, because the code will be used by many people so that it may be worthwhile to spend the effort. But the server side? There are many more server applications than there are different Web browsers, and each one would have to be changed. At the very least, they'd need an administrative interface to enter and delete PSKs. That means that supporting PSKs is going to cost the businesses money (both to change their code and to change their workflow), money that they'd rather not spend on something that they probably perceive as the customer's (i.e., not their) problem, namely phishing. Some German banks put warnings on their web pages that they'll never ask you for private information such as passwords. SaarLB (http://www.saarlb.de) even urges you to check the certificate fingerprint and provides well-written instructions on how to do that. In return, they'll assume no responsibility if someone phishes your PIN and TANs. They might, out of goodwill, reimburse you. Then again, they might not. I believe that SaarLB could win in court. So where is the incentive for SaarLB to spend the money for PSK support? Fun, Stephan smime.p7s Description: S/MIME Cryptographic Signature
Re: Another entry in the internet security hall of shame....
Alaric Dailey wrote: If I may inject my humble opinion(that isn't necessarily a response to this peticular email), I may not be as informed as some but While I admit that PKI is flawed, I don't see anyway that PSK could used effectively. How are PSKs going to be shared in a secure way? are we talking about generating a new key for every connection? if so how do you validate the key? if not, how do you validate that the key hasn't been compromised by someone who put up a phishing site? on the business/server side ... where x.509 identity certificates represent horrible privacy and liability issues ... and they've migrated to relying-party-only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo by definition, the institution needs to have already registered the clients public key ... in order to even issue a relying-party-only certificate ... they client/customers public key has been preshared (otherwise it would have been impossible for the institution to have issued the certifivate). at this point it is trivial to demonstrate that the issuing of the relying-party-only certificate is redundant and superfluous ... since by definition the institution has the PSK. so if you look at existing business process where pre-shared passwords are part of an authentication administration infrastructure that is integrated with the permissions and authorization administrative infrastructure ... say like either radius or kerberos http://www.garlic.com/~lynn/subpubkey.html#radius http://www.garlic.com/~lynn/subpubkey.html#kerberos it is possible to register public keys in place of password, retaining the existing business process and integrated administration of authentication and authorization. one of the issues when we started dealing with this small client/server startup that wanted to do payments on their server platform http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 had this new thing called SSL which were dependent on PKI, certification authorities, and digital certificates. As part of that effort, we had to do various kinds of business process and end-to-end audits of these things called certification authorities. There was a lot of discussion in these audits about certification authorities having very little to do with security and technology ... and primarily involved in a traditional service operation with loads of administrative work. One of the characteristics of businesses that have existing relationship management administrative relationship management operations ... like financial institutions with accounts or business with accounts payable and accounts billable or ISPs ... is that they have tried to provide some amount of administrative scaleup and integrity to the operation. Frequently it is possible to show a trivial toy PKI demo as an add-on w/o impacting the core authentication and authorization business processes. The big expenses quickly dawns on them when it starts to appear that PKI operation might have some impact on real business operations. At that point of time, it becomes quickly apparent that any full-scale PKI authentication infrastructure deployment will have an enormous cost duplication (especially after there has been possibly scores of years developing scaleable and integrated authentication and authorization infrastructures). At that point, the ongoing duplicate PKI operational costs totally dominate ... any trivial software technology deployment issue. Part of the issue is that the promise of having x.509 identity certificates groslly overloaded with enormous amounts of privacy information along with authorization and permissions ... has been shown to be false. That the organization isn't able to use the deployment of a X.509 PKI operation (with the digital certificates containing enormous amounts or privacy and senstive information) to eliminate their existing integrated relationship management and administrative infrastructure costs ... it possible turns out to be possibly doubling the actual business costs (in any sort of full-scale production deployment used for actual business purposes.). It may actually be worse than doubling ... the basic PKI administrative infrastructure may be replicated ... doubling the costs ... however the actual costs may be tripled if the existing production business operation and the replicated PKI administrative operation then has to be kept in sync. From a business/server standpoint ... upgrading an existing integrated authentication/authorization/permission infrastructure to use digital signature authentication with public key registration ... conforms to existing business practices and doesn't introduce duplicate and unnecessary administrative operation. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
