2009-11-02 203 views
2

我的問題有2個部分。第一個是「我可能使用哪種類型的加密」,另一個是「破壞它的可能性有多大」(只要找到加密算法)。解密類型和破解(AES 128?)

因此,我得到了原始文件和加密的文件,並且我能夠在原始文件中發生某些變化時測試加密的行爲。我發現最重要的線索:

  1. 原始和加密文件有相同的尺寸(請注意該尺寸的產品爲0x10 = 128位)

  2. 加密塊大小似乎是128位。當原始文件上的一個字節發生變化時,相同的128位塊會在加密文件上發生變化,有時(可能)會在前一個或下一個塊上發生變化。但大多數時候只有這個塊。而文件的其餘部分根本沒有改變。

  3. 有反覆上的原始文件(例如16個字節00值),但它們中的非區段具有對加密的文件相同的128比特的塊的結果。因此,第二個塊中的00個16字節的加密結果與下一個塊中的16個00字節不同。

在腦海中處理這些線索,你能猜到它會是什麼類型的算法嗎?我認爲這是一個AES 128位,但線索#2不包括CBC模式,而線索#3不包括ECB!似乎是「之間」的那些......在任何其他模式下它可能是AES 128嗎?你還能想什麼?

如果有一對已知的算法可能會導致這種行爲,那麼有什麼機會打破它,知道原始數據並能夠對2個文件的更改進行測試?

預先感謝

+2

「」當在原始文件的字節變化,[...}前面的[...]塊[變化],」你反覆檢查?這將使它在任何模式下,我有不同聽說過的。 – 2009-11-02 17:48:06

+0

我會嘗試再次檢查。也許這是因爲由2個字節改變對2塊,所以會再次嘗試予以肯定。 – SVicon 2009-11-02 18:32:15

回答

2

聽起來好像它是在ECB模式中,其中該明文塊進行異或與從該塊的文件中的位置在ECB模式加密之前得到的隨機數的變化。

這將導致所觀察到的特徵:

  • 不增加文件大小(所以因此沒有IVS);
  • 在輸入一個單一的字節變化影響的輸出的整個塊。

(現時值可以是作爲對簡單)。

該方案是薄弱。它將容易受到針對ECB模式的同類頻率分析攻擊的影響 - 它只需要更多的密文。此外,您收集的任何明文/密文對都可在您找到的任何未知密文中重複使用相同的塊位置。

+0

但在這樣的方案將不能解釋爲什麼(有時)塊或者在被修改的塊之後改變,否則我會認爲它也是這樣的(比如XEX,LRW或者XTS模式),但是這些模式都沒有這個鄰居修改屬性。 – 2009-11-04 14:36:43

+0

好吧,OP確實會說「可能」是關於那些變化的塊,所以我打了折扣。然而,如果文件被分割成不是塊大小的倍數的段,那實際上可能只是在像XTS這樣的模式下竊取密文的效果。 – caf 2009-11-05 00:15:19

+0

感謝您的幫助。也許這比CTR更有意義。我知道一些應該是最初所有00的部分,所以我想我可以對此做一些事情(「攻擊」00塊)。任何具體的建議? – SVicon 2009-11-07 19:35:57