2

问题是，在处理不同平台时使用加密和解密时可以遵循的最可取的方法是什么。

据我所知，每当一个人想要处理这样的场景时，他/她都必须考虑到某些事情。比如说，

  1. 加密/解密算法
  2. 填充图案
  3. 两边的字符编码
  4. 密码密钥和块大小

当然，一个人想要使用的加密/解密算法必须在双方都相同，我想我可以对剩下的三件事说同样的话。

请建议我在处理以下或类似情况时要遵循的步骤。

  1. 在c中加密和在java中解密
  2. 在 php 中加密 & 在 java 中解密
4

3 回答 3

1

如果您真的对互操作性感兴趣，请尝试使用容器格式，例如 CMS。它部署了 BER/DER 编码的 ASN.1，它是消息结构的二进制编码（类似于 XML，它是消息的文本编码）。不幸的是，并非所有平台都包含此类消息格式，但如果支持它们，您可以合理地确定它们可以编码/解码消息。

PHP 很棘手，它要么依赖于 openssl 包装器，要么依赖于可怕的 mcrypt 库。

于 2012-09-07T23:52:41.110 回答
0

我会添加字节顺序（数字的小端与大端），但是，只要您选择相同的算法（和参数）和数据格式，在一个平台上加密的内容应该可以在另一个平台上解密，反之亦然。例如，这就是当今 SSL 的工作方式。

于 2012-09-05T04:39:08.480 回答
0

良好互操作性的一个非常重要的方面是标准合规性。

良好的加密标准带有测试向量。如果两端实现了相同的规范，并且相关的测试用例已经过验证，那么它们成功对话的机会就会大得多。

例如，假设您需要从密码中派生 AES 密钥。如果你使用 openssl，你可能会想使用 commonEVP_BytesToKey函数。不幸的是，这不是一个标准的推导算法，如果在另一端你也没有 openssl，你会发现自己有麻烦。使用像 PBKDF2 这样的标准会更好，因为您有一个大多数库都实现的清晰、知名且广泛使用的规范 ( RFC2898 )。

不幸的是，密码标准往往只关注原语，并且经常需要将几个原语移植在一起。“嫁接”可能被证明是互操作性分崩离析的领域。出于这个原因，我建议使用尽可能广泛的标准化算法，即使代价是一些额外的复杂性。

例如，如果您想加密某些东西，最好选择标准的身份验证模式，如 CCM（在RFC3610中定义）。您可以一次性获得以下互操作性：

  • 加密
  • 验证
  • 填充
  • IV的交付
于 2012-09-05T05:10:03.077 回答