尋求資料加密標準

1973年3月15日，政府徵求首個資料加密標準（DES）的候選方案。促使政府尋求一項標準以保護其非機密但敏感數據的原因有兩個。第一個原因是1965年的布魯克斯法案，該法案指示國家標準局制定標準，以規範聯邦政府電腦的採購與使用；第二個原因則是日益增長的壓力，要求保障政府所掌握的關於公民的數據安全，這一需求最終催生了1974年的隱私法。布魯克斯法案通過後，國家標準局的魯思·戴維斯便開始調查是否應對非機密政府通訊的交易進行加密；她認為應當加密，並在發出公開徵求意見之前，就尋求國家安全局協助開發一套合適的加密算法。

在1970年代初期，國家安全局的密碼學研究仍屬類比時期，主要致力於研發基於硬體的加密技術。當時的國家安全局數學家理查德 “迪基” 喬治回憶道：「國家安全局資訊保證部門大約有2500人從事密碼的評估與實作，但我們連一台電腦都沒有，全靠紙筆進行工作。」國家安全局的領導層並未投入於非硬體加密技術的研發。喬治進一步提到，1973年資訊保證部門的一位主管發現他在研發一種基於軟體的加密算法，便告誡他：「這方面的工作別超過你總工作時間的10%，因為我們永遠不會在軟體上運行密碼，加密工作還是要依靠可靠的硬體。」儘管面臨這些限制，國家安全局仍自認為是密碼學領域的領導者。喬治表示：

「使我們成為密碼學領導者的關鍵在於我們擁有最具挑戰性的問題。我們擁有世界上最優秀的設計師，並以嚴苛的標準檢視他們設計的密碼，尋找其中的漏洞——沒有人能夠獲得如此棘手的問題，這實在令人振奮。我們還擁有龐大的人才庫，每天都有上千名數學家齊聚一堂，研究這些問題並彼此交流資訊。正是這些最具挑戰性的問題，以及龐大的人才群體，讓我們得以主導整個領域，而我們確實做到了。」

在收到國家標準局要求研發DES的請求後，喬治回憶說：

「國家安全局內部各個層級展開了大量討論……技術層面上大家在探討我們是否能做到以及如何實現；而在更高層級，有人認為如果我們推出一個演算法，沒有人會採用，因為大家會懷疑那必定是內置了後門（也就是國家安全局故意設計的漏洞）。一旦有人發現了攻擊方法，他們就會認為我們確實在其中設置了後門，即便事實上我們並未如此。因此，從政治角度來看，不論我們採取何種方案，都可能給我們帶來災難性的後果。」

國家安全局的負責人告知國家標準局的對口主管，儘管該局不會自行創建DES演算法，但將對選定的演算法進行評估，以檢查是否存在已知的攻擊方式。這位負責人還對團隊說：「我要能向國家標準局的主管保證，這個演算法確實如宣傳中所述那般強大；如果我們發現任何問題，必定會如實告知他們。」隨後，一份官方的國家安全局歷史記錄對這一時期做了如下記載：

決定與國家標準局合作並非眾望所歸。從訊號情報的角度來看，一項優秀的行業標準可能會流入不利的領域，例如第三世界政府的通訊、毒品販子的通訊以及國際恐怖組織的運作。然而，國家安全局最近才發現美國政府和國防工業電話通訊中的大規模資料竊取行為。這一事實反而證明了另一種觀點——正如政府密碼學家及國家密碼學學校指揮官弗蘭克·羅列特自第二次世界大戰以來所主張的，從長遠來看，保護自身通訊的安全比利用敵方通訊來獲取情報更為重要。

國家標準局發出的徵求意見書中訂定了 DES 的多項標準。首先，該演算法不應該是祕密的，與過去許多加密系統不同；安全性應僅依賴於加密密鑰的保密性。其次，演算法必須能夠抵禦已知明文攻擊。在這種攻擊中，密碼分析者能同時獲取加密通訊與其明文內容，以協助其破譯密鑰。這一點十分重要，因為密鑰可能長期不變，而相關的明文資料可能因被竊取或因正常業務操作（例如草擬中的新聞稿被洩露是敏感的，但一旦發布便應廣泛傳播）而公開。第三，針對該演算法，唯一可行的攻擊方式應僅為窮舉攻擊，即暴力破解——必須嘗試所有可能的密鑰，而這種攻擊在經濟上應當不可行。

