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

D. Hugh Redelmeier hugh at mimosa.com
Sun Jan 4 07:54:50 EET 2015


| From: Paul Wouters <paul at nohats.ca>
| Date: Sat, 3 Jan 2015 18:37:39 -0500 (EST)

| The recent NSA documents reveal a possible bruteforcing of PSKs. There
| are also tools like http://ikecrack.sourceforge.net/
| 
| 	IKE Agressive Mode BruteForce Summary
| 	Aggressive Mode IKE authentication is composed of the following steps:
| 
| 	1 - Initiating client sends encryption options proposal, DH public
| 	key,
| 	random number [nonce_i], and an ID in an un-encrypted packet to the
| 	gateway/responder.
| 	2 - Responder creates a DH public value, another random number
| 	[nonce_r], and calculates a HASH that is sent back to the initiator in
| 	an un-encrypted packet. This hash is used to authenticate the parties
| 	to
| 	each other, and is based on the exchange nonces, DH public values, the
| 	initiator ID, other values from the initiator packet, and the
| 	Pre-Shared-Key [PSK].
| 	3 - The Initiating client sends a reply packet also containing a HASH,
| 	but this response is normally sent in an encrypted packet.
| 
| 
| 	IKECrack utilizies the HASH sent in step 2, and attempts a realtime
| 	bruteforce of the PSK.

| From: Paul Wouters <paul at nohats.ca>
| Date: Sat, 3 Jan 2015 23:44:49 -0500 (EST)

| I don't think rate limiting helps. This is not an active attack, but a
| passive attack that can be done offline.

[Hugh reads the earlier message more carefully.]

I see.  ikecrack isn't offline, it is realtime, according to what you
quote.  But offline seems quite feasible (I haven't checked the
actual RFC).

Offline is an attack on the responder.  This is usually the stupidly
administered non-libreswan side.  Not Our Problem???

| > Perhaps we should mount a PR campaign to shame those who insist on
| > Aggressive Mode.
| 
| We'll still have to support it, eg for stupid certification reasons.

We should CERTAINLY shame the certification authority.  That's
horrible.  The NSA revelations are fresh ammunition.

What is this certification authority?

| But
| also because 75% of IKEv1 deployed is Aggressive Mode :(

I think that argument (which I don't really accept) would be for
libreswan to support Aggressive Initiation.

Is there any argument in favour of libreswan supporting Aggressive
Responding?  With PSK?  (We would need to support it for testing 
purposes.)

| > | 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.
| 
| And it does require a dictionary.

It comes with a dictionary, I think.  Or at least it is already
deployed with a dictionary.

| I tried to stay away from "password
| hacking" tools and make it simpler. Because we wouldn't catch people
| using a single character 20 times in a foreign script.

It is a palindrome and is therefor caught.

I think that this is a fool's game.  Better to use someone else's fool
than invent a new one.

| > | 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.
| 
| Is it? Would it be less misleading if we hide the reason and number and
| just say "we deem this PSK too weak" ?

Yes.  But perhaps more frustrating.

In either case the user has no idea why libreswan considers it weak
and what to do about it.

| > It is training users to meet a meaningless goal.
| 
| It's raising the bar. The bar is quite low as it is now. Even if you
| limit the minimum length to 8, you will get "testtest".

The shannon_entropy function looks all mathy but isn't.  A simpler and
clearer formulation of roughly the same restriction would be:
1) you need at least n distinct characters
2) the most common character must not appear more than m times.
I'm not saying that this is the right restriction.  I'm saying that it
is better than one involving shannon_entropy.

You could keep adding restrictions until the cows come home:
3) at least half the characters must appear only once
4) some of the characters must be lower case letters
5) some of the characters must be upper case letters
6) some of the characters must be digits
7) some of the characters must not be letters or digits
9) no digraph may appear more than once
10) must not be a palindrome
11) must involve switching hands n times when touch-typing on a querty
    keyboard
But I think that this is a waste of time.

These tests are such that they are easy to comply with.  Not so with
the odd "shannon_entropy".

This is reinventing a wheel.  Not generally a good idea in security
work.

| > (A minimum key length is not perfect but it is clearly so and thus
| > doesn't mislead users.  They might still rebel.)
| 
| Yeah, it's too simple, "testtesttesttest"

Every rule set can be gamed.  The more complicated the rules, the more
fun to defeat them.

| > BTW, reporting "Shannon Entropy" values might be leaking valuable
| > information to an attacker, assuming they can see the message.
| 
| I have no problem making that a debug only, or even DBG_CRYPT only
| display - or just never displaying it at all and just saying "too weak".

Fine.

But the user surely has no feel for what shannon_entropy is imposing.
I had to spend some time figuring out what I managed to.  Hiding the number
may make this worse.  So make the test more comprehensible to users.


More information about the Swan-dev mailing list