iOS AES256解密

Question

我需要解密使用AES256加密的字符串。

例如：這是一個加密的字符串：“ U2FsdGVkX18egiyzJUY5gHS ++ 2trNSYNSEXpJicKPBE =”使用此密鑰：“ 70ca7c5b0f58ca290d39613fa3644251”與AES256算法

示例字符串已使用以下方式加密：

https://code.google.com/p/crypto-js/

有多種工具可用於解密AES256加密的字符串： https : //github.com/AlanQuatermain/aqtoolkit/tree/master/CommonCrypto

https://github.com/RNCryptor/RNCryptor

https://github.com/Gurpartap/AESCrypt-ObjC

我已經嘗試了所有方法，但沒有一個方法能夠解密我的字符串。 我確定它已正確加密，因為我可以使用此在線工具對其進行解密：

http://www.appcove.com/tool/aes

請幫我。

謝謝喬治

-------------- 編輯 --------------

您能推薦API（js）/ iOS的對稱加密/解密算法嗎？ 您用來加密API上的字符串並在iOS應用上對其進行解密的內容。

謝謝

Answer 1

為了幫助您入門：

This is an encrypted string: "U2FsdGVkX18egiyzJUY5gHS++2trNSYNSEXpJicKPBE="

這不是加密的字符串。 它是加密字節數組的Base64呈現。 為了解密它，您首先需要將其從Base64轉換回字節數組。

using this key: "70ca7c5b0f58ca290d39613fa3644251"

這不是關鍵。 這是字節數組的十六進制字符串表示形式，它可以是實際密鑰，也可以用於派生實際密鑰。 您需要將其從十六進制字符串轉換回字節數組。

with the AES256 algorithm

您在這里需要更多信息：至少是模式和填充。

正在使用什么模式？ AES-ECB，AES-CBC，AES-CTR或其他模式？ 瀏覽說明以嘗試找出答案。 正如Zaph的評論所說，缺少IV或Nonce可能表示ECB模式。 ECB模式是不安全的， 不將其用於任何生產代碼。

您還需要知道使用了什么填充。 Zaph說PKCS7填充很常見，但是問題源應該告訴您。 您需要設置解密方法以期望正確的填充。

Answer 2

我將為您提供一個簡單的流程來展示AES的工作原理：

為了清楚起見，我將使用偽目標c使其對您來說易於理解，並且對我而言是快速的。

// Here comes encryption process:
NSString *key           = @"fsd7f897sfd8sfds…";
NSString *secretMessage = @"Confidential text";

AES *aes = [AES sharedAES];
NSString *encryptedMessage = [aes encryptWithKey:key message:secretMessage];

// Now is time for decryption:
Base64   *base64           = [Base64 sharedBase64];
NSString *messageToDecrypt = [base64 decode:encryptedMessage];
NSString *decryptedMesage  = [aes decryptWithKey:key message:messageToDecrypt];

// Now you should have the result:
NSLog(decryptedMesage);

---

看看http://travistidwell.com/jsencrypt/

Answer 3

從Google文檔中：

對於密鑰，當您傳遞字符串時，將其視為密碼短語並用於派生實際密鑰和IV。 或者，您可以傳遞代表實際鍵的WordArray。 如果通過實際密鑰，則還必須通過實際IV。

對於CryptoJS.AES.encrypt()

是將字符串作為鍵傳遞進來，另一個鍵也將被派生，也是iv。 這將是一個兼容性問題，因為必須知道實際密鑰派生的方法以及iv派生和在iOS中重復的方法。

以上都不是標准。

解決方案是使用JavaScript將密鑰作為正確大小（256位）的WordArray和WordArray iv傳遞。

或根據文檔：

“您可以定義自己的格式，以便與其他加密實現兼容。格式是具有兩種方法的對象（字符串化和解析），可在CipherParams對象和密文字符串之間進行轉換。

然后，使用這些相同的加密/解密即可在iOS中進行匹配。

這是我發現的一些信息，這是WRT在base64編碼之前的加密數據：

前8個字節是“ Salted__”，可能由Javascript解密用來了解要使用的方法。
接下來的8個字節是隨機的。 對於使用相同密鑰對相同數據進行的每次加密，它們是不同的。它們可以從具有隨機分量的密鑰派生而來。
接下來的字節以16個字節為一組（塊大小），正好足以包含數據和填充。 填充總是添加至少一個額外的字節。

由於iv是隨機的， 因此對於具有相同數據和密鑰的每次加密， 加密字節將有所不同 ，但是可以通過某種方式使用密鑰和前導字節來重新生成密鑰和iv，從而恢復字節。 該方法不是秘密，只是我不知道。

當然，這並不是特別有幫助，但確實顯示了問題。