最初在聯邦公報中發布的徵求意見並不理想；僅有三位教授響應，而他們均要求金錢來研究這一問題，而非提供現成的演算法，因此國家標準局拒絕了他們的申請。隨後，因私營部門無法滿足要求，國家標準局轉向國家安全局，詢問是否能夠研發 DES。當國家安全局再次討論是否能夠創建此類演算法時，其研究與工程副主任霍華德·羅森布魯姆發現了 Lucifer 的存在。這一發現很可能與對 Lucifer 下達的發明保密令有關，可能是依據國家安全局內部某人的指示而進行的。喬治回憶說，他發現「主要設計者費斯特爾曾與國家安全局一同從事密碼工作，所以大家認為他確實知道自己在做什麼，這個演算法可能不錯。」儘管記錄不甚清楚，費斯特爾在劍橋研究中心期間可能曾與國家安全局合作。IBM 與國家安全局之間關係密切；據艾倫·孔海姆回憶，「國家安全局的員工每隔幾個月就會前來了解 IBM 的最新進展。」此外，IBM 的首席科學家路易斯·布蘭斯科姆曾任國家標準局負責人。鑑於雙方關係密切，國家標準局的丹尼·布蘭斯塔德博士直接向 Tuchman 提出請求，要求 IBM 提交 Lucifer 作為候選演算法。

在IBM紐約總部召開了一次會議，討論國家標準局的徵求要求。Lucifer經歷了無數小時的設計與改進，若將其作為候選方案提交，意味著必須放棄專利，讓其他公司也能利用這項演算法，並大幅降低IBM的投資回報。儘管IBM仍保有在晶片上實作與優化該演算法的秘訣，以及利用現有客戶群的能力，但一旦失去獨家擁有可行商用密碼的優勢，從中獲得的龐大回報將無法實現。IBM的副指揮官保羅·里佐與其他高層主管鮑勃·埃文斯和布蘭斯科姆傾聽著Tuchman的懇求，要求他們將Lucifer保持為專有技術。Tuchman後來反思自己宛如「走狗、資本主義好戰分子」，他堅信Lucifer是市場上最優秀的密碼，能夠為IBM在未來數年提供持續的競爭優勢。Tuchman更記錄下里佐那既感人又令人難忘的回應：「如果通用汽車完善了一種全新且更優越的安全帶，我相信他們會與競爭對手共享，而不會將其用作商業競爭優勢。」最終，決定將該演算法提交給國家標準局。Tuchman駕車返回他位於Kingston的實驗室時，回想起自己從未如此以IBM為榮，他感慨自己那好戰的資本主義心態已被徹底消磨。

隨著IBM加入，國家標準局必須盡職調查是否還會有其他候選演算法出現，因此進行了第二次DES徵求。共收到三份回應：一份來自另一位教授，要求資金以研究這個問題；一份來自一家商業公司，他們擁有一種演算法，但希望將其保持專有，從而阻止公眾對其進行審查；以及來自Lucifer的回應。最終，Lucifer被選定為DES的候選演算法。國家安全局隨即開始對Lucifer進行分析。多名IBM員工獲得了安全許可，可以向國家安全局詢問任何有關Lucifer的問題，而國家安全局也奉命如實回答；喬治評論說，國家安全局與IBM密切合作，確保提交的成果正確無誤。國家安全局成立了一支團隊來評估DES，不久後又成立了影子評估團隊，在不通知第一團隊的情況下對其工作進行審查，接著又成立了第二個影子團隊，評估第一影子團隊的工作。喬治回憶道：「我不知道究竟有多少團隊在監督這些團隊，但似乎每個人都參與其中，卻又沒有人真正知曉全貌……這真是一個瘋狂的系統。」

資料加密標準採用了資料加密演算法（Lucifer），這是一種區塊密碼，每次加密64位元的資料區塊。Lucifer屬於對稱演算法，即同一密鑰既用於加密也用於解密（與之相對的非對稱／公鑰演算法則需使用兩個獨立但數學上相關的密鑰分別進行加密與解密）。雖然該密鑰以64位元變數表示，但每隔八位用作奇偶校驗，目的是確保密鑰無誤，使得實際有效的密鑰長度僅為56位元。儘管8位元的差異看似微小，但每增加一位密鑰長度，密鑰強度便會加倍，因此64位元的密鑰遠遠優於56位元。此奇偶校驗位的使用後來引起了公眾的廣泛關注。

該演算法採用了克勞德·香農在其1948年發表的經典論文《傳訊數學理論》中所定義的兩個基本密碼學原則。混淆使得密文與原始明文之間的關係變得模糊，其理念在於即便輸入資料中的單一位元發生變化，也應影響到大部分甚至全部的密文，從而令破解分析變得困難。擴散則指明文輸出中的統計冗餘特性，可防範依賴頻率分析等技術的破解（例如在英語中某些字母，如「E」，的出現頻率較高）。實現擴散最簡單的方式便是透過換位（亦稱為排列變換），即重排明文中字母的順序。DES 利用置換盒（S盒）來同時運用混淆與擴散原則，對明文施行16次數學運算迭代，以產生最終的密文。國家安全局對 IBM 提出的 S盒設定了八項必須滿足的標準，但還有一項 IBM 不知情的額外標準。這秘密的第九項標準涉及一項機密技術——差分密碼分析，即研究輸入差異對輸出所造成的影響，藉此發現可能揭示演算法弱點的非隨機結果。喬治回憶說：

