Re: Password Difficulties

joshua@cae.retix.com writes:
>>   Hey folks, passwords are hard to choose!
>
>?

What part don't you understand?

Give people the opportunity to chose "random" passwords and they
choose easily guessed strings.  (Well demonstrated.)

Tell people to chose a *phrase* and they are going to frequently type
"The quick brown fox...".  (My assertion.)

Your suggestion about rare steak is so long that "normal" people are
not going to bother with it.  Just getting people to type the
19-characters of "the quick brown fox"--just four words--is going to
be hard, and there are not very many bits of information in 4 short
common English words--forget that they are a chiche.

Besides, your sample phrase might not have as many bits in it as you
think.

>Rare steak tastes good when it is cooked over a wood fire. better
>chicken. better than fish. good with worcestershire sauce.

22 words, a good start.  But all will appear in a short dictionary
list, 4 gramatical sentences, sentences with related meaning.  Not so
good.  Slightly non-standard capitalization--but only a few bits in
that.  You suggest a phrase that is going to seem annoying to people
raised on 4-digit PINs, yet it still might not have, say, the 128-bits
lots of people want.

My 128 coin tosses can be roughly turned into 8-words, but out of a
much larger word list than your phrase and with no gramatical
connections--and hard to remember.  Each transformation I might do to
those words to help remember them chops off a few of my original bits.
By the time I have something my mother is going to bother with there
are few bits left.  A little brute force and those bits are blown.

And why should you care if my mom uses weak keys?  Because it will
undermine the legal weight of things like digital signatures.  Because
all communication you have with "normal" people will be nearly in the
clear because of their poor security.  If you want privacy, you need
to help others have privacy.

Back to a rephrasing of my original question: should programs like PGP
super-duper encrypt the private key (and remove those hints poeple
have mentioned recently) as a way of slowing down brute-force attacks?


-kb

P.S. Remember, even a good hashing algorithm should not be expected to
create entropy out of thin air.  Too few bits in means too few bits
out.  Just because I don't know how to analyze those bits does not
mean you should be content.


--
Kent Borg                                                  +1 (617) 776-6899
kentborg@world.std.com                                
kentborg@aol.com                                      
          Proud to claim 31:15 hours of TV viewing so far in 1994!

-----BEGIN PGP SIGNED MESSAGE-----

In article <199407020841.AA23083@world.std.com> you write:
>Back to a rephrasing of my original question: should programs like PGP
>super-duper encrypt the private key (and remove those hints poeple
>have mentioned recently) as a way of slowing down brute-force attacks?

In general, multiple encryption does not signifigantly increase
security.  Just for starters, we don't know if IDEA is a group..
If it is, you can encrypt all you want and you won't get one
extra bit of security.  Trying to analyse just *one*
cryptosystem or algorithm for security holes and information
leaks is hard enough - trying to analyse the interaction between
several layers of said algorithm or even between different
algorithms seems harder and lacking in promise.  Of course you
could view this as defence of multiple-encryption: "if there
*is* some weird interaction that reveals my key when you xor the
secret-key file with any Nick Danger script, no one will ever
discover it because it will be too hard"  but this strikes me as
the security through obscurity myth.

You can't get something for nothing.  With a 12 bit pass phrase,
you have 12 bits of security - I don't see any known way to
increase this without increasing the pass phrase length.

I haven't looked into this alot, but I wonder how the approach
used with many unix passwd utilities would fare?  For instance,
checking password/phrase crackability if you will - comparing
against a dictionary, measuring entropy or just plain not
accepting pass phrases shorter than x.  Also, many passwd utils
will generate "pronouncable" random text.  Perhaps with several
short words generated thusly would get you the entropy you need.

Thoughts?

- --
 Baba baby mama shaggy papa baba bro baba rock a shaggy baba sister
shag saggy hey doc baba baby shaggy hey baba can you dig it baba baba
        E7 E3 90 7E 16 2E F3 45   *   28 24 2E C6 03 02 37 5C 
   Stuart Smith                           <stu@nemesis.wimsey.com>

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAgUBLhb4kKi5iP4JtEWBAQGjyQP7BIFaiEGEbAs3JFMCL/A/NBn5GIqB1XqK
KZwlKHixqDhG3TaqrxTIbe5e6/rKGnYz8ct2ETq3BZMucSuv4nFwizXxlw8Ra9zO
IWCbre0j2A/wOEd2mLksov1cnJdwVDYQ2XIyTvV55J2ajIxiu4rIA0ErOIEE2sH0
dn2R9K9A6qU=
=tFK0
-----END PGP SIGNATURE-----

> kentborg@world.std.com (Kent Borg) writes:
> joshua@cae.retix.com writes:
> Besides, your sample phrase might not have as many bits in it as you
> think.

> >Rare steak tastes good when it is cooked over a wood fire. better
> >chicken. better than fish. good with worcestershire sauce.

> 22 words, a good start.  But all will appear in a short dictionary
> list, 4 gramatical sentences, sentences with related meaning.  Not so

I think it's quite likely to have 128 bits worth of keyfulness (no, that's
not a Term of Art).  Shannon estimated from experiments (people guessing
the next letter in connected standard English text) that English contains
about one bit of information per character.  The ungrammatical structures
and missing caps would add more bits to the data in those areas, so the
120 or so characters would yield more than 120 bits of information.
Guessing a long passphrase from a dictionary attack doesn't work, as you
can tell from some simple arithmetic: 22 words out of a 1,000-word
dictionary is like 10^66 possibilities, and 'worcestershire' wouldn't be
in the 1,000-word dictionary.  Note also that guessing keyphrases using
some kind of Markov algorithm isn't going to be easy, because unlike the
Shannon experiment you don't get any feedback on your trials until you
have every bloody bit right.  It requires enumerating all legal 128-byte
English sequences and testing each in turn.

It's much easier to use an attack like Tim suggested than to break even
a weakish passphrase (well, not as weak as "quick brown fox").  One example
would be infiltrating Cypherpunk PGP key-signing parties: write a TSR or
custom COMMAND.COM that will capture all keystrokes typed on your laptop,
and offer it to others for signing your key and others'.  Don't forget to
have any command that accesses the floppy disk check for a file called
"secring.pgp" and copy it to your hard drive under the name
c:\scratch\junk17.foo.  Remember, you're signing keys to verify that you
know who they are... not that you trust them.

	Jim Gillogly
	9 Afterlithe S.R. 1994, 16:57

Figure that each English character has 1.8 bits of entropy.  (This is
a conservative number, because it doesn't take into account case, spacing,
or punctuation.)  If I want a passphrase that will map into a 64-bit 
keyspace, I need at least a 35-chararcter phrase.

I generally assume that I need about one word per byte of key.  Thus, if
I want to generate a 64-bit key, I need an eight-word phrase.

Bruce

Kent Borg says:
> Besides, your sample phrase might not have as many bits in it as you
> think.
> 
> >Rare steak tastes good when it is cooked over a wood fire. better
> >chicken. better than fish. good with worcestershire sauce.
> 
> 22 words, a good start.  But all will appear in a short dictionary
> list, 4 gramatical sentences, sentences with related meaning.

Were I using a sentence like that, I'd probably spice it up with low
probability words and the like, as in

"rare olliphant meat tastes good when cooked over a burning car. better
than oktopuss. not as good as republican. tasty with wasabi and chives."

Still fewer bits than I'd like, but you do better when things take an
unexpected turn mid-phrase.

Perry