生成对称和非对称密钥的方法

Question

我们使用基于Beaglebone的定制板，并希望使用混合加密来加密固件文件，即对称加密大固件文件和非对称加密对称密钥文件。关于混合加密思想，我参考了这博客。

现在，关于对称密钥和非对称密钥的生成(主要是在Bash脚本中)，我有以下疑问。

对称密钥

方法1:

openssl rand 128 > sym_keyfile.key

怀疑1:

密钥的长度(例如128、192或256 )如何影响加密和解密？加密和解密是否只需要时间？

方法2:

cat /dev/urandom | head -n 128 > sym_keyfile.key

方法3:

cat /dev/random | head -n 128 > sym_keyfile.key

怀疑2:

哪种方法比较随机，方法1还是方法2？我倾向于认为方法2是随机的，random, urandom的手册页建议在不确定的情况下使用urandom。然而，我们有足够的种子熵来产生更安全的随机数。

怀疑3:

我们可以要求OpenSSL从/dev/urandom取随机数吗？

非对称密钥

私钥生成：

openssl genrsa -out keyfile.key 4096

从私钥生成

公钥：

openssl rsa -in keyfile.key -pubout -out keyfile.pub

现在，当我阅读OpenSSL有关rsa的帮助时，它说：

rsa命令处理RSA密钥。它们可以在各种形式之间进行转换，它们的组成部分可以打印出来。注意，此命令使用传统的SSLeay兼容格式进行私钥加密:较新的应用程序应该使用更安全的PKCS#8格式，使用pkcs8实用程序。

怀疑4:

OpenSSL帮助建议使用pkcs#8生成私钥和公钥，还是仅用于从私钥生成公钥？

怀疑5:

您建议其他方法来生成更安全的非对称密钥吗？

Answer 1

您似乎要求对OpenSSL和Linux内核默认使用的PRNG (伪随机数生成器)进行比较研究。这很可能会填满一个充满数学公式的卷，更糟糕的是，OpenSSL和Linux自OpenSSL将使用/dev/urandom作为默认种子以来并不是独立的，并且正在为Linux提供替代的PRNG (您可以看到Stephan Müller在主题这里和那里上的工作，以及他对linux内核邮件列表的讨论)。

然而，事实是，在大多数情况下，两者的长处和弱点是相同的：

• 优点:两者都是成熟且经过良好审核的代码，通常被公认为密码安全的PRNG，
• 缺点:由于它们的名称状态，它们都是伪随机数生成器，这意味着它们都是确定性算法，给定相同的种子，它们将产生相同的输出。因此，生产数量的不可预测性直接取决于种子的不可预测性。

因此，在安全性方面，您主要关注的可能不是使用OpenSSL或/dev/urandom中的哪一个(尤其是当您现在知道前者依赖后者时)，而是为了确保播种的质量。特别是，您可能需要的是TRNG (真随机数发生器)的一个或多个来源，即。一些硬件组件，专门为不可预测的随机数据服务，适用于密码学。

这将保证上述算法使用的种子的质量不会取决于系统I/O、负载等外部因素(当可用时，这些熵源很可能仍然被使用，但与TRNG输入合并)。在大多数情况下，这将对您的总体关键优势产生更大的影响，而不是在两个建立良好的PRNG实现之间进行选择。

现在来回答你的疑虑：

问题1:密钥的长度(例如128、192或256 )如何影响加密和解密？加密和解密是否只需要时间？

是的，它是:更大的密钥需要更多的计算能力来加密和解密。背后的想法是，虽然它将需要更多的努力，从合法的设备知道正确的密钥，它也将需要“指数”更多的努力，从任何潜在的攻击者。

关于合适的长度，您已经在这个主题(像这张漂亮的桌子)上找到了很多讨论，有些是一般的情况，有些是考虑到一些限制因素(比如具有非常有限的计算能力的嵌入式设备)。

疑问2:哪种方法更随机，方法1还是方法2？我倾向于认为方法2是随机的，随机的手册页建议在不确定的情况下使用urandom。然而，我们有足够的种子熵来产生更安全的随机数。

方法3可能会突然阻塞，时间未定。如果这不是您想要的(通常您不希望这样)，那么选择确实是在方法1和方法2之间。

从那以后，选择仅仅是个人偏好的问题。我要说的是，使用OpenSSL的语法更易于移植，而且更容易避免bug(例如，使用-n (行数)代替-c (字节数)作为head命令的参数)。

疑问3:我们可以要求OpenSSL从/dev/urandom获取随机数吗？

这是默认行为，但如果您希望确保此OpenSSL文档是您的朋友，并建议您添加-rand参数：

openssl rand -rand /dev/urandom 128 > sym_keyfile.key

疑问4: OpenSSL是否建议使用pkcs#8生成私钥和公钥，或者仅用于从私钥生成公钥？

正如LvB注释中所述，这是关于如何存储密钥，而不是生成密钥(这就像将文件存储在.zip、.rar或.tar.gz存档中一样)。

如果您可以自由选择，OpenSSL确实建议您使用现代和标准化的格式，而不是历史上的SSLeay格式：

• 使用PKCS8，您将将私钥存储在一个(可能是加密的)文件中，而公钥/证书存储在另一个(明文)文件中。
• 使用PKCS12，您将把私有和公共组件捆绑在一个文件中(这看起来更实用，但意味着如果.p12文件是加密的，那么如果不首先解密文件，即使是公共证书也无法读取)。

实际上，选择通常取决于应用程序将使用键支持什么。它的文档通常会要求您在何处以及如何存储关键材料。

问题5:您是否建议其他方法来生成更安全的非对称密钥？

我已经在上面提到了TRNG设备，我还建议您通过使用成熟和知名的软件实现来保持在已知的土地上。软件实现了糟糕的算法或好的算法，但是有了错误的实现，您的安全性同样会被摧毁。

最后，保持自错误随处可见以来的信息，但他们最有可能很快被发现和解决在成熟的解决方案，而不是在异域的解决方案。

Answer 2

与其尝试自己实现混合加密，我建议使用openssl smime子命令。另一种选择是使用gpg，它可能比openssl更适合对文件进行签名和加密。

openssl smime和gpg都自动进行混合加密。