I think it would certainly be possible (without knowing any details about this generator), but in my view it only makes sense to provide such a solution if a majority of users would benefit from this feature. At the moment I don't think that many users have access to this kind of random generator.
Regards
Christian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Could you at least modify the program, so I can supply entropy from a file?
This way I can generate a random file from my entropy source and feed it into the application.
Currently, there is only support for text files because I have to copy content into a textbox.
Also at the moment, the application seems to use up almost all entropy when creating a password, even if the count is ">10000"
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Incorporating entropy from a file is a good idea. I think I will add such a feature to the upcoming release of PWGen.
As for the entropy counter, please note that the entropy of the random pool is limited to 256 bits (corresponding to the key length of AES-256). The counter is allowed to exceed this limit in case the user doesn't trust PWGen's estimations about the entropy content of user inputs (keystrokes, mouse handling, etc.). Of course the entropy content (in terms of "quality") of the pool is not decreased (as the progress bar might suggest) when random data is generated, the decrease just means that if you generate two 256-bit passwords, for example, using the same 256-bit entropy, the entropy of the two passwords is 256-bit rather than 512-bit, because theoretically it would be "easier" for an attacker to find the 256-bit seed value than to find the two random passwords independently. So if you discard one of the passwords, the entropy of the remaining one is still 256 bits. In addition to the pool content itself, PWGen uses the output of a 64-bit high resolution counter whenever it makes sense during random data generation, which means that the security is probably higher than 256 bits. And please never forget that the complexity of the 256-bit key space is very, very, huge...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I own a custom high entropy hardware random generator I wish to use with PWGen
Would it be possible, that PWGen can be instructed to listen on a localhost TCP interface to receive random data?
Hello, I'd be interested to know more about the hardware in question. It's not something one could find in the hardware store I suppose?
Hi AyrA,
I think it would certainly be possible (without knowing any details about this generator), but in my view it only makes sense to provide such a solution if a majority of users would benefit from this feature. At the moment I don't think that many users have access to this kind of random generator.
Regards
Christian
Hi Christian
Could you at least modify the program, so I can supply entropy from a file?
This way I can generate a random file from my entropy source and feed it into the application.
Currently, there is only support for text files because I have to copy content into a textbox.
Also at the moment, the application seems to use up almost all entropy when creating a password, even if the count is ">10000"
Hi AyrA,
Incorporating entropy from a file is a good idea. I think I will add such a feature to the upcoming release of PWGen.
As for the entropy counter, please note that the entropy of the random pool is limited to 256 bits (corresponding to the key length of AES-256). The counter is allowed to exceed this limit in case the user doesn't trust PWGen's estimations about the entropy content of user inputs (keystrokes, mouse handling, etc.). Of course the entropy content (in terms of "quality") of the pool is not decreased (as the progress bar might suggest) when random data is generated, the decrease just means that if you generate two 256-bit passwords, for example, using the same 256-bit entropy, the entropy of the two passwords is 256-bit rather than 512-bit, because theoretically it would be "easier" for an attacker to find the 256-bit seed value than to find the two random passwords independently. So if you discard one of the passwords, the entropy of the remaining one is still 256 bits. In addition to the pool content itself, PWGen uses the output of a 64-bit high resolution counter whenever it makes sense during random data generation, which means that the security is probably higher than 256 bits. And please never forget that the complexity of the 256-bit key space is very, very, huge...