[Swan-dev] shannon_entropy [was Re: ikev2-14-missing-ke test failure]

[D. Hugh Redelmeier]

| From: Paul Wouters <paul at nohats.ca>

| On Sat, 3 Jan 2015, D. Hugh Redelmeier wrote:
| 
| > Lets look as some values calculated by the function.
| 
| Most example do not take into account that we would force a minimum PSK
| length (which I had not yet implemented but was planning to add)

I was basically showing that the function is not what it is
represented to be, Shannon Entropy.  Furthermore, the result is not
meaningfully read as bits, which is what one would expect.

Where did the algorithm come from?

| The recent NSA documents reveal a possible bruteforcing of PSKs.

Sure.  No surprise there.

| Since we cannot force people to stop using IKEv1 Aggressive Mode,

We disagree about that.  You've just proved it is a weakness.  I guess
rate-limiting would be a useful bandaid.

Perhaps we should mount a PR campaign to shame those who insist on
Aggressive Mode.

| 1) Do have you something better within the restrains of not using
| dictories?

pam_cracklib seems to exist already, be available on most systems we
target, be designed for this purpose, be widely used already, stood
the test of time, and already experienced by users.

I have no idea how to use it.  Maybe it cannot be used reasonably.
I don't even know if it is any good.
<http://www.linux-pam.org/Linux-PAM-html/sag-pam_cracklib.html>

| 2) Does this code do anything bad? (I'd say at most a false sense of
| security?)

It is quite misleading.  That is always a problem in security systems.

It is training users to meet a meaningless goal.  Often they rebel in
ways that impair security.  (The tales of this are legion.)

(A minimum key length is not perfect but it is clearly so and thus
doesn't mislead users.  They might still rebel.)

BTW, reporting "Shannon Entropy" values might be leaking valuable
information to an attacker, assuming they can see the message.