Apg or another password generator discussion

apg < stands for “another-password-generator”
apg < generates several random passwords

-a 0 < use algo. 0 - pronounce-able pw. gen. default
-a 1 < use algo. 1 - random character pw. gen.

-c /dev/urandom < use /dev/urandom seed for pw. gen.
-c /tmp/seed < use custom seed file for pw. gen.
-c cl_seed < use cl_seed as random seed for pw. gen.
< use it to gen. pws. in shell scripts.

-s < ask user to type a random sequence for pw. gen.
< only first 16 keys are significant

-M C < mode-gen. MUST use capital letters for every pw.
-M L < mode-gen. MUST use small letters for every pw.
< ALWAYS present if algo. 0 is used
-M N < mode-gen. MUST use numeral symbol for every pw.
-M S < mode-gen. MUST use special symbol for every pw.

-m 8 < generates an 8 character long pw. default.
-m 16 < generates a 16 character long pw.
-m min_pass_len < specify how long you want your pw. to be.

-n 1 < generates one pw.
-n 6 < generates six pws. default.
-n num_of_pass < specify how many pws. you want to generate

example :

apg -a 1 -c /dev/urandom -M CLNS -m 16 -n 8

https://explainshell.com/ or info apg or man apg

the above is a better, more direct approach to pw. generation
the ‘SeaHorse’ or ‘Password Safe’ GUI apps can be used as well.

i find the above approach takes considerably less time (with a keyboard) if you make a script or even keep it as a handy alias.
if you want to use ‘Password Safe’ JUST for pw. generation then you have to take additional steps with login-credentials, more clicks, and the built in generator doesn’t offer that many options.

the -c option is SO useful.

the only thing with apg is that it hasn’t seen updates in quite a while and i was wondering if there is anything better CLI wise.

what is the difference between /dev/random and /dev/urandom ?

-c cl_seed seems to be less secure since it uses the same seed each time if you leave the seed file unchanged.

2 Likes

Refer the man page. One blocks if insufficient entropy is available and the other doesn’t. I think - and I can’t remember which is which.

Edit: man urandom

/dev/random is suitable for applications that need high quality randomness, and can afford indeterminate delays.

Password generation can usually tolerate indeterminate delays, so /dev/random is stronger and better for that purpose.

Use an external hardware RNG if you are experiencing entropy starvation. I believe that the Librem Key can provide low bandwidth (40 kbit/s true random number generator) entropy (but more than enough for password generation).

2 Likes

@irvinewade u for unlimited => non blocking => a little bit (pun intended) less secure :slight_smile:

2 Likes

Here’s a non-technical explainer:
ht tps://www.2uo.de/myths-about-urandom/
(URL fractured to prevent autoload)
The TL;DR is that people much more knowledgeable than I am claim that there are only a few, limited circumstances where /dev/random is preferable over /dev/urandom.
These days, I usually just use some variation of the old standby:
dd if=/dev/urandom bs=1 count=15 | base64
If I don’t have access to the command line, and don’t need absolute maximum entropy, I just blindly grab into an opaque bag of Scrabble tiles.
For those occasions when I need a memorable passphrase, I usually use a scheme similar to Diceware, that is, use physical dice to randomly select a series of dictionary words. The trick there is to be truly random instead of constructing anything meaningful… I used to pull passphrases from unpublished historical documents, passed through an obfuscation scheme… bad idea, since anything written by humans is too non-random, also everything seems to end up on the internet eventually… hence the strict use of dice + dictionary.
ht tps://en.wikipedia.org/wiki/Diceware

1 Like

M8, just put text on the line before the URL. (Won’t autoload in the forum, might still prefetch in the browser of course). https://www.2uo.de/myths-about-urandom/

i gave the example above … but there are some web-sites who don’t allow for higher than 16 character passwords (and don’t allow special symbols)

i feel that 16 is too low nowadays with GPUs and HASHCAT and everything else that’s going on …

go 32 or more if that’s an option …

is there a way to access that from the CLI in PureOS ? i assume that -c /dev/random would need to be replaced by something else if that is the case …

