<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>...or just use urandom, which is non-blocking, does not "waste
      randomness" and is totally acceptable for this use case. <br>
      I recommend watching this talk:
      <a class="moz-txt-link-freetext" href="https://media.ccc.de/v/32c3-7441-the_plain_simple_reality_of_entropy">https://media.ccc.de/v/32c3-7441-the_plain_simple_reality_of_entropy</a><br>
    </p>
    <br>
    Essentially, it boils down to this: the feature request was about
    providing specific character sets for specific passwords. <br>
    Base64 may sometimes be sufficient and sometimes just not satisfy
    restrictions imposed by the website -  it definitely is not the
    answer for the feature request.<br>
    Generating it by wrangling /dev/(u)random might or might not be the
    best approach.<br>
    <br>
    But before all that, there are other questions: <br>
    * should pass offer these options? (my opinion: yes, as this is
    necessary for some sites)<br>
    * If yes, how should it do so?<br>
        * Should it be a command switch, <br>
        * should it be passed as a CHARSET environment varianble (my
    preference)?<br>
    <br>
    THEN we can look at a way to get those passwords - and keep in mind:
    it should not introduce new dependencies and it should run not only
    on linux, but on OSX, BSD and a nix-y windows environment.<br>
    <br>
    <div class="moz-cite-prefix">On 11/11/2016 11:33 AM, Brian Candler
      wrote:<br>
    </div>
    <blockquote
      cite="mid:332d224e-0e4e-115b-459b-f9575a6761a0@pobox.com"
      type="cite">On 11/11/2016 10:05, Henrik Christian Grove wrote:
      <br>
      <blockquote type="cite">
        <blockquote type="cite">tr -dc
          'A-Za-z0-9!"#$%&'\''()*+,-./:;<=>?@[\]^_`{|}~'
          </dev/random |
          <br>
          >head -c 32 && echo
          <br>
          >
          <br>
        </blockquote>
        You're absolutely right, I totally missed that first head which
        is
        <br>
        totally unneccessary.
        <br>
      </blockquote>
      <br>
      Note that if you pipe /dev/random directly into tr like this, you
      are likely to consume 4KB or more of random data, which will
      unnecessarily deplete your entropy pool, and indeed may block
      waiting for more entropy. It's a highly wasteful approach, as
      entropy is a valuable resource, and this in turn may impact on the
      performance of other cryptographic operations taking place on the
      machine.
      <br>
      <br>
      If you are using 'pass' then I suspect you are making passwords to
      copy-paste rather than remember and type. Therefore the benefits
      of having a larger character set are minimal, when you could just
      have longer passwords to achieve the desired level of entropy.
      <br>
      <br>
      Consider that the base64 set has 64 symbols, and hence 6 bits of
      entropy per character. The set in that 'tr' line has 95 symbols,
      so has 6.57 bits of entropy per character.
      <br>
      <br>
      So to get a password with 96 bits of entropy, you need a
      16-character base64 password, or a 15-character password from that
      extended set. I don't consider the benefit of saving one character
      to be worthwhile, especially considering the difficulty of
      locating some of those characters on different keyboards, or the
      fact that many sites may reject some of those characters
      (different sites having their own policies as to which characters
      are acceptable)
      <br>
      <br>
      A good-quality 96-bit password can be generated consuming the
      minimum amount of system entropy like this (*):
      <br>
      <br>
      head -c 12 /dev/random | base64
      <br>
      <br>
      However if you really *do* want to use shorter passwords with more
      symbols, then I think it would be better to use a dedicated
      external program to generate passwords. The shell is *not* a good
      general-purpose programming language.
      <br>
      <br>
      I think 'pass' should have a simple default, and a configuration
      setting to choose an external password generator.
      <br>
      <br>
      Regards,
      <br>
      <br>
      Brian.
      <br>
      <br>
      <br>
      (*) Some sites insist that your password *must* include at least
      one upper case, lower case and digit, and occasionally this
      formula will generate a password which doesn't meet those
      requirements - roughly 1 time in 15.
      <br>
      <br>
      p(no digits) = ((64-10)/64)^16 = .0659812552
      <br>
      p(no uppercase) = p(no lowercase) = ((64-26)/64)^16 = .0002385931
      <br>
      <br>
      However there are only two symbols in the base64 set, so if a site
      requires at least one symbol then you're quite likely to fail.
      <br>
      <br>
      p(no symbols) = ((64-2)/64)^16 = .6017103034
      <br>
      <br>
      I find that in practice, passwords generated like this are fine,
      and if very occasionally I have to generate another one, that's
      not a big deal - certainly less work than having to configure a
      program with the rules for a given site.
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix">On 11/11/2016 10:05, Henrik Christian
        Grove wrote:<br>
      </div>
      <blockquote
        cite="mid:c92c0d6a-28e9-dd29-20b5-5b2e79e6aed6@3001.dk"
        type="cite">
        <blockquote type="cite" style="color: #000000;">
          <pre wrap="">tr -dc 'A-Za-z0-9!"#$%&'\''()*+,-./:;<=>?@[\]^_`{|}~' </dev/random |
