1. 項(xiàng)目概述為什么RSA在Java中依然至關(guān)重要最近在整理一個(gè)老項(xiàng)目的安全模塊發(fā)現(xiàn)里面還在用簡(jiǎn)單的對(duì)稱加密處理一些敏感信息傳輸這讓我心里一驚。在當(dāng)今這個(gè)數(shù)據(jù)安全被提到前所未有高度的環(huán)境下作為開發(fā)者如果對(duì)非對(duì)稱加密尤其是RSA沒有一個(gè)扎實(shí)的掌握和實(shí)戰(zhàn)經(jīng)驗(yàn)心里總是不太踏實(shí)。RSA算法這個(gè)以三位發(fā)明者姓氏首字母命名的公鑰加密體系自1977年誕生以來幾乎成了非對(duì)稱加密的代名詞。盡管后起之秀如ECC橢圓曲線加密在性能和密鑰長(zhǎng)度上展現(xiàn)出優(yōu)勢(shì)但RSA憑借其堅(jiān)實(shí)的數(shù)學(xué)基礎(chǔ)、廣泛的支持和易于理解的工作原理依然是數(shù)字簽名、SSL/TLS握手、密鑰交換等核心安全場(chǎng)景的中流砥柱。對(duì)于Java開發(fā)者而言無論是處理用戶密碼的加密傳輸、實(shí)現(xiàn)API接口的簽名驗(yàn)簽還是構(gòu)建需要高安全等級(jí)的系統(tǒng)模塊RSA都是一項(xiàng)必須掌握的技能。你可能在面試中被問到它的原理也可能在項(xiàng)目中直接調(diào)用Cipher.getInstance(RSA/ECB/PKCS1Padding)這樣的代碼。但僅僅會(huì)調(diào)用API是遠(yuǎn)遠(yuǎn)不夠的理解其背后的數(shù)學(xué)邏輯、密鑰對(duì)的生成過程、填充模式的選擇以及在實(shí)際應(yīng)用中如何避免常見的“坑”比如廣為人知的“RSA Public Key Not Find”這類錯(cuò)誤才是從“會(huì)用”到“精通”的關(guān)鍵。這篇文章我就結(jié)合自己多次在項(xiàng)目中集成RSA加密的經(jīng)驗(yàn)從原理到代碼從生成密鑰到處理異常系統(tǒng)地拆解一遍目標(biāo)是讓你看完后不僅能自己動(dòng)手實(shí)現(xiàn)一個(gè)健壯的RSA工具類更能深刻理解每一步背后的“為什么”。2. RSA加密的核心原理與數(shù)學(xué)基礎(chǔ)拆解要真正用好RSA而不是僅僅當(dāng)一個(gè)API調(diào)用者我們必須先穿過它那層看似復(fù)雜的數(shù)學(xué)面紗。放心我們不需要成為數(shù)論專家但必須理解幾個(gè)核心概念這能幫助你在遇到問題時(shí)比如為什么不能加密過長(zhǎng)的數(shù)據(jù)立刻找到根源。2.1 非對(duì)稱加密的基石公鑰與私鑰與AES這類對(duì)稱加密使用同一把密鑰加解密不同RSA使用一對(duì)數(shù)學(xué)上相關(guān)聯(lián)的密鑰公鑰和私鑰。公鑰可以公開給任何人用于加密數(shù)據(jù)私鑰必須嚴(yán)格保密用于解密由對(duì)應(yīng)公鑰加密的數(shù)據(jù)。反過來私鑰也可以用于簽名公鑰則用于驗(yàn)證簽名這就實(shí)現(xiàn)了身份認(rèn)證。這種“單向性”和“配對(duì)性”是理解所有非對(duì)稱加密應(yīng)用的起點(diǎn)。2.2 關(guān)鍵數(shù)學(xué)過程密鑰生成RSA的安全性建立在大數(shù)分解的困難性上。密鑰生成過程可以概括為以下幾步選擇兩個(gè)大質(zhì)數(shù)p和q這是整個(gè)安全性的基礎(chǔ)。這兩個(gè)數(shù)必須足夠大如今通常要求2048位甚至更長(zhǎng)并且是隨機(jī)生成的質(zhì)數(shù)。在Java中KeyPairGenerator類在初始化時(shí)會(huì)自動(dòng)完成這一步。計(jì)算模數(shù)nn p * q。n的長(zhǎng)度就是密鑰長(zhǎng)度如2048位。n會(huì)被包含在公鑰和私鑰中是公開的。但攻擊者從n反向分解出p和q在計(jì)算上是不可行的。計(jì)算歐拉函數(shù)φ(n)φ(n) (p-1) * (q-1)。這個(gè)值必須保密它在后續(xù)計(jì)算中起到關(guān)鍵作用。選擇公鑰指數(shù)ee是一個(gè)整數(shù)需要滿足1 e φ(n)且e與φ(n)互質(zhì)最大公約數(shù)為1。通常選擇一個(gè)較小的質(zhì)數(shù)如65537 (0x10001)。這個(gè)值也是公開的包含在公鑰里。選擇65537是因?yàn)樗诙M(jìn)制表示中只有兩個(gè)1計(jì)算效率高且安全性經(jīng)過充分驗(yàn)證。計(jì)算私鑰指數(shù)dd是e關(guān)于φ(n)的模逆元。即滿足(d * e) % φ(n) 1。這個(gè)d就是私鑰的核心部分必須絕對(duì)保密。至此我們得到了公鑰(n, e)和私鑰(n, d)。在Java中RSAPublicKey和RSAPrivateKey對(duì)象內(nèi)部就封裝了這些值。2.3 加密與解密運(yùn)算加密公鑰操作對(duì)于明文消息M需要先轉(zhuǎn)換為一個(gè)小于n的整數(shù)計(jì)算密文C M^e mod n。解密私鑰操作對(duì)于密文C計(jì)算明文M C^d mod n。這里的“mod n”就是模運(yùn)算保證了結(jié)果始終在0到n-1的范圍內(nèi)。這個(gè)運(yùn)算過程是單向的知道公鑰(n, e)和密文C想反推出明文M在數(shù)學(xué)上等價(jià)于大數(shù)分解難題。注意這里引出了一個(gè)至關(guān)重要的限制RSA算法本身無填充一次能加密的數(shù)據(jù)塊大小必須小于密鑰模數(shù)n的字節(jié)長(zhǎng)度。對(duì)于一個(gè)2048位的密鑰n是2048位即256字節(jié)。但由于填充如PKCS1Padding需要占用一部分字節(jié)實(shí)際能加密的明文數(shù)據(jù)長(zhǎng)度更短。這是很多新手直接加密長(zhǎng)字符串或文件時(shí)拋出IllegalBlockSizeException的根源。解決這個(gè)限制的方案我們會(huì)在后面詳細(xì)討論。3. Java中的RSA實(shí)現(xiàn)從密鑰對(duì)生成到加解密理解了原理我們進(jìn)入實(shí)戰(zhàn)環(huán)節(jié)。Java標(biāo)準(zhǔn)庫(kù)javax.crypto提供了完善的RSA支持我們一步步來構(gòu)建。3.1 生成RSA密鑰對(duì)生成密鑰對(duì)是第一步。你需要決定密鑰長(zhǎng)度。目前1024位已被認(rèn)為不夠安全主流應(yīng)用至少使用2048位對(duì)安全性要求極高的場(chǎng)景建議使用4096位。但請(qǐng)注意密鑰長(zhǎng)度翻倍加解密運(yùn)算耗時(shí)將顯著增加。import java.security.KeyPair; import java.security.KeyPairGenerator; import java.security.NoSuchAlgorithmException; public class RSAKeyGenerator { public static KeyPair generateKeyPair(int keySize) throws NoSuchAlgorithmException { // 1. 獲取RSA密鑰對(duì)生成器實(shí)例 KeyPairGenerator keyPairGen KeyPairGenerator.getInstance(RSA); // 2. 初始化密鑰生成器指定密鑰長(zhǎng)度 keyPairGen.initialize(keySize); // 3. 生成密鑰對(duì) return keyPairGen.generateKeyPair(); } public static void main(String[] args) throws Exception { KeyPair keyPair generateKeyPair(2048); System.out.println(公鑰: keyPair.getPublic()); System.out.println(私鑰: keyPair.getPrivate()); // 通常我們需要將密鑰以特定格式如PEM保存或傳輸 // 這涉及到編碼后面會(huì)講 } }實(shí)操心得在服務(wù)器端生成密鑰對(duì)時(shí)務(wù)必確保有足夠的熵隨機(jī)性來源。在Linux服務(wù)器上/dev/random和/dev/urandom是常見的熵源。對(duì)于高并發(fā)生成密鑰的場(chǎng)景如果系統(tǒng)熵池不足generateKeyPair可能會(huì)阻塞。一個(gè)變通方案是使用SecureRandom并指定一個(gè)偽隨機(jī)數(shù)生成器PRNG算法但這需要仔細(xì)評(píng)估安全性。3.2 密鑰的保存與加載PEM格式與Base64編碼內(nèi)存中的密鑰對(duì)象不能直接保存到文件或通過網(wǎng)絡(luò)傳輸。我們需要將它們編碼為字節(jié)數(shù)組通常再轉(zhuǎn)換為Base64字符串并以特定的格式封裝最常見的就是PEM格式。PEM格式通常以-----BEGIN XXX-----和-----END XXX-----包裹Base64編碼的密鑰數(shù)據(jù)。Java標(biāo)準(zhǔn)庫(kù)沒有直接提供PEM解析功能我們通常需要借助Bouncy Castle庫(kù)或者自己處理Base64部分。使用純Java處理PKCS#8格式的私鑰和X.509格式的公鑰import java.security.KeyFactory; import java.security.PrivateKey; import java.security.PublicKey; import java.security.spec.PKCS8EncodedKeySpec; import java.security.spec.X509EncodedKeySpec; import java.util.Base64; public class RSAKeyUtils { // 將公鑰對(duì)象轉(zhuǎn)換為Base64字符串X.509格式 public static String publicKeyToBase64(PublicKey publicKey) { byte[] encoded publicKey.getEncoded(); // 默認(rèn)是X.509格式 return Base64.getEncoder().encodeToString(encoded); } // 將私鑰對(duì)象轉(zhuǎn)換為Base64字符串PKCS#8格式 public static String privateKeyToBase64(PrivateKey privateKey) { byte[] encoded privateKey.getEncoded(); // 默認(rèn)是PKCS#8格式 return Base64.getEncoder().encodeToString(encoded); } // 從Base64字符串加載公鑰 public static PublicKey loadPublicKeyFromBase64(String base64PublicKey) throws Exception { byte[] decoded Base64.getDecoder().decode(base64PublicKey); X509EncodedKeySpec keySpec new X509EncodedKeySpec(decoded); KeyFactory keyFactory KeyFactory.getInstance(RSA); return keyFactory.generatePublic(keySpec); } // 從Base64字符串加載私鑰 public static PrivateKey loadPrivateKeyFromBase64(String base64PrivateKey) throws Exception { byte[] decoded Base64.getDecoder().decode(base64PrivateKey); PKCS8EncodedKeySpec keySpec new PKCS8EncodedKeySpec(decoded); KeyFactory keyFactory KeyFactory.getInstance(RSA); return keyFactory.generatePrivate(keySpec); } }這樣你就可以將publicKeyToBase64得到的字符串加上-----BEGIN PUBLIC KEY-----和-----END PUBLIC KEY-----頭尾保存為PEM文件。私鑰同理。加載時(shí)先讀取PEM文件去掉頭尾行和換行符得到純Base64字符串再調(diào)用loadPrivateKeyFromBase64。踩坑記錄“RSA Public Key Not Find”這類錯(cuò)誤十有八九發(fā)生在密鑰加載環(huán)節(jié)。可能的原因有1PEM文件的頭尾標(biāo)識(shí)不正確2Base64字符串中包含多余的空格或換行符3嘗試用加載公鑰的方法去加載私鑰或者反之4密鑰格式不匹配比如提供了PKCS#1格式的私鑰但Java默認(rèn)期望PKCS#8。務(wù)必仔細(xì)檢查你的密鑰字符串和加載代碼。3.3 核心加解密與簽名驗(yàn)簽實(shí)現(xiàn)有了密鑰我們就可以進(jìn)行加解密和簽名驗(yàn)簽了。這里必須引入一個(gè)關(guān)鍵概念填充模式Padding。原始的RSA運(yùn)算教科書式RSA是不安全的必須與填充方案結(jié)合使用。常見的填充方案PKCS1Padding最常用的填充方案之一。在加密前會(huì)對(duì)明文進(jìn)行特定格式的填充增加了安全性。但注意它本身不具有抵抗選擇密文攻擊的特性。OAEPPadding例如RSA/ECB/OAEPWithSHA-256AndMGF1Padding這是比PKCS#1 v1.5更安全、更現(xiàn)代的填充方案推薦在新項(xiàng)目中使用。它提供了更強(qiáng)的安全性證明。import javax.crypto.Cipher; import java.security.*; public class RSACrypto { private static final String TRANSFORMATION RSA/ECB/OAEPWithSHA-256AndMGF1Padding; // 推薦使用OAEP /** * 公鑰加密 */ public static byte[] encrypt(byte[] data, PublicKey publicKey) throws Exception { Cipher cipher Cipher.getInstance(TRANSFORMATION); cipher.init(Cipher.ENCRYPT_MODE, publicKey); return cipher.doFinal(data); } /** * 私鑰解密 */ public static byte[] decrypt(byte[] encryptedData, PrivateKey privateKey) throws Exception { Cipher cipher Cipher.getInstance(TRANSFORMATION); cipher.init(Cipher.DECRYPT_MODE, privateKey); return cipher.doFinal(encryptedData); } /** * 私鑰簽名使用SHA256withRSA */ public static byte[] sign(byte[] data, PrivateKey privateKey) throws Exception { Signature signature Signature.getInstance(SHA256withRSA); signature.initSign(privateKey); signature.update(data); return signature.sign(); } /** * 公鑰驗(yàn)簽 */ public static boolean verify(byte[] data, byte[] signatureBytes, PublicKey publicKey) throws Exception { Signature signature Signature.getInstance(SHA256withRSA); signature.initVerify(publicKey); signature.update(data); return signature.verify(signatureBytes); } }關(guān)鍵點(diǎn)解析Cipher.getInstance(“RSA/ECB/OAEPWithSHA-256AndMGF1Padding”)這里ECB是分組密碼模式但對(duì)于RSA這種非對(duì)稱算法ECB是唯一有效的選項(xiàng)可以忽略。重點(diǎn)是OAEPWithSHA-256AndMGF1Padding它指定了填充方案和內(nèi)部使用的哈希算法。數(shù)據(jù)長(zhǎng)度限制即使使用填充RSA一次能加密的數(shù)據(jù)長(zhǎng)度仍然有限。對(duì)于2048位密鑰和OAEPWithSHA-256填充最大明文長(zhǎng)度大約在~190字節(jié)左右具體值取決于哈希算法和參數(shù)。這是硬性限制。4. 突破長(zhǎng)度限制混合加密與分段處理方案這是RSA實(shí)戰(zhàn)中最常遇到的問題。你需要加密一個(gè)幾百KB的配置文件或者一個(gè)用戶上傳的文檔直接調(diào)用上面的encrypt方法肯定會(huì)拋出IllegalBlockSizeException。怎么辦有兩種主流方案。4.1 方案一RSAAES混合加密推薦這是最標(biāo)準(zhǔn)、最高效的解決方案。思路是利用RSA加密傳輸對(duì)稱密鑰再用對(duì)稱密鑰如AES加密實(shí)際的大數(shù)據(jù)。發(fā)送方生成一個(gè)隨機(jī)的AES密鑰例如256位。使用接收方的RSA公鑰加密這個(gè)AES密鑰。使用這個(gè)AES密鑰以合適的模式如GCM加密原始數(shù)據(jù)。將加密后的AES密鑰和加密后的數(shù)據(jù)一起發(fā)送給接收方。接收方用自己的RSA私鑰解密出AES密鑰再用AES密鑰解密數(shù)據(jù)。這種方式結(jié)合了非對(duì)稱加密的安全密鑰交換和對(duì)稱加密的高效性是SSL/TLS等協(xié)議的核心思想。import javax.crypto.KeyGenerator; import javax.crypto.SecretKey; import javax.crypto.spec.GCMParameterSpec; import java.security.SecureRandom; public class HybridEncryption { public static EncryptionResult hybridEncrypt(byte[] data, PublicKey rsaPublicKey) throws Exception { // 1. 生成隨機(jī)的AES密鑰 KeyGenerator keyGen KeyGenerator.getInstance(AES); keyGen.init(256); // AES-256 SecretKey aesKey keyGen.generateKey(); // 2. 用RSA公鑰加密AES密鑰 byte[] encryptedAesKey RSACrypto.encrypt(aesKey.getEncoded(), rsaPublicKey); // 3. 用AES-GCM加密數(shù)據(jù) Cipher aesCipher Cipher.getInstance(AES/GCM/NoPadding); byte[] iv new byte[12]; // GCM推薦12字節(jié)IV new SecureRandom().nextBytes(iv); GCMParameterSpec spec new GCMParameterSpec(128, iv); // 128位認(rèn)證標(biāo)簽 aesCipher.init(Cipher.ENCRYPT_MODE, aesKey, spec); byte[] encryptedData aesCipher.doFinal(data); byte[] authenticationTag aesCipher.getIV(); // 注意GCM模式下認(rèn)證標(biāo)簽包含在doFinal結(jié)果中通常需要單獨(dú)處理IV // 4. 返回結(jié)果包含加密的AES密鑰、IV和加密數(shù)據(jù) return new EncryptionResult(encryptedAesKey, iv, encryptedData); } // 解密過程與之對(duì)稱略 static class EncryptionResult { byte[] encryptedAesKey; byte[] iv; byte[] encryptedData; // ... 構(gòu)造方法和getter } }4.2 方案二RSA分段加密與解密在某些無法使用混合加密的特定場(chǎng)景比如你只能使用RSA可以對(duì)數(shù)據(jù)進(jìn)行分段加密。但這通常不是好主意因?yàn)樗实拖虑倚枰⌒奶幚硖畛浜蛪K順序。基本思路將原始數(shù)據(jù)按(密鑰長(zhǎng)度/8 - 填充開銷)的大小分塊。對(duì)每一塊數(shù)據(jù)分別用RSA公鑰加密。將所有加密后的塊按順序拼接。解密時(shí)按(密鑰長(zhǎng)度/8)的大小分塊再分別解密。重要警告分段加密破壞了加密算法的語(yǔ)義安全性且實(shí)現(xiàn)復(fù)雜容易出錯(cuò)。除非有非常強(qiáng)的約束否則強(qiáng)烈推薦使用方案一的混合加密。5. 實(shí)戰(zhàn)中的典型問題排查與性能優(yōu)化即使代碼寫對(duì)了在集成和運(yùn)行時(shí)還是會(huì)遇到各種問題。這里記錄幾個(gè)我踩過的坑和對(duì)應(yīng)的解決方案。5.1 常見異常與排查表異常信息可能原因排查步驟與解決方案javax.crypto.IllegalBlockSizeException: Data must not be longer than XXX bytes嘗試加密的數(shù)據(jù)長(zhǎng)度超過了當(dāng)前密鑰和填充模式允許的最大長(zhǎng)度。1. 確認(rèn)數(shù)據(jù)長(zhǎng)度。2. 改用混合加密方案。3. 如果必須用RSA檢查并實(shí)施正確的分段邏輯。java.security.InvalidKeyException: RSA Public Key not find或InvalidKeySpecException1. 密鑰字符串格式錯(cuò)誤頭尾標(biāo)識(shí)、空格、換行。2. 密鑰類型不匹配用公鑰加載方法加載私鑰。3. 密鑰編碼格式不匹配如PEM解析錯(cuò)誤。1. 打印或日志輸出你準(zhǔn)備加載的Base64字符串檢查其完整性。2. 確認(rèn)你使用的是正確的加載方法X509EncodedKeySpec對(duì)應(yīng)公鑰PKCS8EncodedKeySpec對(duì)應(yīng)私鑰。3. 使用在線工具或openssl命令驗(yàn)證你的PEM文件是否正確。java.security.SignatureException: Signature length not correct簽名數(shù)據(jù)被篡改或驗(yàn)簽時(shí)使用的公鑰與簽名的私鑰不配對(duì)。1. 檢查數(shù)據(jù)傳輸過程是否完整。2. 確認(rèn)驗(yàn)簽方使用的公鑰確實(shí)來自簽名方的私鑰對(duì)。加解密或簽名速度極慢使用了過長(zhǎng)的RSA密鑰如4096位或在高頻循環(huán)中重復(fù)初始化Cipher和Signature對(duì)象。1. 評(píng)估安全需求是否可用2048位替代4096位。2.將Cipher和Signature對(duì)象緩存起來復(fù)用。它們的初始化init開銷很大。5.2 性能優(yōu)化要點(diǎn)緩存Cipher和Signature對(duì)象這是最重要的優(yōu)化點(diǎn)。Cipher.getInstance()和Signature.getInstance()特別是隨后的init()方法開銷很大。對(duì)于頻繁進(jìn)行加解密或簽名驗(yàn)簽的服務(wù)應(yīng)該使用ThreadLocal或?qū)ο蟪貋砭彺嬉殉跏蓟膶?shí)例。private static final ThreadLocalCipher cipherThreadLocal ThreadLocal.withInitial(() - { try { return Cipher.getInstance(“RSA/ECB/OAEPWithSHA-256AndMGF1Padding”); } catch (Exception e) { throw new RuntimeException(e); } }); // 使用時(shí)獲取避免重復(fù)初始化 Cipher cipher cipherThreadLocal.get(); cipher.init(Cipher.ENCRYPT_MODE, publicKey);區(qū)分讀寫操作使用不同密鑰對(duì)于高并發(fā)系統(tǒng)可以考慮使用多對(duì)密鑰。例如用一對(duì)密鑰專門處理簽名另一對(duì)處理加密減少單對(duì)密鑰的競(jìng)爭(zhēng)?？紤]使用硬件安全模塊HSM對(duì)于最高安全等級(jí)的場(chǎng)景密鑰的生命周期管理生成、存儲(chǔ)、使用、銷毀應(yīng)交給HSMJava代碼通過PKCS#11接口調(diào)用私鑰永不離開硬件設(shè)備。5.3 密鑰管理的最佳實(shí)踐私鑰永不落地理想情況下私鑰應(yīng)該存儲(chǔ)在受保護(hù)的硬件HSM、TEE或經(jīng)過強(qiáng)加密的密鑰管理服務(wù)KMS中。絕對(duì)不要將私鑰硬編碼在源代碼或配置文件里然后提交到代碼倉(cāng)庫(kù)。使用密鑰版本化為公鑰設(shè)置一個(gè)Key ID。當(dāng)需要輪換密鑰時(shí)生成新的一對(duì)密鑰并將新公鑰與一個(gè)新的Key ID一起發(fā)布。這樣舊密鑰在過渡期后可以安全廢棄。定期輪換密鑰即使沒有泄露跡象也應(yīng)制定策略定期更換密鑰以限制單個(gè)密鑰泄露可能造成的損失范圍。6. 在典型場(chǎng)景下的應(yīng)用架構(gòu)示例最后我們看兩個(gè)RSA在Java項(xiàng)目中的典型應(yīng)用場(chǎng)景把上面的知識(shí)點(diǎn)串聯(lián)起來。6.1 場(chǎng)景一API接口的簽名驗(yàn)簽為了保證API請(qǐng)求的完整性和不可抵賴性常用RSA簽名。假設(shè)客戶端調(diào)用服務(wù)端的某個(gè)接口。流程服務(wù)端生成RSA密鑰對(duì)私鑰妥善保存如放在配置中心或KMS公鑰下發(fā)給所有客戶端可集成在SDK中或通過固定接口獲取?？蛻舳嗽诎l(fā)起請(qǐng)求前構(gòu)造請(qǐng)求參數(shù)如按字典序排序后拼接成字符串使用自己的私鑰對(duì)該參數(shù)字符串進(jìn)行簽名如SHA256withRSA得到簽名串?？蛻舳藢⒑灻妥陨淼腒ey ID標(biāo)識(shí)使用的是哪對(duì)密鑰放在HTTP請(qǐng)求頭如X-Signature中。服務(wù)端收到請(qǐng)求后根據(jù)Key ID找到對(duì)應(yīng)的客戶端公鑰。服務(wù)端用同樣的規(guī)則構(gòu)造參數(shù)字符串使用客戶端公鑰對(duì)簽名進(jìn)行驗(yàn)簽。驗(yàn)簽通過則處理請(qǐng)求否則返回401錯(cuò)誤。這種方式確保了請(qǐng)求在傳輸過程中未被篡改并且確實(shí)來自持有對(duì)應(yīng)私鑰的客戶端。6.2 場(chǎng)景二敏感數(shù)據(jù)的安全傳輸用戶在前端需要提交密碼等敏感信息到后端。流程混合加密后端提供一個(gè)接口返回一個(gè)臨時(shí)生成的RSA公鑰可設(shè)置較短有效期和一個(gè)本次會(huì)話的sessionId。前端隨機(jī)生成一個(gè)AES密鑰如256位。前端使用后端返回的RSA公鑰加密這個(gè)AES密鑰得到encryptedAesKey。前端使用AES密鑰加密用戶的敏感數(shù)據(jù)如密碼得到encryptedData。同時(shí)生成一個(gè)隨機(jī)IV。前端將sessionId、encryptedAesKey、IV和encryptedData一起發(fā)送給后端。后端根據(jù)sessionId找到對(duì)應(yīng)的RSA私鑰臨時(shí)密鑰對(duì)可在內(nèi)存中緩存解密出AES密鑰再用AES密鑰和IV解密出原始敏感數(shù)據(jù)。這種方式既保證了傳輸安全RSA保護(hù)了AES密鑰又保證了加密性能AES加密實(shí)際數(shù)據(jù)是HTTPS之外應(yīng)用層加密的常見模式。實(shí)現(xiàn)RSA加密從調(diào)用幾行API到構(gòu)建一個(gè)健壯、安全、高效的應(yīng)用模塊中間隔著對(duì)原理的深刻理解和對(duì)細(xì)節(jié)的反復(fù)打磨。希望這篇從數(shù)學(xué)原理到Java代碼從密鑰管理到異常排查的長(zhǎng)文能幫你建立起關(guān)于RSA的完整知識(shí)圖譜。在實(shí)際編碼時(shí)多寫測(cè)試用例特別是邊界情況超長(zhǎng)數(shù)據(jù)、錯(cuò)誤密鑰、異常格式的測(cè)試才能真正做到心中有數(shù)上線不慌。安全無小事每一個(gè)細(xì)節(jié)都值得仔細(xì)推敲。