軟體加密原理：為什麼非對稱加密
因此，現代軟體幾乎都採用「混合加密」：用非對稱加密解決身分驗證與金鑰協商，用對稱加密保護真正的大量資料。這個分工是理解 TLS、SSH、Signal、PGP 等協定的關鍵。換句話說，非對稱加密不是用來取代對稱加密，而是用來補上對稱加密最缺的那一塊：在陌生人之間建立可信的共享秘密。
二、非對稱加密的核心原理：一對金鑰的數學魔法
非對稱加密（Asymmetric Encryption），又稱公開金鑰密碼學（Public-Key Cryptography），使用一對數學上相關但無法輕易互相推導的金鑰：公開金鑰（Public Key）與私密金鑰（Private Key）。公鑰可以公開散布，私鑰必須嚴格保密。這對金鑰的分工，讓軟體可以在公開網路上完成過去必須靠安全通道才能做到的事。
公鑰與私鑰：一對金鑰的非對稱分工
最常見的用途是「公鑰加密、私鑰解密」。假設 Alice 想傳訊息給 Bob，Bob 先把自己的公鑰公開。Alice 用 Bob 的公鑰加密訊息，只有持有對應私鑰的 Bob 能解密。中間人就算截獲密文與公鑰，也無法還原明文。這個流程解決了「如何把機密資料傳給一個從未共享金鑰的人」的問題。
另一種同樣重要的用途是「私鑰簽章、公鑰驗章」。Bob 用私鑰對訊息摘要簽章，任何人只要取得 Bob 的公鑰，就能驗證簽章是否確實由 Bob 的私鑰產生，且訊息未被竄改。數位簽章不提供保密性，但提供身分認證、完整性與不可否認性。實務上，加密與簽章是兩種不同操作，不能混為一談：用公鑰加密是為了讓只有私鑰持有者能讀；用私鑰簽章是為了讓所有人能驗證來源。
這裡有一個常見誤解：公鑰加密並不會自動證明「對方就是本人」。如果攻擊者把網站公鑰替換成自己的公鑰，使用者仍可能被騙。因此，非對稱加密必須搭配憑證、信任鏈、網域驗證或可信第三方，才能建立完整的身分信任。這也是為什麼 TLS 不是只有加密，還包含憑證驗證。
單向函數與陷阱門：數學上的「容易去、難回來」
非對稱加密之所以可行，建立在「單向函數」與「陷阱門」之上。單向函數是指正向計算很容易，反向推導卻極度困難。例如把兩個大質數相乘很容易，但要把一個很大的整數分解回兩個質因數，目前沒有已知的高效率演算法。RSA 的安全性，很大程度上就建立在這個大整數分解難題上。
「陷阱門」則是說：雖然反向推導對一般人很難，但如果你掌握某個秘密資訊，就能輕易完成反向運算。私鑰就是這道陷阱門。沒有私鑰的人，只能面對巨大的計算複雜度；有私鑰的人，則能快速解密或簽章。這種「公開資訊不足以推導私鑰」的特性，是非對稱加密安全性的核心。
除了大整數分解，常見的數學難題還包括離散對數問題與橢圓曲線離散對數問題。不同演算法建立在不同的難題上，也因此有不同的金鑰長度、效能與安全假設。當量子電腦的發展威脅到這些難題時，整個非對稱加密體系就必須遷移到後量子密碼學，這也是近年軟體架構必須提前思考的議題。
數位簽章與金鑰交換：非對稱的兩種用法不要混淆
非對稱密碼學在實務上有兩大類用法。第一類是「金鑰交換或金鑰封裝」：雙方利用非對稱機制協商出一把只有彼此知道的對稱金鑰，之後再用這把對稱金鑰加密大量資料。TLS 1.3 的 ECDHE 金鑰交換就是典型例子。第二類是「數位簽章」：用私鑰簽署，用公鑰驗證，常見於軟體更新簽章、憑證簽發、程式碼簽章與文件簽章。
這兩類用法常被混稱為「非對稱加密」，但嚴格來說，金鑰交換本身不一定直接加密資料。Diffie-Hellman 是一種金鑰協商協定，雙方交換公開參數後各自算出共享秘密，過程中並沒有「用公鑰加密訊息」的動作。理解這個差異，在評測軟體時很重要：看到「採用非對稱加密」這句話，應該進一步問清楚是加密、簽章、金鑰交換，還是三者都有。
此外，非對稱加密通常不會直接拿來加密大量資料。除了效能考量，還有訊息長度限制與填充（Padding）問題。RSA 直接加密的資料長度受限於金鑰大小，實務上多半只用來封裝一把對稱金鑰，或加密雜湊值與簽章。這也是混合加密架構成為主流的技術原因。
三、主流非對稱演算法評測：RSA、橢圓曲線、Ed25519 與後量子
談到非對稱加密，許多人第一個想到的是 RSA。但現代軟體實際上使用多種演算法，依場景選擇。以下從相容性、效能、金鑰尺寸、安全性與遷移風險等角度，評測幾個主流選項。
RSA：相容性王者，但成本與尺寸是硬傷
RSA 在 1977 年由 Rivest、Shamir 與 Adleman 提出，歷史悠久、支援度極高，幾乎所有作業系統、函式庫與硬體都支援。它的安全性建立在大整數分解難題上，常見金鑰長度為 2048 位元與 3072 位元，更高階場景會使用 4096 位元。RSA 可用於加密與簽章，在憑證、SSH、電子簽章與舊系統整合中仍非常常見。
然而 RSA 的缺點也很明顯。第一，金鑰與簽章尺寸大：RSA-2048 的簽章約 256 位元組，公鑰也相對龐大；對行動裝置、物聯網與高頻 TLS 握手而言，傳輸與儲存成本較高。第二，運算成本較高，尤其是私鑰操作與大量簽章驗證。第三，填充模式必須正確：加密應使用 OAEP，簽章應使用 PSS，舊式的 PKCS#1 v1.5 在特定情境下有風險。第四，RSA 不具備後量子安全性，未來需要遷移。
從評測角度來看，RSA 並不是「不好」，而是「適用於相容性優先、遷移成本高的場景」。如果一套新軟體沒有歷史包袱，卻仍只提供 RSA-1024 或使用不安全的填充模式，這就是明顯的警訊。相對地，使用 RSA-3072 以上、搭配 OAEP 或 PSS、並有金鑰輪替計畫的系統，仍在可接受範圍內。
橢圓曲線密碼學：行動裝置與 TLS 的主流選擇
橢圓曲線密碼學（Elliptic Curve Cryptography，ECC）建立在橢圓曲線離散對數難題上。它的最大優勢是「較短的金鑰提供較高的安全強度」。例如 256 位元的橢圓曲線金鑰，安全強度大致相當於 3072 位元的 RSA 金鑰，但簽章、公鑰與運算成本都小得多。這讓 ECC 成為行動裝置、TLS、SSH 與物聯網的熱門選擇。
常見的 ECC 應用包括 ECDH／ECDHE 金鑰交換、ECDSA 簽章與 Ed25519 簽章。TLS 1.3 大量使用 ECDHE 進行金鑰協商，並以 ECDSA 或 Ed25519 憑證進行身分驗證。ECDHE 的「E」代表 Ephemeral，也就是暫時性金鑰：每次連線產生新的金鑰對，用完即丟，提供前向保密（Forward Secrecy）。即使伺服器私鑰日後外洩，攻擊者也無法解密過去錄下的連線內容。
ECC 的實作細節比 RSA 更容易出錯，例如曲線參數選擇、隨機數產生、簽章隨機值重用等。歷史上曾發生 ECDSA 隨機數重複導致私鑰外洩的案例。因此，評測時不只要看「有沒有用 ECC」，還要看是否使用標準曲線（如 P-256、P-384、Curve25519）、是否使用成熟函式庫、是否避免自製曲線與自製隨機數產生器。
Ed25519：現代簽章的高效選項
Ed25519 是基於 Edwards 曲線的 EdDSA 簽章演算法，近年快速普及。它的公鑰只有 32 位元組，簽章只有 64 位元組，簽章與驗章速度都很快，且設計上避免了一些傳統 ECDSA 的實作陷阱。SSH、TLS、Signal、Git 簽章、軟體套件簽章與許多現代協定都支援 Ed25519。
Ed25519 的優點包括：金鑰與簽章緊湊、速度快、實作相對簡單、預設使用 SHA-512 且不需要額外隨機數來產生簽章（ deterministic 簽章），降低了隨機數品質不佳的風險。不過，Ed25519 主要用於簽章，不用於金鑰交換；若需要金鑰協商，通常會搭配 X25519。評測時應確認軟體是否正確區分簽章與金鑰交換用途，並檢查是否支援金鑰輪替與憑證鏈。
後量子密碼學：下一場遷移已經開始
非對稱加密有一個必須正視的長期風險：量子電腦。Shor 演算法理論上可以在量子電腦上有效率地解決大整數分解與離散對數問題，這意味著 RSA、ECC、Diffie-Hellman 等主流非對稱機制在足夠強大的量子電腦面前將不再安全。雖然實用級量子電腦尚未普及，但「先錄下密文、等未來再解密」的攻擊模式，讓長期機密資料現在就面臨風險。
美國國家標準與技術研究院（NIST）已推動後量子密碼學標準化，並在 2024 年公布多項標準，包括以 Kyber 為基礎的 ML-KEM（FIPS 203）、以 Dilithium 為基礎的 ML-DSA（FIPS 204），以及 SLH-DSA（FIPS 205）。軟體架構師現在就應該盤點哪些系統使用非對稱加密、哪些資料需要長期保護、哪些通訊協定需要支援混合式後量子金鑰交換。評測新軟體時，「是否具備密碼學敏捷性」已經成為重要指標：能不能在不改動應用邏輯的情況下替換演算法與金鑰長度。
以下表格整理幾種常見非對稱機制的特性，方便快速比較。請注意，安全強度與金鑰長度不是單純的數字比大小，實際安全性還取決於參數、實作與協定設計。
機制
主要用途
常見金鑰／簽章尺寸
優勢
注意事項
RSA-2048／3072
加密、簽章、憑證
簽章約 256／384 位元組
相容性極高、生態成熟
尺寸大、速度較慢、需正確填充
ECDSA P-256
簽章
簽章約 64 至 72 位元組
金鑰短、效能好、TLS 支援廣
隨機數品質要求高、實作需謹慎
Ed25519
簽章
公鑰 32 位元組、簽章 64 位元組
速度快、尺寸小、實作陷阱較少
主要用於簽章，不用於金鑰交換
X25519
金鑰交換
公鑰 32 位元組
高效、適合 ECDHE
需搭配簽章或憑證驗證身分
ML-KEM（Kyber）
金鑰封裝
依參數而定，較傳統 ECC 大
抗量子、標準化進行中
效能與封包尺寸需評估、生態仍在成熟
四、為什麼實務軟體採用「混合加密」：非對稱談判，對稱傳輸
理解了非對稱加密的優點與成本之後，就能明白為什麼現代軟體幾乎都採用混合架構。非對稱加密負責「建立信任」與「協商金鑰」，對稱加密負責「保護大量資料」。這種分工讓系統同時享有非對稱加密的身分驗證能力與對稱加密的效能。
TLS 1.3 握手流程拆解
以瀏覽器連線 HTTPS 網站為例。TLS 1.3 的握手大致包含以下步驟：客戶端送出 ClientHello，包含支援的密碼套件、金鑰交換參數與隨機數；伺服器回應 ServerHello，選定參數並提供金鑰交換資訊；雙方透過 ECDHE 或後量子混合機制協商出共享秘密；伺服器用憑證與私鑰簽章證明身分；客戶端驗證憑證鏈、網域與有效期；最後雙方衍生出對稱金鑰，改用 AES-GCM 或 ChaCha20-Poly1305 加密應用資料。
TLS 1.3 與舊版 TLS 1.2 的一個重要差異，是移除靜態 RSA 金鑰交換，預設要求具備前向保密的 (EC)DHE。這讓即使伺服器私鑰在未來外洩，攻擊者也不能解密過去錄下的工作階段。對軟體評測而言，支援 TLS 1.3、使用 AEAD 密碼套件、具備前向保密、憑證驗證嚴格，都是基本門檻。若一套軟體仍允許 TLS 1.0／1.1、RC4、3DES 或靜態 RSA 金鑰交換，就應該被列為高風險。
值得注意的是，非對稱加密在 TLS 中扮演兩種角色：ECDHE 負責金鑰協商，憑證簽章負責身分驗證。兩者缺一不可。只有金鑰協商而沒有憑證驗證，會讓中間人有機可乘；只有憑證而沒有前向保密，則會讓長期私鑰成為單點風險。混合架構的價值，就在於把這些風險分散到不同機制上。
從 SSH 到 Signal：不同軟體如何取捨
SSH 是另一個常見例子。SSH 連線建立時，雙方先透過 Diffie-Hellman 或 ECDH 協商工作階段金鑰，再用主機金鑰與使用者金鑰進行身分驗證。使用者第一次連線時會看到主機指紋，本質上這是一種「首次使用即信任」（TOFU）模型。這種設計適合技術人員管理伺服器，但對一般使用者不夠友善，因此才需要憑證授權與金鑰管理系統來補強。
Signal 等通訊軟體則採用更複雜的雙棘輪機制，結合 X25519 金鑰交換、Ed25519 簽章、對稱金鑰衍生與訊息金鑰輪替，提供端對端加密與前向保密。這類系統的評測重點不只是「有沒有端對端加密」，還包括：金鑰驗證機制是否可被中間人攻擊、裝置新增與移除時金鑰是否更新、備份與多裝置同步是否破壞端對端保證、以及伺服器是否能取得明文。
PGP／GPG 則是另一個極端案例。它使用非對稱加密保護對稱金鑰，再用對稱金鑰加密郵件或檔案，技術上可行，但使用者體驗與金鑰管理一直是痛點。金鑰遺失、撤銷憑證、信任網（Web of Trust）與金鑰伺服器汙染等問題，讓 PGP 在一般使用者間難以普及。這說明了一個重要觀點：加密原理正確，不代表軟體產品成功；金鑰管理與使用者體驗，往往才是決定安全性的關鍵。
五、非對稱加密的實作陷阱與軟體評測檢查表
非對稱加密的數學很優雅，但實作卻充滿細節。許多真實世界的資安事件，不是因為演算法被破解，而是因為填充錯誤、隨機數不足、憑證驗證被忽略、金鑰管理鬆散，或開發者自製密碼學。以下整理常見陷阱與評測時應該檢查的項目。
常見錯誤：填充、隨機數、憑證驗證
第一類錯誤是填充與模式誤用。RSA 加密若使用舊式 PKCS#1 v1.5 填充，在特定情境下可能遭受 Bleichenbacher 類型的選擇密文攻擊；實務上應優先使用 OAEP。簽章則應使用 PSS 或 Ed25519 等現代方案。對稱加密方面，應使用 AEAD 模式，避免 ECB 這類會洩漏明文模式的模式。
第二類錯誤是隨機數品質。非對稱金鑰產生、ECDSA 簽章、對稱金鑰與 IV 產生，都依賴高品質的密碼學隨機數。若使用一般偽隨機數產生器、時間戳或可預測種子，金鑰可能被推導出來。歷史上已有因隨機數重複而導致私鑰外洩的案例。評測時應確認軟體使用作業系統提供的 CSPRNG，並且不在多個裝置間共用同一組隨機數來源。
第三類錯誤是憑證驗證不完整。有些行動 App 或內部系統為了「方便」，會忽略憑證鏈驗證、接受自簽憑證、不檢查主機名稱，或把憑證固定（Pinning）做成無法更新的硬編碼。這些做法會讓中間人攻擊變得容易。相反地，良好的實作會完整驗證憑證鏈、有效期、主機名稱與撤銷狀態，並設計可更新的 Pinning 或公鑰固定策略。
第四類錯誤是自製密碼學。許多團隊會自行設計加密流程、金鑰衍生函式或簽章格式，卻沒有經過密碼學專家審查。密碼學的細節非常容易出錯，使用成熟且持續維護的函式庫（如 OpenSSL、BoringSSL、libsodium、wolfSSL 等）通常是更安全的選擇。評測時若看到「自行研發加密演算法」或「獨家加密技術」這類宣傳，應保持高度懷疑。
金鑰管理與效能取捨
非對稱加密的金鑰管理比對稱加密複雜。私鑰應該存放在受保護的環境中，例如硬體安全模組（HSM）、雲端金鑰管理服務（KMS）、作業系統的 Keychain／Keystore、TPM 或 Secure Enclave。私鑰不應出現在程式碼、設定檔、版本控制系統或日誌中。金鑰需要有產生、啟用、輪替、停用與銷毀的完整生命週期管理。
效能方面，非對稱操作通常是連線建立時的主要成本。伺服器可以透過連線重用、TLS session ticket、OCSP stapling、憑證鏈優化與硬體加速來降低負擔。行動裝置則應避免在每次請求都執行完整的非對稱握手，並注意憑證鏈長度與簽章驗證成本。對於高頻交易、物聯網或低功耗裝置，選擇 ECC、Ed25519 或輕量級協定，通常比 RSA 更合適。
另一個常被忽略的點是「密碼學敏捷性」。系統應該能夠在不改動應用程式邏輯的情況下，替換金鑰長度、演算法與憑證格式。當 SHA-1 退場、RSA 金鑰長度提升、TLS 1.3 普及、後量子遷移啟動時，敏捷性會決定系統能否平順升級。評測時可以問：更換憑證是否需要重新編譯？是否支援多種簽章演算法？金鑰輪替是否需要停機？這些問題比單純比較演算法名稱更有實務價值。
資安評測時應該問的十個問題
以下檢查表可作為軟體評測的起點。它不是完整的安全稽核，但能快速辨識高風險訊號：
連線是否使用 TLS 1.3 或至少 TLS 1.2，並停用已知不安全的密碼套件？
是否支援前向保密（ECDHE 或 DHE），而非靜態 RSA 金鑰交換？
憑證驗證是否完整，包括鏈、主機名稱、有效期與撤銷狀態？
是否使用成熟密碼學函式庫，而非自製加密或自製隨機數？
私鑰是否存放在 HSM、KMS、Keychain、Keystore 或 TPM 等受保護環境？
是否有金鑰輪替、撤銷與備份政策？
RSA 是否使用 OAEP 與 PSS，或已改用 ECC／Ed25519？
對稱加密是否使用 AEAD 模式，並避免 ECB 與固定 IV？
是否具備密碼學敏捷性，能因應後量子遷移？
端對端加密產品是否明確說明伺服器可見的資料範圍與金鑰持有者？
這十個問題看似基本，卻能過濾掉大量不合格的產品。實務上，許多資安事故不是因為攻擊者突破了 AES 或 RSA，而是因為憑證驗證被關閉、私鑰被寫進程式碼、隨機數可預測，或開發者為了「先讓功能跑起來」而暫時停用加密。非對稱加密提供的是架構上的信任基礎，但這個基礎需要正確的工程實作才能成立。
六、結論：非對稱不是取代對稱，而是補上信任的最後一哩
回到最初的問題：為什麼需要非對稱加密？答案不是「因為對稱加密不安全」，而是「因為對稱加密無法獨立在開放網路上解決金鑰分發與身分驗證」。非對稱加密讓陌生人之間能在不安全的通道上協商共享秘密、驗證身分、簽署資料，並建立可擴展的信任鏈。它讓電子商務、行動通訊、軟體更新、雲端服務與物聯網得以在沒有事先共享金鑰的前提下安全運作。
但非對稱加密不是萬靈丹。它運算成本高、金鑰與簽章尺寸大、實作細節多，且面臨量子電腦的長期挑戰。因此，現代軟體採用混合加密：用非對稱機制建立信任與協商金鑰，用對稱機制保護大量資料。TLS 1.3、SSH、Signal、PGP 與無數軟體系統，都是這個分工的具體實踐。
對「雅寶社區 · 頂客論壇」的讀者而言，無論你是開發者、資安人員或一般使用者，理解非對稱加密的價值與限制，都能幫助你更準確地評估一套軟體。看到「軍規加密」、「獨家演算法」這類行銷詞彙時，先問它用了什麼協定、金鑰怎麼管理、憑證怎麼驗證、是否支援前向保密與後量子遷移。真正值得信任的軟體，通常不會只告訴你「有加密」，而是能清楚說明它如何建立信任、如何保護金鑰，以及如何在演算法退場時優雅地遷移。
非對稱加密的偉大之處，不在於它比對稱加密更快或更強，而在於它補上了對稱加密最難跨越的那一哩路：讓互不相識的雙方，仍能在公開網路上安全地開始對話。理解了這一點，你就掌握了現代軟體加密架構的核心脈絡。