Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 24 Aug 2016 20:42:09 +0200
From: "e@...tmx.net" <e@...tmx.net>
To: passwords@...ts.openwall.com
Subject: Re: GMOs And Passwords


> Entropy refers to the whole distribution not individual
> instances.

therefore entropy is not preserved when we shift the observer
from the defending side to the attacker's side
(which we always do in the context of password cracking)

it is not that entropy is "currently" not actionable.
entropy is in principle can not be used for the purpose in question
under any circumstances.



> Where I disagree with you though is that information about the whole set
> can be useful. Going to your GMO example, one problem that GMOs can
> introduce is lack of genetic diversity.

which can not be observed in a grain of wheat.
therefore you can not legitimately label a grain "GMO" coz of the lack 
of characteristic property.


> produce homogeneous populations.

so what? I do not eat populations.


> You can totally calculate the entropy for a set of known
> passwords. When trying to estimate the potential impact of different
> password creation policies on entropy, well things get more complicated,
> but ultimately it is a solveable problem. Where we run into issuess is
> then trying to translate that entropy value into some statement about
> the security of the system, but that's probably a topic for a different
> discussion. What I am trying to say though is that the generation
> process does sometimes provide useful information that can be tested for
> over a set of targets even if you can't test for it with an individual
> target.

this is exactly the "root of all evil" mistake.
no amount of entropy can scare the attacker.
your generation procedures are irrelevant, once the attacker uses 
ANOTHER generation procedure.
and when the attacker's procedure is simpler than yours, you end up 
surprised: "Why? i produced so much entropy!!!"


Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