『壹』 c#的AES加密解密問題
不是初學，而是對.net中所有的加解密方式都沒有弄清楚。不過別灰心——很多自以為會的人也沒有弄清。
首先，.net中類庫中支持各類摘要加解密方式。一般情況下我們將安全分為兩類，一類是摘要，一類是加解密。加密解又分為對稱與非對稱加解密。
在.net體系中，不管是摘要還是加解密，為了統一演算法方式，一律都是流方式進行的。不管是MD5摘要還是ADE/DES/TDES/RSA等等。一定要記住的第一條，是流方式進行的！
流——這個概念很多人也不清楚，因為stream的范圍還是非常的大的，有網路流responseStream等，基本文本流，IO流等等，在加密時我們使用了一個流叫「加解密流」CryptStream，該流用來實現加解密及摘要演算法等等。
那麼CryptoStream是個什麼流呢？它算是轉換流，把一種形式轉換成另一種形式，比如把密文轉換成明文或把明文換成密文。正常的情況下，我們可以用流寫流的方式來實現，比如MemoryStream來換流。當然，也可以把byte[]數組直接寫到流中。
流這部分說完了，那麼，其實我們如何區別CryptoStream是加密還是解密呢，除了說明之外，還是一個方式，就是看流的方式是讀還是寫！所以當我看到你的解密流中使用的方式竟然是Write,而不是Read，所以你對加解密方式並沒有真正理解。
比如，我們可以轉換後的流直接進行ReadToLine即可。
老實說，你這種寫法有很大問題——有關stream大部分都是非託管，所以一定要記著Dispose，或Close（Close時會自動調用Dispose)。防止出現錯誤等內存泄露。
有於加解密流，我們經常一句話，加密方式是Write,解密方式是Read!
『貳』 php AES加密 openssl解密失敗，幫忙看下代碼哪裡有問題
用Zend的加密吧，但是還是可以解密的，這也沒辦法，凡是對稱加密或非不可逆的加密演算法，均可以解密，這只是時間問題。
特別是沒有密碼的加密（不可逆除外）。
可以這樣，使用AES加密，再用GZIP壓縮，然後運行時解密，在eval那些代碼。
前提是每個加密的文件的密碼都不同，要購買才可以解密運行。
『叄』 為什麼windows下aes解密android上的加密文件失敗
1.程序加密可結合AES演算法，在程序運行中，通過外部晶元中的AES密鑰，加密數據來驗證雙方的正確性，稱之為對比認證。2.加密數據傳輸過程中，可通過AES加密後形成密文傳輸，到達安全端後再進行解密，實現數據傳輸安全控制。3.綜合1和2，當前高大上的方式是程序加密可進行移植到加密晶元，存儲在加密晶元中，運行也在加密晶元內部運行，輸入數據參數，返回執行結果，同時輔助以AES加密和認證，實現數據程序的全方位防護
『肆』 java編程一個AES加密txt文件的程序，其中AES解密文件的方法出錯，求大神搭救
你是對文件內容加的密，應該和文件類型無關把。如果用的是
AES演算法加的密的話，初始化的時候就會寫到
keygen = KeyGenerator.getInstance("AES");
//生成密鑰
deskey = keygen.generateKey();
//生成Cipher對象,指定其支持的DES演算法
c = Cipher.getInstance("AES");
加密和解密的過程幾乎是一樣的，AES是對稱加密方式，你看看加密和解密方法里的有沒有寫錯的地方。
『伍』 php AES加密 openssl解密失敗，幫忙看下代碼哪裡有問題
請放上代碼
使用VS2005下的Visual Studio 2005 Command Prompt進入控制台模式（這個模式會自動設置各種環境變數）
、解壓縮openssl的包,進入openssl的目錄
、perl configure VC-WIN32
盡量在這個目錄下執行該命令，否則找不到Configure文件，或者指定完整的Configure文件路徑。
、ms\do_ms
在解壓目錄下執行ms\do_ms命令
、nmake -f ms\ntdll.mak編譯後在openssl解壓目錄下執行，完成編譯後。輸出的文件在out32dll裡面，包括應用程序的可執行文件、lib文件和dll文件
注意：在運行第五步時，cl編譯器會抱怨說.\crypto\des\enc_read.c文件的read是The POSIX name for this item is deprecated（不被推薦的），建議使用_read。呵呵，我可不想將OpenSSL中的所有的read函數修改為_read。再看cl的錯誤代碼 error C2220，於是上MSDN上查找：
warning treated as error - no object file generated
/WX tells the compiler to treat all warnings as errors. Since an error occurred, no object or executable file was generated.
是由於設置了/WX選項，將所有的警告都作為錯誤對待，所以。。。
於是打開OpenSSL目錄下的MS目錄下的ntdll.mak文件，將CFLAG的/WX選項去掉，存檔。
『陸』 AES 加密解密爬坑
加密，要長度為 （16 *n）,則getInstance("AES/ECB/NoPadding")中NoPadding是關鍵
public static byte[] encrypt(byte[] key, byte[] data) throws Exception {
SecretKeySpec skeySpec = new SecretKeySpec(key, "AES");
Cipher cipher = Cipher.getInstance("AES/ECB/NoPadding");//"演算法/模式/補碼方式"
cipher.init(Cipher.ENCRYPT_MODE, skeySpec);
byte[] encrypted = cipher.doFinal(data);
return encrypted;
}
public static byte[] decrypt(byte[] key, byte[] data) throws Exception {
SecretKeySpec skeySpec = new SecretKeySpec(key, "AES");
Cipher cipher = Cipher.getInstance("AES/ECB/NoPadding");
cipher.init(Cipher.DECRYPT_MODE, skeySpec);
byte[] decrypted = cipher.doFinal(data);
return decrypted;
}
『柒』 AES加解密使用總結
AES, 高級加密標准, 是採用區塊加密的一種標准, 又稱Rijndael加密法. 嚴格上來講, AES和Rijndael又不是完全一樣, AES的區塊長度固定為128比特, 秘鑰長度可以是128, 192或者256. Rijndael加密法可以支持更大范圍的區塊和密鑰長度, Rijndael使用的密鑰和區塊長度均可以是128，192或256比特. AES是對稱加密最流行的演算法之一.
我們不去討論具體的AES的實現, 因為其中要運用到大量的高等數學知識, 單純的了解AES流程其實也沒什麼意義(沒有數學基礎難以理解), 所以我們今天著重來總結一些使用過程中的小點.
當然了分組密碼的加密模式不僅僅是ECB和CBC這兩種, 其他的我們暫不涉及.
上面說的AES是一種區塊加密的標准, 那加密模式其實可以理解為處理不同區塊的方式和聯系.
ECB可以看做最簡單的模式, 需要加密的數據按照區塊的大小分為N個塊, 並對每個塊獨立的進行加密
此種方法的缺點在於同樣的明文塊會被加密成相同的密文塊, 因此, 在某些場合, 這種方法不能提供嚴格的數據保密性. 通過下面圖示例子大家就很容易明白了
我們的項目中使用的就是這種模式, 在CBC模式中, 每個明文塊與前一個塊的加密結果進行異或後, 在進行加密, 所以每個塊的加密都依賴前面塊的加密結果的, 同時為了保證第一個塊的加密, 在第一個塊中需要引入初始化向量iv.
CBC是最常用的模式. 他的缺點是加密過程只能是串列的, 無法並行, 因為每個塊的加密要依賴到前一個塊的加密結果, 同時在加密的時候明文中的細微改變, 會導致後面所有的密文塊都發生變化. 但此種模式也是有優點的, 在解密的過程中, 每個塊的解密依賴上一個塊的加密結果, 所以我們要解密一個塊的時候, 只需要把他前面一個塊也一起讀取, 就可以完成本塊的解密, 所以這個過程是可以並行操作的.
AES加密每個塊blockSize是128比特, 那如果我們要加密的數據不是128比特的倍數, 就會存在最後一個分塊不足128比特, 那這個塊怎麼處理, 就用到了填充模式. 下面是常用的填充模式.
PKCS7可用於填充的塊大小為1-255比特, 填充方式也很容易理解, 使用需填充長度的數值paddingSize 所表示的ASCII碼 paddingChar = chr(paddingSize)對數據進行冗餘填充. (後面有解釋)
PKCS5隻能用來填充8位元組的塊
我們以AES(128)為例, 數據塊長度為128比特, 16位元組, 使用PKCS7填充時, 填充長度為1-16. 注意, 當加密長度是16整數倍時, 反而填充長度是最大的, 要填充16位元組. 原因是 "PKCS7" 拆包時會按協議取最後一個位元組所表徵的數值長度作為數據填充長度, 如果因真實數據長度恰好為16的整數倍而不進行填充, 則拆包時會導致真實數據丟失.
舉一個blockSize為8位元組的例子
第二個塊中不足8位元組, 差4個位元組, 所以用4個4來填充
嚴格來講 PKCS5不能用於AES, 因為AES最小是128比特(16位元組), 只有在使用DES此類blockSize為64比特演算法時, 考慮使用PKCS5
我們的項目最開始加解密庫使用了CryptoSwift, 後來發現有性能問題, 就改為使用IDZSwiftCommonCrypto.
這里咱們結合項目中邊下邊播邊解密來提一個點, 具體的可以參考之前寫的 邊下邊播的總結 . 因為播放器支持拖動, 所以我們在拖拽到一個點, 去網路拉取對應數據時, 應做好range的修正, 一般我們都會以range的start和end為基準, 向前後找到包含這個range的所有塊范圍. 打比方說我們需要的range時10-20, 這是我們應該修正range為0-31, 因為起點10在0-15中, 20 在16-31中. 這是常規的range修正.(第一步 找16倍數點).
但是在實際中, 我們請求一段數據時, 還涉及到解密器的初始化問題, 如果我們是請求的0-31的數據, 因為是從0開始, 所以我們的解密器只需要用key和初始的iv來進行初始化, 那如果經過了第一步的基本range修正後, 我們請求的數據不是從0開始, 那我們則還需要繼續往前讀取16個位元組的數據, 舉個例子, 經過第一步修正後的range為16-31, 那我們應該再往前讀取16位元組, 應該是要0-31 這32個位元組數據, 拿到數據後,使用前16個位元組(上一個塊的密文)當做iv來初始化解密器.
還有一個要注意的點是, 數據解密的過程中, 還有可能會吞掉後面16個位元組的數據, 我暫時沒看源碼, 不知道具體因為什麼, 所以保險起見, 我們的range最好是再向後讀取6個位元組.
感謝閱讀
參考資料
https://zh.wikipedia.org/zh-cn/%E9%AB%98%E7%BA%A7%E5%8A%A0%E5%AF%86%E6%A0%87%E5%87%86
https://segmentfault.com/a/1190000019793040
https://ithelp.ithome.com.tw/articles/10250386
『捌』 為什麼windows下aes解密android上的加密文件失敗
你的Cipher生成好像缺了很多步聚，而且如果只需要加／解密，用CipherInputStream和CipherOutputStream應該更方便。
我把你的代碼完整改了一下（幾乎面目全非）。已包含加密和解密的方法，一套即用。除了Cipher生成那方法比較難明外，其他部份都很簡單，相信你一看就明。
『玖』 uniappaes解密前面部分亂碼
每次加解密都需要重新生成一個AES對象。
在CBC模式，同個AES對象，所有之前的加解密會影響下一次加解密(加密解密誰先誰後影響都一樣)，因為CBC是Blockchained的，加密的時候是串列的，需要依賴上個塊的加解密結果，可以理解為它是有記錄中間狀態的過程，所以下一次加解密使用原來的AES對象存在問題，ECB模式則沒有這個問題，解決方法：每次加解密都需要重新生成一個AES對象。
亂碼是指由於本地計算機在用文本編輯器打開源文件時，使用了不相應字元集而造成部分或所有字元無法被閱讀的一系列字元。亂碼包括文本亂碼、文檔亂碼等。