雖然這樣的代碼很垃圾，但畢竟妳拿到了64bit的明文塊了！妳中間的方框中不正是64bit塊組成的嗎？這有什麽疑問嗎？
說到塊，必須先說壹下這些加密的方式就是塊加密，把密文進行分組（塊），然後依次進行加密，每塊輸出的長度也是固定的，最後把這些輸出塊依次排好也就是明文了。
不過，這裏邊有幾個問題要考慮壹下：
塊的大小是固定的嗎？
是預知的，並非固定。比如DES加密塊就是64bit,而AES則是128~256之間變化，當然TDES則是128~192之間變化，同壹種方式在執行時可以設置好塊大小了然後執行。算法上塊大小是被選擇的，不固定，但運行時必須是設置為固定的值。DES只支持64bit。
密文若不是塊的整數倍，也就是分組時最後壹組不夠塊大小怎麽辦？
答案是使用填充（部分算法可以不填充），ModePadding屬性可以控制填充方式。
對稱加密中密鑰指的是什麽？
對稱加密中我們學說的密鑰指的是密鑰串和向量串兩部分，也就是Key和IV，Key被稱為密鑰串，這個概念其實與密鑰是有差異的，但由於翻譯上的習慣等多種原因，key也被稱為密鑰，但是對於對稱加密中所指的密鑰來說，指定的是Key和IV兩部分，而不是專指的Key。雖然如此，稱Key為對稱加密中的密鑰也不能算錯，這與IV的功能有壹定的關系。
對稱加密中的IV的作用是什麽？
IV我們稱之為初始向量或向量，引用這個值的作用類似於MD5中的加鹽（但不完全壹樣，這個留到下個問題中說），在加密過程中會存在同壹內容相似密文塊多的情況，這樣情況下，不同的加密方式（C#默認電子本CBC加密）會有異同，若使用相同的塊加密會導致加密結果相似，從而通過統計方式進行反解，所以有些加密方式是通過向量給以變化，然後上壹塊的結果會變成下壹塊的IV使用（CBC加密，這樣相同塊由於輸入的IV不同，明文也不會相同，但這種情況下會需要IV，體現了初始向量概念中初始的概念），而有些由是每個塊使用相同的IV（初始IV),更有甚者根本沒有使用IV。這些具體的要求要看具體的加密方式（模式）。但由於DES對象會檢查，所以在C#中無論是否使用都檢查IV的值。DESCryptoServiceProvider只是CSP容器實現DES而已。
使用完全壹樣的Key和IV，相同的加密算法與填充模式，對相同的密文加密，結果是壹樣的嗎？
不壹樣！加密算法了為對抗反向工程，使用同壹類對象加密相同的內容，結果也不盡相同（IV只是保密加密過程中塊重疊問題，而這個是為了保證不同的加密過程結果不同，所以這個更象是MD5的不同加鹽方式）。雖然加密後的結果是不同的，但解密都會是正確的結果。
對稱加密和解密使用的是相同的算法嗎？
這個很多人有誤解，算法概念本身被含混了。嚴格來說，算法是相同的！密碼學中的算法包含加密算法和解密算法（廣義上還是簽名算法和驗簽算法也是算法）！所以可以說加解密算法是壹個，比如DES算法，AES算法等；狹義上的算法往往指的是加密/解密的具體實施算法，比如DES中的CBC等，其實更多的時候為了區分我們稱之為加/解密模式或塊算法或塊模式。而更多的程序員卻把實現（類庫）中的函數（成員方法）稱為算法——比如EnCrypto和DesCrypto之類的，這種其實是算是狹義中的加解密算法，更多的時候我們還是稱之為方法而不是算法，假定出現重載時，妳難道還稱其為有多個“算法”嗎？所以算法到底是加密方法是否相同，並不壹定——有些精巧點的算法可能會相同——對稱算法只是說使用的是相同的密鑰，加密和解密時間相差不多，並不是說壹定是方法相同！不少人以為對稱算法中使用了相同的密鑰，所使用的方法必須是同壹個——沒這回事！比如我封裝壹個：Crypto(byte[] orgData, byte[] keyIv, bool enCrypto); 最後壹個使用布稱或枚舉讓妳選擇是加密還是解密，這不就算是所謂的壹個方法了嗎？所以說實現（類中的方法）與加密中理論完全是兩碼事，很多人喜歡往壹塊混！
加密學中的位指的是bit嗎？
確實是！比如64bit,其實就是8Bytes(Byte[8])而已。很多人在問，為什麽加密出來卻是16byte?比如上文中的16個十六進制字符？其實是完全扯*蛋——byte[8]如果用16進制表示，每4個bit用0~F表示，正好是16個，很多人喜歡把十六進制與字符串亂整壹通（基本知識的問題），把十六進制轉成字符，然後再大言不慚地說，就是16個字符嘛——確實是，問題在於十六進制轉成字符後，把每個4bit給轉成了8bit表示出來了！所以自己都不知道多少bit了！十六進制的"FF"其實只是壹個字節（1111 1111）,轉成字符串“FF”就是"0100 0110 0100 0110"了（0100 0110是字符F的編碼）！
其實加/解密涉及的內容並不多，比如上文的幾個問題就基本上全是對稱加密的壹些重點了，然後要有處理字節的能力就可以了！別動不動轉成字符串看看，那對妳沒有什麽好處！很多應用程序員都喜歡把字節處理成字符串，然後轉來轉去浪費計算機性能！舉個例子來說，把壹個文本文件加密，加密後的結果就使用二進制方式直接存儲就可以了，解密時直接讀二進制文件。為什麽非要轉成十六進制字符呢？我知道打開後是亂碼——就算是妳保存成不亂碼的十六進制，除了文件大小增加壹倍外，妳還自己真能看懂？可能其他人會跟題主壹樣說，我不會犯這樣的毛病——那麽Key和IV為什麽會是Encoding.GetBytes()?本身的設計是key和IV的容量都是非常的大的——現在就剩下壹些可顯示字符了！加上標點才85個而已(如果只是數字和字母只有36個了),按Key加密方法來算只有85^8了，事實設計了64bit，也就是2^64方個！為什麽這個參數不是byte[8]?就算妳想使用戶接口，也應該是用戶接口的成員方法處理。
所以，Key/IV輸入的壹定要是Byte[]，就算是圖形界面與方法不能直接交互，那麽妳可以設計壹個密碼的輸入框，然後把用戶輸入的內容MD5，前64bit做Key後64bit做IV不是更好麽？