3 ms·
Thanks very much for the updates on entropy requirements. Re: "Why are you generating keys on a remote VM" - prior to this, it hadn't occured to me I couldn't
by ghshephard 11y ago
Thanks very much for the updates on entropy requirements.
Re: "Why are you generating keys on a remote VM" - prior to this, it hadn't occured to me I couldn't generate a gpg key on linode/digital ocean, VMs. I realize now that keys should be generated on local laptops (or such), and copied up.
Re: "Fair to say failed to work" - It just sat their for 90+ minutes - I spent a couple hours researching, and found a bug (highly voted on) that other people had run into the same issue. But, honestly - don't you think that gpg just hanging for 90+ minutes for something like generating a 2048 bit RSA key should be considered, "failing to work?" - I realize under the covers (now) what was happening - but 99% of the naive gpg using population would just give up in the same scenario instead of trying to debug it.
- yuvadam 11y agoOn environments with limited initial entropy (such as VMs) just use haveged [1] [1] - https://wiki.archlinux.org/index.php/Haveged https://wiki.archlinux.org/index.php/Haveged
- cbsmith 11y agoYeah, the bug was really how it handled the case of waiting forever without telling you why. In GPG's defense, before it actually stars reading from /dev/random, it does give you all kinds of warnings that it needs sources of entropy before it can make any progress. Hard to get that kind of thing right, but fundamentally it did stop you from making exactly the kind of terrible mistake that I was talking about. ;-)