Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Jeffrey Goldberg Newsgroups: sci.crypt Subject: Re: Firefox improvements. Date: Tue, 20 Oct 2015 00:52:33 -0500 Lines: 66 Message-ID: References: <263cd$561a967a$d47876e2$46985@news.ziggo.nl> <83qm1bt725k3537qtlo1f58p8h0vkqd5jl@4ax.com> <9gbn1b5rqadqfo8klt3jc9fhsa84edvb1l@4ax.com> Reply-To: jeffrey+news@goldmark.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net 7diMmvlFQD60/NZS7YPHsA+WeYjsLAc3C/q3f0fJIyhO3iKX0A Cancel-Lock: sha1:QNpbc/hhNatRondSpri9raGSZa8= User-Agent: Unison/2.1.10 Xref: csiph.com sci.crypt:33071 On 2015-10-12 16:56:39 +0000, Richard Heathfield said: > On 12/10/15 17:47, Rich wrote: >> [Only posted to sci.crypt, as comp.lang.c and sci.electronics.design >> likely won't know what "AOB" means.] >> >> In sci.crypt Richard Heathfield wrote: >>>> And all brute force hacks try ALL keys. They do not discredit >>>> any, as you have. >> >>> All *valid* keys. Otherwise, all brute force attacks would have to >>> try infinitely many keys despite there being an upper limit on key >>> length, and that's obviously impossible. Brute force is a last resort >>> and takes *ages*, so any shortcuts that /can/ be applied /are/ >>> applied. Adversaries are not constrained by your desire for brute >>> force to be harder than it needs to be. >> >> I'm beginning to sense an alternate AOB here. >> >> "Brute force" is defined only his way, no other way, and "Eve" can only >> work by applying "his way" in reverse. > > > I was too slow in coming to that conclusion myself. I think I'll leave > it there. Yep. It was clear from early on that when he refused to acknolwedge basic facts of math that there was little reason to continue to engage with him. It's one thing to be wrong; it's another to persist in a verifiable mistake once it's been pointed out. But his nonesense did give me the opportunity to rant about things that I am particularly interested in, which is how humans create passwords in the face of rules/advice/restrictions and whether there are realistic ways to either side step the whole problem by eliminiting such passwords or by getting people to pick better ones for the ones that they do have to create. Underneath DLU#1's errors and stubborness is a grain of an intuition that if thought about clearly has some value: If you present people with restrictions like "must contain two digits", do you get them to pick better passwords despite the fact that you are actually restricting the password space? I think that in some cases the answer can reasonably be "yes". I actually think that that good intuition did underly his idiocy, but he clearly was unable to acknowledge any error in his original statement, so there was no way to isolate reasonable bit from the layers of BS he added to try to defend each of is bizaare statements. But I didn't want to deal with him. Cheers, -j > > Some sci.crypters may still remember Anthony Szopa and David(?) Scott, > who were similarly gifted in their determination to hold onto their > preconceptions. Arguing with them never did much good either.