我的脚本是：
- #!/usr/bin/env bash
- rm -rf .gnupg
- mkdir -m 0700 .gnupg
- touch .gnupg/gpg.conf
- chmod 600 .gnupg/gpg.conf
- tail -n +4 /usr/share/gnupg2/gpg-conf.skel > .gnupg/gpg.conf
- touch .gnupg/{pub,sec}ring.gpg
- cat >.gnupg/foo <<EOF
- %echo Generating a basic OpenPGP key
- Key-Type: RSA
- Key-Length: 2048
- Subkey-Type: RSA
- Subkey-Length: 2048
- Name-Real: User 1
- Name-Comment: User 1
- Name-Email: user@1.com
- Expire-Date: 0
- Passphrase: kljfhslfjkhsaljkhsdflgjkhsd
- %pubring foo.pub
- %secring foo.sec
- # Do a commit here,so that we can later print "done" :-)
- %commit
- %echo done
- EOF
- gpg2 --verbose --batch --gen-key .gnupg/foo
当我运行它时,它显示：
- =$./gen.keys.sh
- gpg: Generating a basic OpenPGP key
- gpg: no running gpg-agent - starting one
- gpg: writing public key to `foo.pub'
- gpg: writing secret key to `foo.sec'
但它只是挂起.
当我同时检查该用户的ps树时,我看到：
- USER PID %cpu %MEM VSZ RSS TTY STAT START TIME COMMAND
- tstpg 22603 0.0 0.0 24108 5688 pts/9 Ss 14:59 0:00 -bash
- tstpg 22624 0.0 0.0 13688 3168 pts/9 S+ 14:59 0:00 \_ bash ./gen.keys.sh
- tstpg 22632 0.2 0.0 27428 3676 pts/9 SL+ 14:59 0:00 \_ gpg2 --verbose --batch --gen-key .gnupg/foo
- tstpg 22634 0.3 0.0 18072 2884 pts/9 SL+ 14:59 0:00 \_ gpg-agent --server
在〜/ .gnupg / gpg.conf中没有提到代理,我不知道它正在尝试做什么.
foo.pub/foo.sec文件在home dir中生成,但是为空.
版本：
> gpg(GnuPG)2.0.26
> libgcrypt 1.6.2
你的选择,为了提高满意度,是
>重新配置gpg以使用非阻塞伪随机数生成器,这是最不明智的(尽管见下文),
>使用软件解决方案从现有系统状态中获取更多熵(众所周知,核心准备从系统状态中获取多少熵,特别是在该状态没有直接人工输入的情况下,例如cpu或NIC时序);正如你所指出的,haveged是一个这样的解决方案,或者
>为计算机提供另一种高级熵的物理来源.像Entropy Key或the OneRNG这样的设备可以满足这个要求(除了我拥有一个熵密钥之外,我与这两个产品都没有关系,我对它非常满意).
编辑：mzhaase在this article on /dev/urandom vs. /dev/random的评论中引起了我的注意(非常感谢,这是一篇很棒的文章！)并且我不喜欢使用urandom来创建密钥.事实上,文章并没有说这两个来源是等价的,并指出
Linux’s /dev/urandom happily gives you not-so-random numbers before
the kernel even had the chance to gather entropy. When is that? At
system start,booting the computer.
也就是说,在启动之后,直到urandom PRNG已经用足够的熵初始化,将它用于密钥生成真的是不安全的.这可能需要一段时间,尤其是在无人值守的无头服务器上,我们不知道何时达到阈值,因为系统没有明确告诉我们.
现在,如果/ dev / random准备发出数字,我可以合理推断熵池足够深,以至于urandom将被正确初始化.但是如果我必须在每次使用urandom之前检查/ dev / random阻塞(假设我生成密钥的次数少于我重启的情况,很可能就是这种情况)我不妨只使用/ dev / random中的数字生成我的密钥.