Sorry, I don’t have a Librem Key - so I am not the best person to answer that. Good question though.

Not the way I do it. Your mileage may vary.

I use rngd to feed medium bandwidth, high quality entropy into the entropy pool. So it is completely transparent to any application using /dev/random or /dev/urandom, so you can basically use either device. (urandom will never block because the entropy pool is close to permanently at the highwater mark that you set with rngd. Ergo there is basically no difference between urandom and random in my scenario.)

If the primary source of entropy is keystrokes and mouse movements then that is not ideal on a headless computer. That was kind of the reason that I originally got interested in adding hardware entropy.

If you can’t be bothered with an external hardware RNG then you can use the hardware RNG built in to the CPU (any half recent Intel CPU; any? ARM CPU) - with the obvious gap that there is no transparency about how the entropy is being generated when it is hidden inside the CPU, no way to change it, single point of failure, limited information about how good the entropy is, whether it is backdoored (as a very theoretical weakness), …

I’m using external hardware RNG on Intel CPUs and the CPU built-in RNG on ARM CPUs (because it is hard to justify the cost when the external hardware RNG would cost more than the device :slight_smile:). Perhaps if I were really keen, I would turn the Intel computers into entropy servers for the ARM CPUs. :slight_smile:

apt search rngd
Sorting… Done
Full Text Search… Done
jitterentropy-rngd/byzantium 1.2.1-2 amd64
Jitter RNG Daemon

rng-tools/byzantium 5migrate1 all
transitional dummy package for rng-tools migration

rng-tools-debian/byzantium 2.3 amd64
daemon to use a Hardware RNG (classic version)

rng-tools5/byzantium 5-4+b1 amd64
Daemon to use a Hardware TRNG

since this is NOT installed by default under PureOS-10-Byzantium (devel version) i would assume that this tool is used/requested by only very few people … which do i need to proceed further ? it’s my first time :slight_smile:

Is this Librem 5 or Librem Mini or something else?

What do you plan to use as your hardware RNG source?

I think the package that you want is rng-tools

It looks like jitterentropy-rngd is installed and running by default on the Librem 5, in which case you should investigate how that would interact with another source of entropy.

You probably wouldn’t use an external (USB) source of entropy on the Librem 5 anyway. However you might use the OpenPGP card if you have one and it is physically installed and it can generate random bits and it is compatible with rngd.

1 Like

i have a librem-key and the LMini (both the v1 and v2 actually) but it would be interesting once i get the L5 to test what you said …

So the next step is to confirm whether or not jitterentropy-rngd is installed and/or running on the LMini.

But you will also need to find out how to get randomness out of the Librem Key. I would start by finding out what device(s) appear when you plug it in. You would be looking perhaps for something with a device name starting with tty.

as was expected jitterentropy-rngd was NOT installed by default but that was easy enough to fix :

sudo apt install jitterentropy-rngd
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
The following NEW packages will be installed:
jitterentropy-rngd
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 18,9 kB of archives.
After this operation, 66,6 kB of additional disk space will be used.
Get:1 http.://repo.pureos.net/pureos byzantium/main amd64 jitterentropy-rngd amd64 1.2.1-2 [18,9 kB]
Fetched 18,9 kB in 1s (19,4 kB/s)

No no no. If jitterentropy-rngd was not installed then you don’t want it installed. You want rng-tools installed.

The point of asking about the former is that if it is already installed then you need to be careful about adverse interaction between two different packages both trying to feed the entropy pool.

wow ! lucky me i guess …

sudo apt install rng-tools

Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
You might want to run ‘apt --fix-broken install’ to correct these.
The following packages have unmet dependencies:
linux-image-amd64 : Depends: linux-image-5.10.0-5-amd64 (= 5.10.26-1) but 5.10.24-1 is to be installed
rng-tools : PreDepends: mksh but it is not going to be installed
Depends: rng-tools-debian (>= 2.2~) but it is not going to be installed
E: Unmet dependencies. Try ‘apt --fix-broken install’ with no packages (or specify a solution).