简短的回答是肯定的。长的答案是“这取决于”。通过单词“计算他的密钥”,我假设你的意思是生成加密密钥。如何生成密钥与使用密钥进行加密和解密的过程完全无关。
DcpCrypt是在Rijndael成为AES标准(很久以前)之前编写的。假设预标准Rijndael实现与AES(可能是)相同,则AES加密/解密互操作性应该是语言和实现中立,只取决于实现选项。
但是,这里是擦...识别这些选项,并将它们设置为相同的加密编解码器和解密编解码器可能会很棘手。
有什么选择?
- 链接模式;
- IV
- 消息如何被盐渍?如果有的话?
- 终止:AES不指定非密钥流式链接模式的阻塞方案。
- 通常,使用除AES以外的密码时,指定密钥编码方式也可能存在问题 - 但这不应该是AES的问题。
一旦确定了加密器使用的所有选项,就必须将相同的选项应用于解密器。这个问题并不是Rijndael/AES所特有的,但对所有密码都是通用的。顺便说一下,如果你为了压缩的目的而压缩,那么压缩之后的加密是毫无意义的。 Zip不会压缩任何内容已经是最大随机的文件,例如密文。
我建议您使用TurboPower LockBox 3在AES中进行加密,而不是使用DcpCrypt进行加密。 Dave Barton的DCPcrypt当天表现不错,但与标准并不一致,并且它不能安全地管理IV。
如果您使用LockBox,有什么选择?如果您在CBC模式下使用LockBox 3的AES编解码器,则通过将IV设置为随机数并预先发射来管理salting和IV。对于超过一个块的消息,通过密文窃取实现阻塞。对于短于一个块的消息,链接模式被强制为8位CFB,这是密钥流式传输。
此外,您对SHA256加密文件的评论没有任何意义。 SHA是散列,而不是密码。
是的。最坏情况:编写一个Delphi DLL,你可以从C#调用它解密它。幸运的是,有几种针对C#的加密/解密解决方案,甚至压缩/解压缩也不成问题。我只是不知道你可以使用哪些。 – 2010-11-18 11:31:00