<span class="moz-txt-citetags">> </span>head -c 32 && echo
<span class="moz-txt-citetags">></span>
</pre>
        </blockquote>
        <pre wrap="">You're absolutely right, I totally missed that first head which is
totally unneccessary.</pre>
      </blockquote>
      <p>Note that if you pipe /dev/random directly into tr like this,
        you are likely to consume 4KB or more of random data, which will
        unnecessarily deplete your entropy pool, and indeed may block
        waiting for more entropy. It's a highly wasteful approach, as
        entropy is a valuable resource, and this in turn may impact on
        the performance of other cryptographic operations taking place
        on the machine.<br>
      </p>
      <p>If you are using 'pass' then I suspect you are making passwords
        to copy-paste rather than remember and type. Therefore the
        benefits of having a larger character set are minimal, when you
        could just have longer passwords to achieve the desired level of
        entropy.</p>
      <p>Consider that the base64 set has 64 symbols, and hence 6 bits
        of entropy per character. The set in that 'tr' line has 95
        symbols, so has 6.57 bits of entropy per character.<br>
        <br>
        So to get a password with 96 bits of entropy, you need a
        16-character base64 password, or a 15-character password from
        that extended set. I don't consider the benefit of saving one
        character to be worthwhile, especially considering the
        difficulty of locating some of those characters on different
        keyboards, or the fact that many sites may reject some of those
        characters (different sites having their own policies as to
        which characters are acceptable)<br>
      </p>
      <p>A good-quality 96-bit password can be generated consuming the
        minimum amount of system entropy like this (*):<br>
      </p>
      <p>head -c 12 /dev/random | base64</p>
      <p>However if you really *do* want to use shorter passwords with
        more symbols, then I think it would be better to use a dedicated
        external program to generate passwords. The shell is *not* a
        good general-purpose programming language.</p>
      <p>I think 'pass' should have a simple default, and a
        configuration setting to choose an external password generator.<br>
      </p>
      Regards,<br>
      <br>
      Brian.<br>
      <br>
      <br>
      (*) Some sites insist that your password *must* include at least
      one upper case, lower case and digit, and occasionally this
      formula will generate a password which doesn't meet those
      requirements - roughly 1 time in 15.<br>
      <br>
      p(no digits) = ((64-10)/64)^16 = .0659812552<br>
      p(no uppercase) = p(no lowercase) = ((64-26)/64)^16 = .0002385931<br>
      <br>
      However there are only two symbols in the base64 set, so if a site
      requires at least one symbol then you're quite likely to fail.<br>
      <br>
      p(no symbols) = ((64-2)/64)^16 = .6017103034<br>
      <br>
      I find that in practice, passwords generated like this are fine,
      and if very occasionally I have to generate another one, that's
      not a big deal - certainly less work than having to configure a
      program with the rules for a given site.<br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Password-Store mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Password-Store@lists.zx2c4.com">Password-Store@lists.zx2c4.com</a>
<a class="moz-txt-link-freetext" href="http://lists.zx2c4.com/mailman/listinfo/password-store">http://lists.zx2c4.com/mailman/listinfo/password-store</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>