2009-10-06 44 views
3

好吧,所以我打包了一個專有的二進制格式。這基本上是幾個不同柵格數據集的鬆散打包。無論如何,只要閱讀本文並拆包是一件容易的事。但現在在下一個版本中,柵格xml數據現在要使用AES-256進行加密(不是我的選擇,也沒有選擇)。AES和CryptoAPI解密?當你知道鑰匙/鹽

現在我們基本上發送了AES密鑰和他們正在使用的SALT,所以我們可以修改我們的解包器。

注意,這些鍵只是一個例子:

他們是每個63字節長的ASCII字符:

Key: "QS;x||COdn'[email protected]`X\/xf}6T7Fe)[qnr^U*HkLv(yF~n~E23DwA5^#-YK|]v." 
Salt: "|$-3C]IWo%g6,!K~FvL0Fy`1s&N<|1fg24Eg#{)lO=o;xXY6o%ux42AvB][j#/&" 

我們基本上要使用C++的CryptoAPI解密這個(我也是在這周只有程序員,明天就會上線,不是我們的錯)。我已經四處尋找了一個實現這個的簡單教程。不幸的是,我甚至無法找到一個教程,他們分別有鹽和密鑰。基本上所有我現在真的是一個小函數,需要一個BYTE數組。隨着它的長度。我怎樣才能做到這一點?

我已經花了大部分時間嘗試製作cryptoAPI的正面/反面。但其並不順利時期:(

編輯

所以我問他們是如何進行加密。他們使用C#,並使用RijndaelManaged的,從我的知識是不等同於AES。

EDIT2

奧凱終於得到了確切發生了什麼事情,他們發錯了鍵

他們正在做以下幾點:

填充= PKCS7 CipherMode = CBC 該鍵被定義爲一組十六進制的32字節。 IV也被定義爲一組32字節的十六進制數。

當我問他們時,他們拿走了鹽。

使用wincrypt.h頭文件在CryptoAPI中設置這些內容有多難?

+0

只要你的塊大小爲128位和你堅持到128位,192位或256位密鑰算法的名稱,你可以合理假設RijndaelManaged的== AES在具體細節http://blogs.msdn.com/shawnfa/archive/2006/10/09/The-Differences-Between-Rijndael-and-AES.aspx – 2009-10-06 14:27:41

+0

即使你的編輯,你仍然需要知道他們的編碼方案'將任意字節轉換爲可打印字符。另外,您需要確認密碼模式。密碼分組鏈接(CBC)? – 2009-10-06 14:29:26

回答

4

AES-256使用256位密鑰。理想情況下,系統中的每個密鑰應該具有相同的可能性。一個63字節的字符串應該是504位。首先需要弄清楚63個字符的字符串是如何轉換爲256位的(你給出的樣本不是base64編碼的)。接下來,「鹽」不是AES的固有部分。你可能指的是在密碼塊鏈模式下的初始化矢量(IV),或者你可能指的是以某種方式更新密鑰。

如果我猜測,我假設「SALT」是指IV,特別是CBC模式。

使用CAPI功能時(例如decrypt),您將需要了解所有這些信息。

如果所有這些聽起來令人困惑,那麼最好改變一下設計,這樣就不用擔心這樣做是正確的。加密很難。一個糟糕的步驟可能會使所有安全性失效。考慮在我的Stick Figure Guide to AES上看this comment

UPDATE:您可以將look at this for a rough starting指向C++ CAPI。你需要一個64字符的十六進制字符串來獲得256位(256位/(4位/字符)== 64字符)。您可以將字符轉換爲位。

再說一次,我必須警告,用IV和鑰匙快速鬆動會產生災難性的後果。我深入研究了AES/Rijndael,直到數學和門級,甚至編寫了我自己的實現。但是,在我的生產代碼中,如果可能的話,我仍然堅持使用經過良好測試的TLS實現。即使對於靜止的數據,最好使用higher level library

+0

謝謝,示例代碼工作正常。它現在只是一個巨大的繃帶。但它會讓我們滿意明天,直到我們可以評估一個真正的選擇。 – UberJumper 2009-10-06 22:47:09

-5

Rijndael算法是AES

+0

但是Rijndael不是AES! AES將塊大小限制爲128位,Rijndael允許從128位到256位進行塊化。 – bkausbk 2013-11-26 07:56:03

+0

我站好了。 AES是否基於Rijndael會公平嗎? – Calyth 2013-11-27 14:54:11