【问题标题】:SlowAES cannot decrypt properly without original size没有原始大小,SlowAES 无法正确解密
【发布时间】:2010-02-19 22:44:49
【问题描述】:

第一次在这里发布海报。这里很棒的社区。经过无数小时的搜索,我无法弄清楚我面临的这个问题的答案。

首先,在加密/解密、密码学等方面,我不是专家。我只想在这个领域走这么远而不迷路。我编码的主要框架是 .NET,我被要求为 C# 创建一个 AES CBC 实现,它可以在 JavaScript 和 ActionScript 3 上运行。我在这两个方面都取得了成功,但在使用 JavaScript 时,我遇到了一个问题。

我决定使用 SlowAES AES 实现,因为它似乎是最受欢迎的,具有最佳互操作性。

关于我的问题,请查看以下链接...

问题 #9:http://code.google.com/p/slowaes/issues/detail?id=9

基本上,我对 SlowAES 的问题是,如果不知道原始未加密文本的长度,我就无法正确解密某些内容。这违背了目的对吧?我应该能够在不需要知道原始字符串的情况下解密加密字符串。

如果我遗漏了什么,如果指出正确的方向,我将不胜感激。谢天谢地,我没事,因为我整合的 .NET AES 实现可以解密 SlowAES 加密的内容,与 ActionScript 3 的实现相同。

此时我只想让 SlowAES 正确解密。

更新

在 Remus 的帮助下,我确定 SlowAES 正在使用 PKCS5/7 填充方案,但没有正确删除它。现在我的问题似乎出在 C#、理解字节数组等方面。

我可以看到我的解密文本中的最后一个字符是“5”,前面有一个“0”。这种模式持续了 5 次。现在根据 Remus 下面所说的,我应该用这个数字减去解密的字符串长度。但是模式是“05”,这是否意味着我将 5 加倍为 10,然后从解密的字符串长度中减去 10?

另外,获得我需要减去的数字的最简单方法是什么?我正在使用以下方式获取当前的号码:

Byte[] decryptedBytes = System.Text.Encoding.ASCII.GetBytes(decrypted);
Byte padLengthByte = decryptedBytes[decryptedBytes.Length - 1];
Char padLengthChar = Convert.ToChar(padLengthByte);
String padLengthString = padLengthChar.ToString();
Int32 padLength = Int32.Parse(padLengthString);

我确定我做错了。再次感谢任何帮助。

我的另一个问题是,您如何知道是否首先应用了填充以将其删除?如果'\07'代表7个字节的填充,如果最后一个字节是'\01\'呢?

【问题讨论】:

    标签: encryption javascript rijndael aes


    【解决方案1】:

    这是因为显然 SlowAES 没有实现常用的填充方案,例如 PKCS:Issue 4: Implement PKCS7 padding。即使库没有实现它,实现它对你来说真的很简单:一旦你得到解密(填充)的文本,只需分析最后一个块并从填充信息中扣除原始长度。如果我没记错的话,RFC2315 中描述了 PKCS7 填充。

    更新

    如果使用 PKCS7 填充文本,则解密文本中的最后一个字节将包含填充的长度。因此,您解密然后从解密文本的末尾删除与最后一个字节上的值一样多的字符。例如。

    1. 原文是'This is the original text'。它的长度为 25。
    2. 加密会将长度填充为 32(下一个 16 大小的块),因此它将加密块“这是原始文本\07\07\07\07\07\07\07”。
    3. 填充块被加密为 32 长度的加密文本
    4. 您解密 32 长度的密码并从 2) 中取回填充文本
    5. 解密块的最后一个字节是'\07',所以你从解密块中减去7个字节。结果是原始文本,长度为 25:'This is the original text'

    PS:我会添加 JavaScript 代码,但我的 JavaScript 编码技能相当生疏。

    【讨论】:

    • RFC2315 第 10.3 节,注意 #2 用于填充。
    • 感谢 Remus 和 Greg 的快速回复。问题是其中一些绝对超出了我的想象。我不知道如何分析最后一个块。关于如何解决这个问题的任何提示或帮助都会很棒。再次感谢!
    【解决方案2】:

    您可以做的一件事是将数据填充为完整的 128 位块大小。这样您就不必担心 PKCS#7 填充,因为您只是自己完成的。几乎不是最优的,但至少你已经启动并运行了:)

    【讨论】:

    • 感谢迈克尔的意见。我不确定如何始终确保我的原始未加密文本始终是一个完整的 128 位块。就像我说的那样,我对这个密码学的东西很陌生,而且很多东西都在我的脑海里。再次感谢您的建议。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2021-05-16
    • 2017-10-16
    • 2014-07-14
    • 1970-01-01
    • 2016-06-09
    • 1970-01-01
    • 2019-04-07
    相关资源
    最近更新 更多