Re: Who's afraid of Mallory Wolf?
- Original Message - From: Ed Gerck [EMAIL PROTECTED] To: Jeroen C. van Gelderen [EMAIL PROTECTED] Cc: Ian Grigg [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, March 24, 2003 11:20 PM Subject: Re: Who's afraid of Mallory Wolf? Jeroen C. van Gelderen wrote: 1. Presently 1% of Internet traffic is protected by SSL against MITM and eavesdropping. 2. 99% of Internet traffic is not protected at all. I'm sorry, but no. The bug in MSIE, that prevented the correct processing of cert path restraints and which led to easy MITM attacks, has been fixed for some time now. Consulting browser statistics sites will show that the MSIE update in question, fueled by the need for other security updates, is making good progress. Their is another bug that has not been fixed by MS that allows signed but invalid certificates to be used to MITM the browser as well with no notification. 3. A significant portion of the 99% could benefit from protection against eavesdropping but has no need for MITM protection. (This is a priori a truth, or the traffic would be secured with SSL today or not exist.) I'm sorry but the a priori truth above is false . Ignorance about the flaw, that is now fixed, and the need to do a LAN attack (if you want not to mess with the DNS) have helped avert a major public exploit. The hole is now fixed and the logic fails for this reason as well. 4. The SSL infrastructure (the combination of browsers, servers and the protocol) does not allow the use of SSL for privacy protection only. AnonDH is not supported by browsers and self-signed certificates as a workaround don't work well either. There is a good reason -- MITM. AnonDH and self-signed certs cannot prevent MITM. 5. The reason for (4) is that the MITM attack is overrated. People refuse to provide the privacy protection because it doesn't protect against MITM. Even though MITM is not a realistic attack (2), (3). But it is, please see the spoof/MITM method in my previous post. Which, BTW, is rather old info in some circles (3 years?) and is easy to do by script kiddies with no knowledge about anything we are talking here -- they can simply do it. Anyone can do it. (That is not to say that (1) can do without MITM protection. I suspect that IanG agrees with this even though his post seemed to indicate the contrary.) I think Ian's post, with all due respect to Ian, reflects a misconception about cert validation. The misconception is that cert validation can be provided as an absolute reference -- it cannot. The *mathematical* reasons are explained in the paper I cited. This misconception was discussed some 6 years in the ssl-talk list and other lists, and clarified at the time -- please see the archives. It was good, however, to post this again and, again, to allow this to be clarified. 6. What is needed is a system that allows hassle-free, incremental deployment of privacy-protecting crypto without people whining about MITM protection. You are asking for the same thing that was asked, and answered, 6 years ago in the ssl-talk and other lists. There is a way to do it and the way is not self-signed certs or SSL AnonDH. Now, this is could be achieved by enabling AnonDH in the SSL infrastructure and making sure that the 'lock icon' is *not* displayed when AnonDH is in effect. Also, servers should enable and support AnonDH by default, unless disabled for performance reasons. Problem -- SSL AnonDH cannot prevent MITM. The solution is not to deny the problem and ask who cares about MITM? Ed Gerck wrote: BTW, this is NOT the way to make paying for CA certs go away. A technically correct way to do away with CA certs and yet avoid MITM has been demonstrated to *exist* (not by construction) in 1997, in what was called intrinsic certification -- please see www.mcg.org.br/cie.htm Phew, that is a lot of pages to read (40?). Its also rather though material for me to digest. Do you have something like an example approach written up? I couldn't find anything on the site that did not require study. ;-) If anyone comes across a way to explain it, that does not require study, please let me know and I'll post it. OTOH, some practical code is being developed, and has been sucessfully tested in the past 3 years with up to 300,000 simultaneous users, which may provide the example you ask for. Please write to me privately if you'd like to use it. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
So far, as I see it, this is not an issue of specific SSL protocol, but of unrestrictive browser to user interfacing. The only MITM attacks that have been practical valid attacks as of lately were specific to microsoft browser issues when interfacing with SSL. On another note, MITM attacks on SSL, is strictly a user education issue. How many users know what a fingerprint is, or what it is designed for? Unless we either force the browser to be that strict and never interface with unseen or untrusted fingerprints (impractical), what can you do? - Original Message - From: Jeroen C. van Gelderen [EMAIL PROTECTED] To: Peter Clay [EMAIL PROTECTED] Cc: Ian Grigg [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, March 24, 2003 4:50 PM Subject: Re: Who's afraid of Mallory Wolf? On Monday, Mar 24, 2003, at 11:37 US/Eastern, Peter Clay wrote: On Sun, 23 Mar 2003, Ian Grigg wrote: Consider this simple fact: There has been no MITM attack, in the lifetime of the Internet, that has recorded or documented the acquisition and fraudulent use of a credit card (CC). (Over any Internet medium.) How do you view attacks based on tricking people into going to a site which claims to be affiliated with e.g. Ebay or Paypal, getting them to enter their login information as usual, and using that to steal money? It's not a pure MITM attack, but the current system at least makes it possible for people to verify with the certificate whether or not the site is a spoof. Correct. On the other hand, in a lot of cases people cannot be expected to do the verification. This shows in the number of people that can be tricked into being spoofed out of their passwords, even when certificates are deployed. That is not an argument against certificates though, it is (partially) an argument against broken user interfaces. Just out of interest, do you have an economic cost/benefit analysis for the widespread deployment of gratuitous encryption? What makes you say it is gratuitous? Or: how can you state my privacy is gratuitous? It's just not that important. If your browsing privacy is important, you're prepared to click through the alarming messages. If the value of privacy is less than the tiny cost of clicking accept this certificate forever for each site, then it's not a convincing argument for exposing people who don't understand crypto to the risk of MITM. This is illogical. Even if a server operator would prefer to allow unauthenticated encryption, he cannot do so without annoying 90% of his customers because they too will be getting these alarming messages. In general, if my browsing privacy is important to me and the server operator is willing to accomodate me, he cannot do so. This however still does not constitute an argument against certificates. It can be morphed as an argument against browsers not supporting Anonymous-DH. (Note that I'm favoring treating sites offering ADH the same as sites offering a certificate. Each offers different functionality which should be distinguishable in the GUI.) Cheers, -J -- Jeroen C. van Gelderen - [EMAIL PROTECTED] The python has, and I fib no fibs, 318 pairs of ribs. In stating this I place reliance On a séance with one who died for science. This figure is sworn to and attested; He counted them while being digested. -- Ogden Nash - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Diffie-Hellman 128 bit
Nope, it uses 128 bit primes. I'm trying to compute the discrete logarithm and they are staying within a 128 bit GF(p) field. Sickening. Thnx. Lance - Original Message - From: Anton Stiglic [EMAIL PROTECTED] To: NOP [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, March 14, 2003 8:10 AM Subject: Re: Diffie-Hellman 128 bit - Original Message - From: NOP [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 13, 2003 4:48 PM Subject: Diffie-Hellman 128 bit I am looking at attacks on Diffie-Hellman. The protocol implementation I'm looking at designed their diffie-hellman using 128 bit primes (generated each time, yet P-1/2 will be a prime, so no go on pohlig-hellman attack), 128-bit prime DH would be trivially breakable, maybe you mean that it uses128-bit secret keys (and a larger prime, such as 512-bit prime at least)? In any case, you can probably get all the information you are looking for in this manuscript: http://crypto.cs.mcgill.ca/~stiglic/Papers/dhfull.pdf Cheers! --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Diffie-Hellman 128 bit
Well, I'm attacking a protocol, I know the rules of DH parameters, and the issue here is I'm trying to solve x, brute forcing that in the 128 bit range can be difficult, and x doesn't have to be a prime. (a = g^x mod P). Their primes are 128 bit primes, as well as their pubkeys, I've done some tests on their prime, and all perform under this method of (p-1)/2 = prime. This eliminates the pohlig-hellman discrete logarithm attack, but I'm trying to learn the Gaussian integer method. Lance James - Original Message - From: Derek Atkins [EMAIL PROTECTED] To: NOP [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, March 14, 2003 10:53 AM Subject: Re: Diffie-Hellman 128 bit Hi, I'm sorry to inform you, but a brute-force attack on a 128-bit prime is simple to mount. I don't think I can estimate the length of time to attack a prime of this length, but it wouldn't be very long. Consider that 425 bits is only about 4KMY (Kilo-MIP-Years) -- with todays 2KM+ processors you're probably talking about a week or less to crack it. Also, there aren't THAT many strong 128-bit primes. If you're using these numbers for real data (even if ephemeral), I would suggest using at least 512-bit ephemeral DH Primes.. But then you need some way to securely AGREE upon the ephemeral prime. How do you intend to prevent an attacker from forcing you to agree to a prime that it's already solved? -derek NOP [EMAIL PROTECTED] writes: I am looking at attacks on Diffie-Hellman. The protocol implementation I'm looking at designed their diffie-hellman using 128 bit primes (generated each time, yet P-1/2 will be a prime, so no go on pohlig-hellman attack), so what attacks are there that I can look at to come up with either the logarithm x from (a=g^x mod p) or the session key that is calculated. A brute force wouldn't work, unless I know the starting range. Are there any realistic attacks on DH parameters of this size, or is theoretically based on financial computation attacks? Thanks for your time. Lance James - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Diffie-Hellman 128 bit
I am looking at attacks on Diffie-Hellman. The protocol implementation I'm looking at designed their diffie-hellman using 128 bit primes (generated each time, yet P-1/2 will be a prime, so no go on pohlig-hellman attack), so what attacks are there that I can look at to come up with either the logarithm x from (a=g^x mod p) or the session key that is calculated. A brute force wouldn't work, unless I know the starting range. Are there any realistic attacks on DH parameters of this size, or is theoretically based on financial computation attacks? Thanks for your time. Lance James - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
