AWS EC2 中有/dev/random什么好处可用于制作将通过安全通道传递的共享密钥？我担心启动的实例一开始不会有太多的熵。如果我延迟使用它几分钟以获得随机 EBS 延迟以获得更多熵怎么办？
编辑：
我不会登录到这些实例。一个实例将生成一个密钥并将其（以十六进制形式）放置在标签中。另一个实例将从该标签中获取密钥并在它们之间建立一个 VPN。也许有一种方法可以为此使用 PKC，尽管往返标签的路径是https，AWS 依赖于它来获取登录密码。
编辑2：
我想访问 EC2 API 的时间可能是熵的另一个来源。
云机器和随机性的潜在问题是虚拟机克隆；看到这个。任何体面的 Linux 系统都能够/dev/urandom在启动后的任何时候产生高质量的随机性，无论它是否位于云中。但是，如果虚拟机被克隆，那么两台机器将以相同的内部状态启动，并且操作系统中没有可以为此包含的安全机制，因为根据定义，客户操作系统不知道克隆.
对于亚马逊来说，在每个新克隆的实例中推送新鲜的随机性在技术上是可行的（更新克隆中的“种子文件”就足够了）。我不知道他们是否这样做。如果他们不这样做（或者如果您找不到一些说明他们这样做的书面文件），那么您可能必须自己进行重新播种。尽管只需等待几分钟的网络活动就应该注入足够的熵，但自己强制它既更快又可以说更安全。假设您正在通过 SSH 从您的笔记本电脑/台式机访问 Amazon EC2 实例，并且您的笔记本电脑/台式机也使用 Linux，那么只需执行一次即可：
dd if=/dev/urandom bs=20 count=1 | ssh TheEC2MachineName 'cat > /dev/random'
瞧！向 VM 熵池添加了 20 个新字节的强随机性。然后，您可以立即在 VM 上处理所有加密内容。