什么是c#.NET和java中常见的AES加密填充

时间:2020-12-27 17:02:28

I want to know which padding modes for AES encryption are common in both java and C#.NET

我想知道AES加密的哪种填充模式在java和C#.NET中都很常见

Thanks Bapi

3 个解决方案

#1


None, PKCS7, Zeros

没有,PKCS7,Zeros

Dotnet supports these 3 as do all the JCE providers.

与所有JCE提供商一样,Dotnet支持这3个。

If you're looking for java<->.net AES I would recommend Bouncy Castle, they have libs for both free.

如果你正在寻找java < - > .net AES我会推荐Bouncy Castle,它们都有免费的库。

http://www.bouncycastle.org/

#2


A couple padding algorithms are outlined at Wikipedia. I have seen PKCS7 used in some significant applications (the Oracle client, for example). It's dead simple to implement, so you wouldn't have to worry if either platform does not support it out of the box.

*概述了几种填充算法。我已经看到PKCS7用于一些重要的应用程序(例如Oracle客户端)。它实现起来很简单,所以如果任何一个平台都不支持开箱即用,你就不用担心了。

#3


I was working on a class project and figured out a few details the hard way. First, Java supports PKCS7 padding out of the box but under a different name. It's called PKCS5. Some programmers use Bouncy Castle because of the mistaken belief that Java does not support PKCS7, but supports a different (older) padding type. This shouldn't really matter, except that Bouncy Castle turned out to have terrible bugs. My project relied on their implementation of AES. While it works if you encrypt all the data at once with a single doFinal, encrypting blocks goes horribly wrong and the outcome even changes depending on the buffer size used to pass the data. Switching back to Sun's implementation gave the correct results with the same code. Needless to say, that costed us a few days of debugging.

我正在研究一个班级项目,并努力找出一些细节。首先,Java支持开箱即用的PKCS7填充,但名称不同。它叫做PKCS5。一些程序员使用Bouncy Castle,因为他们错误地认为Java不支持PKCS7,但支持不同的(较旧的)填充类型。这应该不重要,除了Bouncy Castle被证明有可怕的错误。我的项目依赖于他们的AES实施。虽然如果使用单个doFinal一次加密所有数据,它可以工作,但加密块出现严重错误,结果甚至会根据用于传递数据的缓冲区大小而改变。切换回Sun的实现,使用相同的代码得到了正确的结果。不用说,这花费了我们几天的调试成本。

#1


None, PKCS7, Zeros

没有,PKCS7,Zeros

Dotnet supports these 3 as do all the JCE providers.

与所有JCE提供商一样,Dotnet支持这3个。

If you're looking for java<->.net AES I would recommend Bouncy Castle, they have libs for both free.

如果你正在寻找java < - > .net AES我会推荐Bouncy Castle,它们都有免费的库。

http://www.bouncycastle.org/

#2


A couple padding algorithms are outlined at Wikipedia. I have seen PKCS7 used in some significant applications (the Oracle client, for example). It's dead simple to implement, so you wouldn't have to worry if either platform does not support it out of the box.

*概述了几种填充算法。我已经看到PKCS7用于一些重要的应用程序(例如Oracle客户端)。它实现起来很简单,所以如果任何一个平台都不支持开箱即用,你就不用担心了。

#3


I was working on a class project and figured out a few details the hard way. First, Java supports PKCS7 padding out of the box but under a different name. It's called PKCS5. Some programmers use Bouncy Castle because of the mistaken belief that Java does not support PKCS7, but supports a different (older) padding type. This shouldn't really matter, except that Bouncy Castle turned out to have terrible bugs. My project relied on their implementation of AES. While it works if you encrypt all the data at once with a single doFinal, encrypting blocks goes horribly wrong and the outcome even changes depending on the buffer size used to pass the data. Switching back to Sun's implementation gave the correct results with the same code. Needless to say, that costed us a few days of debugging.

我正在研究一个班级项目,并努力找出一些细节。首先,Java支持开箱即用的PKCS7填充,但名称不同。它叫做PKCS5。一些程序员使用Bouncy Castle,因为他们错误地认为Java不支持PKCS7,但支持不同的(较旧的)填充类型。这应该不重要,除了Bouncy Castle被证明有可怕的错误。我的项目依赖于他们的AES实施。虽然如果使用单个doFinal一次加密所有数据,它可以工作,但加密块出现严重错误,结果甚至会根据用于传递数据的缓冲区大小而改变。切换回Sun的实现,使用相同的代码得到了正确的结果。不用说,这花费了我们几天的调试成本。