【问题标题】:does ruby-aes use padding by default?ruby-aes 默认使用填充吗?
【发布时间】:2014-02-15 20:09:57
【问题描述】:

我在 RoR 项目中使用以下内容:

somepass =Aes.encrypt_buffer(128, 'ECB', some_cypher_key, nil, pain_string)

使用这个库和方法ECB是否默认使用填充?

我最终想要做的是让一个 RoR 应用程序和一个 Java 应用程序能够从相同的简单字符串中创建相同的加密字符串。

在我使用的 Java 代码中: cipher = Cipher.getInstance("AES/ECB/PKCS5Padding", "SunJCE");

这两行代码不会创建相同的加密密钥。

【问题讨论】:

  • 我希望你的意思是他们不创建相同的加密块而不是相同的加密密钥?

标签: java ruby-on-rails aes


【解决方案1】:

Aes.encrypt_buffer 将使用填充,只是不是您期望的那种。它将用添加字节的值用 n 字节填充块。也就是说,如果需要增加15个字节,就用0x0f填充,如果需要增加5个字节,就用0x05填充。也就是说RFC-5652中描述的PKCS7。

您应该切换到 openssl 或将 Cipher.getInstance("AES/ECB/PKCS7Padding", "BC") 与 java 一起使用。

【讨论】:

  • 谢谢米兰。将 PKCS7 填充与提供者 BC 一起使用会产生与将 PKCS5 填充与提供者 SunJCE 一起使用时相同的结果。知道为什么吗?此外,我注意到一些密码返回一个前面带有“-”的加密密钥,但 ruby​​ 并非如此。有什么想法吗?谢谢
  • 自从我上次使用 pkc 标准已经有一段时间了,但我很快意识到 pkcs7 只是 pkc5 的扩展,可以处理更大的块。这就是为什么你会得到相同的结果。看起来您拥有的代码应该可以工作,但由于 ruby​​-aes 的标准实现错误,它并不是最像的。我的建议是改用 openssl 并重试。
  • 我是否有可能获得这些奇怪的密钥,因为我以错误的方式对密码中的字节进行编码?
猜你喜欢
  • 1970-01-01
  • 2019-01-19
  • 1970-01-01
  • 2015-11-27
  • 2020-05-26
  • 1970-01-01
  • 2013-06-23
  • 1970-01-01
  • 2011-06-12
相关资源
最近更新 更多