簡短的回答是肯定的。長的答案是「這取決於」。通過單詞「計算他的密鑰」,我假設你的意思是生成加密密鑰。如何生成密鑰與使用密鑰進行加密和解密的過程完全無關。
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