Encryption 椭圆曲线密码可以用作分组密码吗？

我正在尝试使用非对称加密来加密固件。引导加载程序将解密并更新闪存。这是在嵌入式设备上，32位CPU以60MHz的频率运行

我想使用ECC，因为它有各种各样的优点。我是加密新手，我对ECIES中实现的os ECC的理解是使用ECC生成密钥，并使用AES进行实际数据加密。由于代码和ram的大小，我不能支持多种加密算法

是否有一个ECC的实现可以像AES一样使用。我想要的是使用“私钥”加密固件，引导加载程序使用“公钥”解密固件

---

谢谢。

我不确定您是否完全理解ECIES的组成：

---

这是相当多的工作，而且它需要大量的原语，在我看来至少包括一个对称原语。这也可能是AES。

让我们从问题的最后一句开始：

我想要的是使用“私钥”加密固件，引导加载程序使用“公钥”解密固件

这里的术语有些混乱。私钥用于解密（或签名），公钥用于加密（或验证）。如果我理解正确，您希望引导加载程序验证固件上的签名，以便引导加载程序只接受您自己正确签名的固件

有多种非对称签名方案可用于此目的，包括一些基于椭圆曲线密码的非对称签名方案。例如，您可以使用ECDSA的OpenSSL实现（请参阅）

恐怕问题中没有足够的信息来正确选择最佳签名方案（如果需要对固件保密，还可能选择加密方案）。在任何情况下，好的加密技术都不足以保证系统的安全，而安全实现等其他考虑因素也同样重要

如果这是你需要保护的重要内容，并且你担心黑客可能试图破坏，我强烈建议你购买安全专业人员的服务。正确使用密码是一项非常棘手的工作，需要全面了解系统-否则，您可能会发现自己处于类似于

的情况下如果您寻求“身份验证”，您必须使用诸如EC之类的非对称算法，这通常是因为如果用户或进程想要更新“固件”他应该通过自己的“签名”向引导加载程序确认自己的身份，以检查请求此更新的人

完成后，引导加载程序将从安全内存加载对称密钥，以解密您想要执行的操作

因此，您有一个用于加密的对称密钥（AES）和两个用于身份验证的非对称密钥（=您是谁？）

注意：在以60MHz执行加密的32位CPU上，EC没有任何优势，除非您的应用程序需要非对称加密而不是身份验证，这是因为用户和引导加载程序之间的线路不安全

因此，您可以使用引导加载程序的“公钥”对固件进行加密，引导加载程序使用其“私钥”对固件进行解密，但是，由于非对称算法的计算量很大，因此实现成本很高

---

寻找“轻量级加密”，这是您的应用程序的典型特征。

AES的实现占用空间非常小。我会很惊讶，你可以安装ECC，但不能安装AES。这比我所能使用的CPU功率和MHz多得多。除此之外，你有那个小闪光灯吗？因为只要不混合使用加密原语和/或使用多线程，就可以共享RAM加密缓冲区。否则，尝试一种占用空间小的较新的流密码。顺便问一下，为什么需要加密固件？签名验证还不够吗？@owlstead，加密固件很常见。它可以很容易地防止竞争对手和黑客进行反向工程。@TJD我绝对适合AES。我想使用非对称加密，以便驻留在引导加载程序上的密钥只能用于解密。ECIES需要大量工作，我不需要所有这些功能。我正在寻找一种加密方案，它与AES一样强大，但使用单独的（私有/公共）密钥进行加密/decrypt@Sabdeep：每个非对称加密方案都使用对称密码来实际加密数据。唯一不能这样做的情况是加密的数据很少：小于50字节。即使这样，这也可能不是一个好主意，因为如果加密的数据不是随机的，非对称加密往往会泄露私钥信息。@HubertKario进一步解释：你需要随机填充来确保安全。通常，这是通过在加密原语发生之前应用的填充模式来完成的。例如，PKCS#1 v1.5和OAEP为RSA和ECIES为EC规定了这些标准。因此，基本上，可以加密的最大纯文本量是密文-开销-填充。由于EC有短键，您将没有太多的空间用于纯文本。此外，每个纯文本块都需要一个模幂运算，这对于CPU来说是非常昂贵的。@owlstead：是的，你说得对。我不记得在哪里读过它，但是如果你一遍又一遍地加密相同的数据（或者加密的数据有某种结构），那么就会有攻击来恢复单个位的私钥信息。总之，不使用混合加密不值得原始非对称加密带来的问题。@HubertKario for EC，在不随机加密两个不同值的情况下完全恢复所有私钥字节，正如Chaos Computer Club使用索尼的一个签名密钥所示（他们使用了一个）。我为误用术语道歉（我对密码学一无所知）。我的目标是保守固件的秘密，减少欺诈