[pass] generate passwords natively instead of dependency

[Brian Candler]

On 14/11/2016 21:27, ilf wrote:
> Here's a simple way to generate passwords from /dev/random directly in 
> shell:
>
> tr -dc "[:graph:]" < /dev/urandom | head -c 32 

Aside: even though urandom doesn't block, I still think it's a really 
bad idea to consume 4KB or more of data from it to generate a single 
password.

As it says in the random(4) manpage:


        Users
        should be very economical in the amount of seed material that  
they  read  from  /dev/urandom
        (and  /dev/random); unnecessarily reading large quantities of 
data from this device will have
        a negative impact on other users of the device.

        The amount of seed material required to generate a cryptographic 
key equals the effective key
        size  of the key.  For example, a 3072-bit RSA or Diffie-Hellman 
private key has an effective
        key size of 128 bits (it requires about 2^128 operations to 
break) so a  key  generator  only
        needs 128 bits (16 bytes) of seed material from /dev/random.

        While  some  safety  margin above that minimum is reasonable, as 
a guard against flaws in the
        CPRNG algorithm, no cryptographic primitive available today can 
hope to promise more than 256
        bits  of security, so if any program reads more than 256 bits 
(32 bytes) from the kernel ran-
        dom pool per invocation, or per reasonable reseed interval (not 
less than one  minute),  that
        should be taken as a sign that its cryptography is not skilfully 
implemented.

So if you want to generate a 32 character password, using a 95 character 
set (6.57 bits of entropy per character), then you should consume 210 
bits from /dev/urandom - no more.  Then you should deterministically map 
those bits to the desired output character set - not just throw away 
good quality random bytes which don't match the 'tr' pattern.

This is something which is easy to do in a good general-purpose 
programming language, which the shell is not.

(In any case, passwords don't need 210 bits of entropy. 128 is more than 
enough)

Regards,

Brian.