random delimiter support

[anarcat]

while it's nice that you can add an arbitrary delimiter to generated passwords, it would be even better if this software would have the (optional) feature to inject random symbols and digits as separators.

by default, the search space of generated passwords is quite large, but that's mostly due to the length of the password. while one can't assume that the password to be cracked will be all letters in the general case, that means the password generation routine becomes yet another "something you know" and allows the attacker to reduce the search space significantly once they know you use this software.

allowing for random passwords would force attackers to not limit themselves to 52 characters. adding numbers and symbols to that space would add about 20 bits of entropy to every password, at little cost to the human memory.

[1022]anarcat@curie:~$ diceware | wc
      1       1      29
[1023]anarcat@curie:~$ diceware | wc
      1       1      28
[1023]anarcat@curie:~$ diceware | wc
      1       1      36
[1023]anarcat@curie:~$ diceware | wc
      1       1      26
[1023]anarcat@curie:~$ qalc
> log2((26+26)^26)

  log2((26 + 26)^26) = approx. 148.21143

> log2((26+26+10+10)^26)

  log2((26 + 26 + 10 + 10)^26) = approx. 160.41805

> log2((26+26)^36)

  log2((26 + 26)^36) = approx. 205.21583

> log2((26+26+10+10)^36)

  log2((26 + 26 + 10 + 10)^36) = approx. 222.1173

thanks for your consideration!

[ulif]

Hi @anarcat !

Your proposal sounds interesting, but I am still not sure, I understand it correctly. Also your entropy computations look a bit optimistic to me (but I might be wrong, of course).

Could you give an example of a cmdline call (as you would imagine it) and the desired output? That would really help me to understand better what you want.

Thank you very much!

[anarcat]

hi!

my entropy calculations do not take into account the word patterns, of course. they are therefore inaccurate in this specific case, but if we treat the password generator as a black box and consider only the character space and length, they should be fairly accurate. i would posit that the rise in entropy would be similar if we did the proper calculation, but i could be wrong about that.

the commandline could be a simple binary flag, disabled by default. normal operation:

$ diceware
DiodeOralManlyCinchWhoopAvid

with the feature enabled:

$ diceware --random-delimiter
Salmon3Outdo!Jumps(Ruth2Assure$Verb

Maybe the argument could simply have a default of characters to choose from. We could abuse the --delimiter parameter to "pick" characters from the delimiter string, for example, normal behavior:

$ diceware --delimiter " "
Kelly 101st Fake Bread Seminar Align
$ diceware --delimiter "0123456789"
Daze0123456789Braun0123456789Guam0123456789Guy0123456789Bored0123456789Nuke
$ 

With the new feature:

$ diceware --delimiter " "  --random-delimiter # no change here because there's only one option!
Froth Maid Rabbi Saber Statue Pareto
$ diceware --delimiter "0123456789" --random-delimiter
Rubber5Elegant0Black7Pablo1Spit9Dub

I am not sure exactly what the commandline usage should be, to be honest...

[ulif]

Hey @anarcat , thank you very much for your explanations!

I guess I can understand your proposal better now and would like to do some entropy caculations over the weekend.

Frankly, I am not completely convinced yet. The main problem is: we must make sure, this new randomness should be possible with real dice as well. All operations of diceware should be executable with regular dice, if it comes to randomness.

Then, we have the "special chars" already in the API and I think we must compute, whether the entropy advantage of 'random-delimiter' would overall be really that huge without creating too much confusion otherwise. Concerning delimiters there are even security considerations to be taken into account, but nothing, I guess, one could not solve :)

Anyway, please give me two or three days to think it over and I will come back to you then, okay?

For now thank you very much for your proposal!

[haboutnnah]

Has this been implemented?

[ulif]

Hi @anarcat and @haboutnnah !

My apologies for the late answer - I got no good excuse.

I am still a bit reluctant about implementing this feature. Basically, generating an extra password as delimiter could be easily done on the shell by something like:

  $ diceware -d `pwgen 5 1`
  BondingzaexoSlingshotzaexoExtentzaexoColazaexoGlade

Generating delimiters with certain restrictions (like: using chars from a certain set only, etc.) would be more complex, but still be doable without a respective diceware feature.

Apart from this, introducing such a feature would mean to make computation more complicated and usage more confusing. I'd like to keep diceware as plain and simple as possible.

Last not least diceware is about generating memorizable passphrases and avoiding fully randomized passwords. So, offering fully randomized parts would be a bit contradictory, don't you think?

[htgoebel]

Without knowing this feature request, I'v implemented this in #61.