弱鍵調度IDEA
為什麼 IDEA 會選擇如此弱的密鑰時間表？
IDEA 的密鑰調度是這樣工作的：將密鑰（128 位）分成 8 個輪密鑰，每個 16 位長。這是前 8 個“輪”鍵（每輪 6 個鍵）。將原始密鑰向左旋轉 25 位。重複此操作，直到我們獲得 8.5 輪所需的 52 輪密鑰。（最後“半”輪有 4 個密鑰。）這個密鑰調度是完全線性的，密鑰中的模式即使在最後一輪密鑰中也存在，幾乎沒有變化。密鑰中的大量零位對於密碼來說是非常有問題的，因為該數字在整個密鑰調度中保持不變。許多攻擊利用了這種行為。
這可以通過一個小範例加密來看出。（鑰匙 （ $ K $ ) 和明文 ( $ P $ ) 在十六進制格式中，省略了前導零字節。)
$$ K = 00, P = 00, \operatorname{IDEA}(K,P) = \text{0001 0001 0000 0000} $$ $$ K = 00, P = 01, \operatorname{IDEA}(K,P) = \text{0013 fff5 0012 0009} $$ $$ K = 00, P = 02, \operatorname{IDEA}(K,P) = \text{0191 0059 011c ff32} $$ $$ K = 00, P = 03, \operatorname{IDEA}(K,P) = \text{038f 0099 02d6 fe33} $$ $$ K = 00, P = \text{01f0}, \operatorname{IDEA}(K,P) = \text{1841 fbc1 ef20 f270} $$ $$ K = \text{0d50}, P = 00, \operatorname{IDEA}(K,P) = \text{3fb2 5ff2 055d 16a6} $$ （來源：IDEA 計算器（Java）） 對數據和加密過程的進一步分析表明，當大量零位在明文或密文中時，雪崩效應非常緩慢。為什麼沒有得到承認和解決？這種問題在 IDEA 被發明的時候還不為人所知嗎？或者這不是真正的問題，因為這種影響對隨機鍵的可能性很小？
論文“ Weak Keys for IDEA ”（1993，PDF）表明，即使是一個小的修正也可以解決這個問題，比如在使用之前對每個輪密鑰進行一個常數的異或運算。常數 $ \text{0dae} $ （16 位，十六進製表示法）被選為範例，但確切的值對於解決論文所述的問題並不重要。
有沒有描述IDEA開發過程的論文？也許他們可以解釋一些關於關鍵時間表的想法。
之所以選擇這樣一個弱密鑰調度，是因為當時密鑰調度“理論”還沒有得到很好的發展。設計人員只是稍微修改了 DES 的密鑰時間表。請記住，這些關鍵計劃必須針對硬體進行優化，任何額外的操作都會在面積方面產生一些成本。