Security 是否可以使用64位I/O块大小实现AES？

我正在开发一个具有非常特定加密要求的应用程序：
我们需要加密/解密单个64位值，以保护内部体系结构的某些部分不受通过公共web端点进行反向工程的影响

问题是，现有的64位加密方法（如3DES）不够安全，无法满足我们的要求（据我所知）。
它们的执行速度也比AES慢，这是另一个痛点

我的问题是，我们是否可以用64位块来实现AES的输入和输出？

---

我们需要创建一个修改的AES算法吗？（如果我们这样做的话，就不是一个完全的交易破坏者。）

否。AES是通过4x4矩阵上的四个基本操作指定的：子字节、ShiftRows、MixColumns和AddKey

---

“8字节AES”将是一种根本不同的密码。特别是ShiftRows和MixColumns操作基于平方矩阵的概念。因此，任何“类似AES”的分组密码的块大小都需要是N（4，9，16，…）的平方。

AES仅针对128位块大小定义。如果有办法减小块大小，那就不再是AES了。分组密码并不是决定可以加密什么的唯一因素。操作模式决定了分组密码的实际应用方式

如果明文大小有限，可以在流模式下使用AES，例如（对计数器进行加密，并用明文对结果块进行异或）。此模式下的密文的长度与明文的长度相同。唯一的问题是，要使其安全，nonce（IV）对于同一密钥下的每个密文都必须是唯一的。如果您的系统能够跟踪nonce（它们可以是简单的96位全局计数器，如果明文长度不超过128位，则可以是128位全局计数器），那么您应该能够满足您的要求

CTR加密：

---

如果您有64位输入，那么您可以添加另一个64位的可移动填充以提供128位。通常使用AES加密128位。解密时，只需删除解密后的填充。有许多不同的填充方案。您将在许多AES库中找到一些，例如PKCS#7

对于固定长度的64位输入，您可以使用随机填充，前提是您始终知道哪些64位是数据，哪些64位是填充。将两者混为一谈将产生有害的后果

---

ETA：对于64位的值，您可以将其中两个值串联起来，形成一个128位的值。解密后将其拆分回64位。

只要使用192位密钥（168位有效密钥），您可能会使用3DE。这将为您提供大约112位的安全性。请注意，通常需要使用需要IV或nonce的模式，这可能会添加额外的数据。或者，你可以寻找一些关于格式保持加密的文章。你可以考虑另一种具有64位块大小（但是128位密钥）的算法，比如Misty1（Nesie选择；CoptReC候选）或Khazad（Nesie Enter）。或者您可以在“格式保留加密”模式（AES-FFX）中使用AES。好的，我明白您所说的AES需要“平方”字节数。但是他们是如何完成AES192和AES256的呢？这两个都不是字节的平方数。@AES192和AES256的键大小不同，但块大小与AES128相同。128、192、256是键大小，而不是块大小。钥匙已展开以使其适合。NIST有一份非常容易理解的规范文件，解释了密码的内部内容。@FreekWiekmeijer是的，那份文件让我很头疼。：）我刚看完这个讲座，真的很有帮助。问题是，我需要加密方法同时具有64位输入和64位输出。然后使用填充。向输入中添加填充，加密/解密并删除填充，返回原始的64位。我明白您的意思，但问题是我需要加密值也是64位值。使用填充生成128位加密值，在不破坏原始数据的情况下无法截断该值。