On Tue, Jan 3, 2012 at 5:12 PM, Bennett Haselton <bennett at peacefire.org> wrote: >> >> The critical thing to remember is that in key auth the authenticating key never leaves the client system, rather an encrypted 'nonce' is sent (the nonce is encrypted by the authenticating key), which only the server, possessing the matching key to the authenticating key, can successfully decrypt. > Actually, the top answer at that link appears to say that the server > sends the nonce to the client, and only the client can successfully > decrypt it. (Is that what you meant?) >> This effectively gives full bit-strength for the whole key; 1024 bits of entropy, if you will, for 1024 bit keys. This would appear to require a 157 character random password chosen from all 95 ASCII printable characters to match, in terms of bit entropy. > Yes, I've acknowledged that whether you think 1024 bits is more secure > than 72 bits depends on how literally you mean "more secure". If the > odds of an attack working in the next year are 1 in 10^10, you can > reduce the odds to 1 in 10^20, which in a strict mathematical sense may > make you more secure, but -- not really. You are still speculating about the wrong things, though. Is your password written down? Has anyone ever been in the same room when you typed it? Could a key logger have been installed anywhere you typed it? And for the brute-force side of things, these may be done from a large number of sources to a large number of targets. They may be too slow to break any specific target but repeat it enough and you'll match something, somewhere. Maybe you were just the lucky one that day - and if you used the same password on the other(s) they would be easy targets. > However, *then* you have to take into account the fact that, similarly, > the odds of a given machine being compromised by a man-in-the-middle > attack combined with cryptanalysis of the stream cipher, is *also* > overwhelmed by the probability of a break-in via an exploit in the > software it's running. I mean, do you think I'm incorrect about that? > Of the compromised machines on the Internet, what proportion do you > think were hacked via MITM-and-advanced-crypto, compared to exploits in > the services? Proportions don't matter. Unless you have something extremely valuable to make this machine a target or someone captured your password and connection destination it was probably a random hit of a random probe. It doesn't matter if they are likely to work or not, some do. > The problem with such "basic stuff" is that in any field, if there's no > way to directly test whether something has the desired effect or not, it > can become part of accepted "common sense" even if it's ineffective. If you have multiple layers of protection and look at your logs, you'll see what people are trying. And they keep trying it because it works... If you aren't looking at your logs there's not much use in speculating about what might be happening. > Case in point: in the *entire history of the Internet*, do you think > there's been a single attack that worked because squid was allowed to > listen on a non-standard port, that would have been blocked if squid had > been forced to listen on a standard port? Generalize that question to 'do you think attacks are helped by permitting applications to use ports the administrator didn't expect them to use' and the answer is clearly yes. There are certainly rogue trojans around that do who-knows-what on other connections while pretending to be your normal applications. -- Les Mikesell lesmikesell at gmail.com