「我們原以為 IBM 達到這些標準不會成問題，因為我們認為很容易就能設計出不易受差分密碼分析影響的排列，結果發現實際上非常困難，IBM提交的 S盒中竟無一例符合那第九項標準。」

因此，國家安全局直接生成了滿足全部九項標準的 S盒，並交付 IBM，告知這些即為 DES 所使用的 S盒。不久後，公眾得知國家安全局介入了 S盒的設計，喬治回憶說：

消息傳出後，大家普遍認為這些 S盒中可能暗藏後門，於是大量研究工作投入到試圖弄清這個「後門」究竟是什麼。研究結果證實這些 S盒並非隨機生成，而是必須滿足那第九項嚴格標準。儘管外界對此多有疑慮，但這並無大礙，因為該演算法是為滿足美國商業利益而設計，美國國內的使用情況也證明其運作良好。

儘管國家安全局或許並不希望 DES 在全球範圍內不受密鑰長度限制地使用，但 IBM 卻希望將其銷往全球市場。由於密碼學產品被歸類為軍火，Tuchman 因此向商務部申請 DES 的出口許可。如果 IBM 不被允許出口具有56位強度的 DES 產品，將會帶來兩大不利後果。首先，IBM 將不得不為所有含密碼學技術的產品生產兩個版本：一個供國內使用，另一個則為外銷市場提供，但後者的加密強度較弱。這不僅會大幅提高生產成本，也可能導致國內外市場均使用加密能力較弱的產品，而非承擔生產兩種不同產品的額外成本；實際上，市場力量將使出口限制實質上轉化為國內限制。其次，隨著外國公司認識到並滿足日益增長的密碼學需求，IBM 將在不久的將來面臨失去市場份額的風險。

國家安全局告知 IBM，其演算法中的多個元件，例如 S 盒，要麼是重新發明的，要麼是基於國家安全局本身機密的數學資料庫，因此用於設計該演算法的大量數學分析無法公開。正是這項限制引發了後續許多爭議，研究人員推測圍繞 S 盒設計的保密，實際上是因為國家安全局在其中植入了一個漏洞，作為該演算法的存取或後門機制。這項設計亦必須保密，因為在驗證過程中，IBM 發現了差分密碼分析技術。Coppersmith 表示，在與國家安全局討論後，決定若公開設計考量，將會洩露差分密碼分析的技術，從而削弱美國的競爭優勢。這份保密範圍還包括 IBM 為內部認證該演算法而進行的密碼分析工作，據 IBM 所稱，該工作投入了約十七人年的努力。

DES 密鑰長度的決定則直達國家安全局高層。密碼分析團隊曾主張使用 16 位元密鑰，喬治評論說：「沒有人會接受那樣的方案，那簡直是一個笑話。」但該團隊最為擔心的是，這會讓他們「教會世界如何製作出優秀的密碼」。為防止國家安全局的方法在 DES 的設計中顯露無遺，國家安全局局長下令，除非變更對安全性至關重要，否則不得對 DES 進行任何修改。當時考慮的密鑰長度有 56 位、64 位、80 位和 128 位，為了解 DES 所需達到的安全標準，局長諮詢了國家安全局的 Jim Frazer。在 1950 年代，Frazer 發展了國家安全局版本的摩爾定律，以預測技術演進，他的方法更為細緻，涵蓋計算機科學中眾多重要領域，使得國家安全局能夠制定出其認為對政府通訊設備所必需的適當安全等級。局長問 Frazer：「為了確保未來安全，我必須將密鑰設計得多大？」Frazer 回答說：「要應付到 1990 年，你需要 56 位，但到了 1990 年就必須撤銷認證，因為 1991 年後它就會容易受到攻擊。」局長隨即致電給國家標準局的對口負責人，表示：「我們選擇 56 位，這能保證安全到 1990 年底。」國家標準局的負責人則回應：「我們只會使用它 3 到 4 年，之後就會換成下一代版本，這當然可以。」那麼，為什麼國家安全局不選擇更大的密鑰長度以提高安全性呢？喬治評論說：「選擇 56 位，是因為我們被問到‘必須達到多好的水平？’你總希望把它限定在『足夠好』的程度。如果過度設計，最終結果要麼是它被使用的時間超出預期，要麼就是因為過度設計而引入了某些問題。」這也引發了公眾對於為何不將密鑰長度增至 64 位甚至 128 位的疑慮，擔心國家安全局將密鑰強度設定在一個他們知道未來數年內能夠透過窮舉攻擊輕易破解的水平。