如果没有原始大小,SlowAES 无法正确解密
第一次在这里发海报。这里的社区很棒。经过无数个小时的搜索,我无法找出我面临的这个问题的答案。
首先,也是最重要的,在加密/解密、密码学等方面,我不是专家。我只想这样做我在这个领域中的主要框架是 .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[] returnedBytes = System.Text.Encoding.ASCII.GetBytes(decrypted);
字节 padLengthByte =解密字节[解密字节.长度 - 1];
Char padLengthChar = Convert.ToChar(padLengthByte);
字符串 padLengthString = padLengthChar.ToString();
Int32 padLength = Int32.Parse(padLengthString);
我确信我做错了。再次强调,任何帮助总是值得赞赏的。
我的另一个问题是,您如何知道是否首先应用了填充以将其删除?如果'\07'代表7个字节的填充,如果最后一个字节是'\01\'怎么办?
First time poster here. Awesome community here. After endless hours of searching, I'm unable to figure out the answer to this problem I"m facing.
First and foremost, I'm no guru when it comes to encryption/decryption, cryptology, etc. I only want to go so far in this realm without getting lost. The primary framework I code on is .NET and I was asked to create an AES CBC implementation for C#, that can work on JavaScript and ActionScript 3. I've been successful with both but with JavaScript, I've ran into an issue.
I decided to use SlowAES AES implementation because it seems to be the most popular with the best interop.
Please see the following links regarding my issue...
Issue #9: http://code.google.com/p/slowaes/issues/detail?id=9
Basically my issue with SlowAES is, I cannot decrypt something correctly without knowing the length of the original, unencrypted text. This defeats the purpose right? I should be able to decrypt an encrypted string without needing to know the original string.
If I'm missing something, I would be grateful if pointed in the right direction. Thankfully, I'm okay because .NET AES implementation I've put together can decrypt what SlowAES encrypts, same with ActionScript 3's implementation.
At this point I would just like to have SlowAES decrypt correctly.
Updated
After following the help of Remus, I've determine that SlowAES is using PKCS5/7 padding scheme but does not remove it properly. Now my problem seems to be with C#, understanding Byte Arrays, etc.
I can see the last character in my decrypted text is '5' which is preceded by a '0'. This pattern continues 5 times. Now from what Remus said below, I'm supposed to subtract the decrypted string length by this number. But the pattern is '05', does that mean I double 5 making 10 then subtract 10 from my decrypted string length?
Also, what would be the easiest way of obtaining the number I need to subtract? I'm using the following to obtain the number currently:
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);
I'm sure I'm doing this wrong. Again any help is always appreciated it.
Another question I have is, how do you know if padding was applied in the first place in order to remove it? If '\07' represents 7 bytes of padding, what if the last byte was '\01\'?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
这是因为 SlowAES 显然没有实现常用的填充方案,例如 PKCS: 问题 4:实现 PKCS7 填充。即使库没有实现它,实现它对于您来说也很简单:一旦获得解密(填充)文本,只需分析最后一个块并从填充信息中扣除原始长度即可。如果我没记错的话,RFC2315 中描述了 PKCS7 填充。
已更新
如果使用 PKCS7 填充文本,解密文本中的最后一个字节将包含填充的长度。因此,您解密,然后从解密文本末尾删除与最后一个字节的值一样多的字符。例如。
PS:我会添加JavaScript代码,但我的JavaScript编码能力相当生疏。
That is because apparently SlowAES doesn't implement the commonly used padding schemes, like PKCS: Issue 4: Implement PKCS7 padding. Even if the library doesn't implement it, it's really trivial for you do implement it: once you get the decrypted (padded) text, just analyze the last block and deduct the original length from the padding info. The PKCS7 padding is described in RFC2315 if I'm not mistaken.
Updated
If text is padded with PKCS7 the very last byte in the decrypted text will contain the length of the padding. So you decrypt and then remove as many characters from the end of the decrypted text as the value on the last byte. Eg.
PS: I would add the JavaScript code, but my JavaScript coding skill is rather rusty.
您可以做的一件事是填充数据以四舍五入为完整的 128 位块大小。这样你就不必担心 PKCS#7 填充,因为你只是自己做的。不太理想,但至少你已经启动并运行了:)
One thing you can do is pad your data to round out to a complete 128-bit block size. that way you don't have to worry about PKCS#7 padding, because you just did it yourself. hardly optimal, but at least you're up and running :)