Re: My password tips



On 11-02-12 8:25 PM, nemo_outis wrote:
Jeffrey Goldberg<nobody@xxxxxxxxxxxx> wrote in
news:8ropl8FqqiU1@xxxxxxxxxxxxxxxxxx:

The lower values are based on human predictors, who are much
more finely tuned to the nuances of English and to the context
of any particular passage. Arguably, for password cracking,
where the attack will almost certainly be fully automated, one
should base the estimate of the entropy of English on the best
*automated* methods which would push us out closer to 1.5
(i.e., as based on compression efficiency).

That makes very good sense.

But that was not the primary context in which I was saying a
longer password is much better than a larger character pool

I took some liberties with the context. You are unambiguously correct where we are talking about each character between drawn randomly from the alphabet. In such a context length matters far more. The math is simple.

I didn't mean to misrepresent what you were saying by playing with the context, but I was trying to draw things back to the context of human memorable passwords. These passwords are going have have low entropy per character.

I have done the math :-) Using *random strings* as the
simplest case for exposition, the payoff from using a larger
character pool is very small compared to simply using a longer
password - as shown in my previous post repeated above.

You have no argument from me. (Even I can do that math.) But when we are limiting ourselves to strings that humans can remember instead of random strings, there is math to do.

So just playing with some toy numbers, lets ignore that added entropy per character changes depending how far into the string. That is, we will pretend that it is the same for the first character as it is for the 20th.

To be extra generous to the "better to add length" approach, lets say that for the nonsense phrases people may use there are 2 additional bits of entropy per character, and we have a 15 character string. This would then have 30 bits of entropy. Making it 16 characters long would give it 32 bits.

Now if expanding the alphabet increased the additional entropy per character from 2 bits to 2.5 bits, then a 15 character passphrase would have 37.5 bits of entropy. With these (fictitious) numbers we see that increasing the alphabet is like adding 3.5 characters. (Now why didn't I pick numbers to get me a whole number of characters.)

Now when I started this, I was hoping for a clearer win for increasing the alphabet. A factor of 4 really isn't a very big deal. So I am very sad to have written all that up and not end up making a persuasive case.

To get the bigger effect that I was hoping for, I would have to bump up my 2.5 bits per character. But I don't think I can do that fairly. The punctuation marks that people add will come in fairly predictable places (word boundaries, or at best syllable boundaries) and will be drawn from those easiest to type.

So this returns us to your point about human memory and keyboard entry.

I fully agree with you about human memory and keyboard
entry.

I take ginkgo for my memory, fennel for my digestion, and
ginkgo for my memory :-)

What were we talking about? I forgot.

Cheers,

-j


--
Jeffrey Goldberg http://goldmark.org/jeff/
I rarely read HTML or poorly quoting posts
Reply-To address is valid
.



Relevant Pages

  • Re: Unrecognized escape sequences in string literals
    ... a reader can't know if \ is a literal character or escape character ... without knowing the context, and it means an innocuous change in context ... thinking about the fact that the s comes after the backslash. ...
    (comp.lang.python)
  • Re: Reader feelings management OR rank your chapters OR "pre-crit"
    ... Context: Alt. ... Did they have too much planning, ... They'd start with some individual character whose family was about ... hardware problems, scanty access, typing fast ...
    (rec.arts.sf.composition)
  • Re: Quran 5:32
    ... verses are no more operative then Old Testament commands regarding ... Since we are not the Old Testament nation of Israel ... In all things..keep it in context. ... Your strawman view of my character is of zero interest to me. ...
    (rec.sport.football.college)
  • Re: How to terminate a text file line in Unicode (in Java)
    ... In this case, technically, I might use any character sequence ... though the text file isn't really a text file if its line terminator is not one of the characters designated for such use in character code standards. ... This is somewhat obscure (since the operating system need not use such a convention) and reflects lack of rigorous standardization of the language. ... I guess both candidates are feasible, with no clear preference, but the context and purpose may make one of them preferable. ...
    (comp.std.internat)
  • Re: Fixed Strings
    ... > much in the context of strings, and Chr$used to tend to create ... character of choice for VB rather than Chr. ... Prev by Date: ...
    (microsoft.public.vb.general.discussion)