Project

General

Profile

Feature #553

Password generation, wasting resources?

Added by Peter K about 2 years ago. Updated about 2 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Target version:
-

Description

During a password generation, Keepassx generates not only 1 (one), but even 20-30 (many!) passwords. If I move the slider, or check any character class checkbox, Keepassx (at each step!) drops the current password (entirely) and pops out from somewhere (/dev/random or such?) a brand new (and hopefully totaly random) one.

It seems to be a waste of "entropy". A waste of some system resource.
(And it may prevent people to change generation parametes...)

(I always read from /dev/random as few as possible. Only as many as I really need.)

History

#1 Updated by Felix Geyer about 2 years ago

  • Status changed from New to Rejected

KeePassX uses libgcrypt which seeds its PRNG from /dev/urandom.
The additional passwords are only generated when you click on the combo box popup.

Reading a few hundred bytes from a PRNG is a fast operation anyway (for example on my system I can read ~1.2MB/s from urandom).

#2 Updated by Peter K about 2 years ago

So, if I can ask, about how many bytes are expended from /dev/random (or /dev/urandom, which reads in turn from /dev/random, as I know), for a password generation? (Or per KeePassX session, if so.)
(Users prefer the minimal.)

What "quality" the generated passwords have? In some appropriate sense. (As far as I know, even /dev/random produces "slightly, at least in a mathematical sense, at least after some exhausting" more random bits than /dev/urandom.)
(Users prefer the maximal.)

And: why is iterated the PRNG (new and new password) even during the tuning phase, for example 10 times during moving the length-slider from 15 to 25?
(As I guess, users could find [at least as] intuitive and sufficing a "Let's generate (again)" explicite button. Pressed after setting the parameters.)

#3 Updated by Felix Geyer about 2 years ago

So, if I can ask, about how many bytes are expended from /dev/random (or /dev/urandom, which reads in turn from /dev/random, as I know), for a password generation? (Or per KeePassX session, if so.)
(Users prefer the minimal.)

That depends on libgcrypt internals. It doesn't directly use /dev/urandom but seeds its own pool with bytes from /dev/urandom.

What "quality" the generated passwords have? In some appropriate sense. (As far as I know, even /dev/random produces "slightly, at least in a mathematical sense, at least after some exhausting" more random bits than /dev/urandom.)
(Users prefer the maximal.)

The "randomness" entirely depends on what entropy sources your kernel has. It doesn't matter how much you read from the pool.

And: why is iterated the PRNG (new and new password) even during the tuning phase, for example 10 times during moving the length-slider from 15 to 25?
(As I guess, users could find [at least as] intuitive and sufficing a "Let's generate (again)" explicite button. Pressed after setting the parameters.)

It saves an extra button on the UI and requires one less mouse click. As I said generating a random password is very cheap.

#4 Updated by Peter K about 2 years ago

There is an "Accept" button on the form.
(Users have no choice other than ACCEPT the password.. Okay, accept one of the passwords in the combo-list, if the user [unlike me, for a long time] discovers the combo opportunity.)
So there is plenty room for a second, "Generate" button.
Meaning that the user, for any reason, does not want to accept the password (neither of the few), and would like to generate another.

(And it would make the combo-list [even more] needless.)

Also available in: Atom PDF