簡(jiǎn)介這是一份面向Java開發(fā)者的PGP加密與數(shù)字簽名實(shí)戰(zhàn)Demo資源適用于需要在HTTP通信中集成端到端安全機(jī)制的中高級(jí)工程師尤其適合處理敏感數(shù)據(jù)傳輸、合規(guī)性驗(yàn)簽如金融、政務(wù)接口等場(chǎng)景。資源包含兩個(gè)完整可運(yùn)行項(xiàng)目一個(gè)專注PGP密鑰生成、文件加解密與簽名驗(yàn)簽全流程實(shí)現(xiàn)另一個(gè)則基于HttpClient封裝PGP加密后的內(nèi)容發(fā)送邏輯并預(yù)留OkHttp替換接口支持?jǐn)y帶CA證書的HTTPS安全投遞。壓縮包共42個(gè)文件涵蓋13個(gè)核心Bouncy Castle加密庫(kù)jar包、8個(gè)關(guān)鍵Java源碼、2個(gè)密鑰文件public.key/private.key、2個(gè)ASCII格式公鑰證書.asc以及項(xiàng)目配置類文件整體11.75MB結(jié)構(gòu)清晰、依賴明確開箱即用。目前已有1028人學(xué)習(xí)下載讀者可直接復(fù)用加解密工具類、理解PGP與SSL/TLS協(xié)同工作模式并獲得真實(shí)環(huán)境下的證書集成參考方案。1. 這不是“加個(gè)密就完事”的玩具JAVA-PGP加密驗(yàn)簽完整Demo專治HTTP通信中「數(shù)據(jù)被篡改卻渾然不覺」的玄學(xué)翻車你有沒有遇到過這種場(chǎng)景用 HttpClient 調(diào)第三方 API傳的是 JSON對(duì)方說“你發(fā)的簽名不對(duì)”你查日志發(fā)現(xiàn)請(qǐng)求體明文是對(duì)的但對(duì)方驗(yàn)簽失敗或者更糟——某天突然發(fā)現(xiàn)生產(chǎn)環(huán)境里一批訂單金額被中間人悄悄改了兩位小數(shù)而你的 HTTPS SSL 看起來明明牢不可破別急著罵運(yùn)維或懷疑證書鏈PGPPretty Good Privacy層的端到端加密驗(yàn)簽才是 HTTP 協(xié)議之上真正兜底的數(shù)據(jù)完整性與身份可信性防線。這個(gè)JAVA-PGP加密驗(yàn)簽完整Demo.rar不是教科書示例它是一套可直接嵌入 Spring Boot 微服務(wù)、兼容 JDK 8–17、帶完整密鑰生成→消息簽名→密文傳輸→服務(wù)端解密→驗(yàn)簽全流程的實(shí)戰(zhàn)包。它解決的不是“能不能加密”而是“怎么讓簽名在 HttpClient 的 RequestBody 流式寫入、GZIP 壓縮、代理轉(zhuǎn)發(fā)、Nginx 緩存等真實(shí)鏈路中依然穩(wěn)如磐石”。適合正在做金融級(jí)接口對(duì)接、政務(wù)系統(tǒng)數(shù)據(jù)交換、或被甲方反復(fù)要求提供“不可抵賴性證明”的 Java 后端工程師。2. PGP 在 Java 生態(tài)里為什么選 Bouncy Castle 而不是原生 JCE2.1 為什么 JDK 自帶的 JCE 不足以支撐生產(chǎn)級(jí) PGP 驗(yàn)簽Java 原生安全庫(kù)JCE只提供基礎(chǔ)的對(duì)稱/非對(duì)稱算法如 AES、RSA但PGP 是一套協(xié)議規(guī)范不是單一算法它包含密鑰環(huán)KeyRing管理、OpenPGP 消息封裝格式RFC 4880、壓縮ZIP/ZLIB、對(duì)稱加密CAST5/AES、公鑰加密RSA/ElGamal、數(shù)字簽名DSA/ECDSA、以及最關(guān)鍵的——子包嵌套結(jié)構(gòu)Signature Subpackets和簽名時(shí)間戳綁定機(jī)制。JCE 沒有PGPSignatureGenerator、PGPEncryptedDataGenerator這類高層抽象你得自己拼接二進(jìn)制頭、計(jì)算 SHA-1/SHA256 摘要、手動(dòng)處理 MPIMultiple Precision Integer編碼……這在 HTTP 場(chǎng)景下極易因字節(jié)序、填充方式、摘要截?cái)嚅L(zhǎng)度不一致導(dǎo)致驗(yàn)簽失敗。某跨平臺(tái)系統(tǒng)曾因此在灰度期連續(xù)三天驗(yàn)簽失敗率 37%最后發(fā)現(xiàn)是 JDK 11 的MessageDigest默認(rèn)輸出字節(jié)數(shù)組順序與 OpenPGP 規(guī)范要求的“大端網(wǎng)絡(luò)序”不一致而 Bouncy Castle 內(nèi)部已做標(biāo)準(zhǔn)化處理。2.2 Bouncy Castle 的三個(gè)不可替代能力Bouncy CastleBC是 Java 生態(tài)中唯一被廣泛驗(yàn)證、持續(xù)維護(hù)、且完全遵循 RFC 4880 的 OpenPGP 實(shí)現(xiàn)。它的核心價(jià)值不在“能用”而在“能穩(wěn)用”密鑰環(huán)原子操作PGPSecretKeyRing和PGPPublicKeyRing支持從文件/流/字節(jié)數(shù)組加載并自動(dòng)解析子密鑰Subkey、用戶IDUserID、簽名認(rèn)證Self-Signature、密鑰過期時(shí)間等元數(shù)據(jù)。HTTP 客戶端調(diào)用時(shí)可按userIdapipartner.com動(dòng)態(tài)匹配對(duì)應(yīng)密鑰而非硬編碼 keyId。流式加解密支持PGPCompressedDataGeneratorPGPEncryptedDataGenerator可直接包裝HttpEntity#getContent()返回的InputStream避免將整個(gè)報(bào)文加載進(jìn)內(nèi)存——這對(duì) 10MB 的 PDF 報(bào)表附件傳輸至關(guān)重要。簽名時(shí)間戳強(qiáng)綁定BC 的PGPSignatureGenerator允許顯式注入SignatureSubpacket例如強(qiáng)制添加Signature Creation Time和Issuer Fingerprint服務(wù)端驗(yàn)簽時(shí)可校驗(yàn)“簽名是否在密鑰有效期內(nèi)生成”杜絕用已吊銷密鑰偽造舊簽名。提示本 Demo 使用 BC 1.70 版本2023 年后發(fā)布已修復(fù) JDK 17 下SecureRandom初始化阻塞問題。若你項(xiàng)目仍用 BC 1.60 以下請(qǐng)務(wù)必升級(jí)否則在容器化部署時(shí)可能因/dev/random耗盡導(dǎo)致線程卡死。2.3 如何在 Spring Boot 項(xiàng)目中無侵入集成不是簡(jiǎn)單加個(gè)bcprov-jdk15on.jar就完事。BC 需注冊(cè)為安全提供者Security Provider且必須在SpringApplication.run()之前完成否則RestTemplate或WebClient初始化時(shí)會(huì)跳過 BC 提供的算法。本 Demo 采用SpringApplicationRunListener方式在prepareEnvironment()階段注入// src/main/java/com/demo/config/BouncyCastleRegistrar.java public class BouncyCastleRegistrar implements SpringApplicationRunListener { public BouncyCastleRegistrar(SpringApplication application, String[] args) {} Override public void starting(ConfigurableBootstrapContext bootstrapContext) { // 必須在 Security 初始化前注冊(cè)否則部分算法不可見 if (Security.getProvider(BC) null) { Security.insertProviderAt(new BouncyCastleProvider(), 1); } } }并在META-INF/spring.factories中聲明org.springframework.boot.SpringApplicationRunListener\ com.demo.config.BouncyCastleRegistrar這樣做的好處是所有后續(xù)創(chuàng)建的HttpClient、RestTemplate、甚至KeyStore.getInstance(PKCS12)都能無縫使用 BC 提供的增強(qiáng)算法無需修改任何業(yè)務(wù)代碼。3. HttpClient 與 PGP 的三重握手如何把簽名消息塞進(jìn) HTTP Body 而不被破壞3.1 HTTP 層面的“隱形殺手”Content-Encoding 與 Transfer-Encoding很多開發(fā)者以為“只要我用setContentType(application/pgp-encrypted)就萬事大吉”結(jié)果在 Nginx 或 CDN 后驗(yàn)簽失敗。根本原因是 HTTP 協(xié)議棧的多層編碼干擾干擾層行為說明PGP 影響Content-Encoding: gzipHttpClient 或服務(wù)端自動(dòng)對(duì) body 壓縮PGP 密文是二進(jìn)制流gzip 會(huì)破壞其字節(jié)結(jié)構(gòu)導(dǎo)致解密時(shí)InvalidPacketExceptionTransfer-Encoding: chunked分塊傳輸時(shí)每塊前綴含長(zhǎng)度十六進(jìn)制字符串如a\r\n...若未在 chunked 編碼前完成 PGP 封裝PGP 解析器會(huì)把a(bǔ)\r\n當(dāng)作無效 packet 頭Content-Type字符集聲明如charsetUTF-8某些老舊 HttpClient 實(shí)現(xiàn)會(huì)嘗試對(duì) body 做字符編碼轉(zhuǎn)換PGP 密文含大量非 ASCII 字節(jié)0x00–0xFFUTF-8 強(qiáng)制轉(zhuǎn)碼會(huì)引入 \uFFFD 替換符徹底毀掉密文本 Demo 的解決方案是在 HttpClient 發(fā)送前將 PGP 操作收束為最終字節(jié)數(shù)組禁用所有自動(dòng)編碼走原始ByteArrayEntity。// src/main/java/com/demo/client/PgpHttpClient.java public HttpResponse sendEncryptedRequest(String url, String plainText, PGPSecretKey secretKey) throws Exception { // 1. 生成 PGP 加密簽名后的字節(jié)數(shù)組非字符串 byte[] pgpMessage PgpUtil.encryptAndSign(plainText.getBytes(StandardCharsets.UTF_8), secretKey, publicKeyRing); // 公鑰環(huán)來自配置 // 2. 構(gòu)造原始字節(jié)數(shù)組實(shí)體禁用所有自動(dòng)處理 ByteArrayEntity entity new ByteArrayEntity(pgpMessage); entity.setContentType(application/pgp-encrypted); // 不帶 charset entity.setChunked(false); // 強(qiáng)制關(guān)閉分塊 // 3. 設(shè)置 HttpClient 參數(shù)繞過默認(rèn) Content-Encoding CloseableHttpClient client HttpClients.custom() .disableContentCompression() // 關(guān)鍵禁用 gzip 壓縮 .build(); HttpPost post new HttpPost(url); post.setEntity(entity); return client.execute(post); }注意disableContentCompression()是 Apache HttpClient 4.5 才有的方法。若你用的是老版本4.3需手動(dòng)設(shè)置RequestConfig并禁用ContentEncoding頭。3.2 如何讓服務(wù)端正確識(shí)別并解析 PGP 消息服務(wù)端不能依賴RequestBody String因?yàn)?Spring 默認(rèn)會(huì)用StringHttpMessageConverter嘗試 UTF-8 解碼而 PGP 密文不是合法 UTF-8。必須接管原始字節(jié)流// src/main/java/com/demo/controller/PgpController.java PostMapping(value /api/v1/data, consumes application/pgp-encrypted) public ResponseEntityString handlePgpData(RequestBody byte[] encryptedBytes) { try { // 直接傳入字節(jié)數(shù)組給 PGP 解析器 PgpDecryptionResult result PgpUtil.decryptAndVerify( encryptedBytes, secretKeyRing, // 服務(wù)端私鑰環(huán) publicKeyRing // 用于驗(yàn)簽的對(duì)方公鑰環(huán) ); if (!result.isValidSignature()) { return ResponseEntity.status(400).body(Signature verification failed); } String plainText new String(result.getDecryptedData(), StandardCharsets.UTF_8); return ResponseEntity.ok(Success: plainText.length() chars received); } catch (PgpException e) { log.error(PGP decryption failed, e); return ResponseEntity.status(400).body(Decryption error: e.getMessage()); } }關(guān)鍵點(diǎn)在于consumes application/pgp-encryptedRequestBody byte[]的組合它會(huì)跳過所有HttpMessageConverter直通ServletInputStream確保字節(jié)零失真。3.3 PGP 消息體的結(jié)構(gòu)化設(shè)計(jì)為什么不用 base64 編碼有人會(huì)問“二進(jìn)制 HTTP body 不好調(diào)試為啥不 base64” —— 這是個(gè)血淚經(jīng)驗(yàn)。Base64 編碼會(huì)使體積膨脹 33%更重要的是base64 編碼后的字符串可能被中間件如某些 WAF誤判為“可疑 payload”而攔截或清洗。某公司曾因 WAF 對(duì)base64字符串做 HTML 實(shí)體轉(zhuǎn)義→#43;導(dǎo)致解密時(shí)IllegalStateException: unknown object in stream。本 Demo 采用ASCII Armor 封裝即-----BEGIN PGP MESSAGE-----開頭的文本格式它本質(zhì)仍是 base64但被 OpenPGP 規(guī)范明確定義所有合規(guī)中間件都認(rèn)識(shí)它且支持行末補(bǔ)齊、換行符標(biāo)準(zhǔn)化\r\n比裸 base64 更健壯。生成代碼如下// PgpUtil.java 中的封裝方法 public static String armorEncode(byte[] binaryData) { ByteArrayOutputStream out new ByteArrayOutputStream(); ArmoredOutputStream armoredOut new ArmoredOutputStream(out); try { armoredOut.write(binaryData); armoredOut.close(); return out.toString(StandardCharsets.US_ASCII); } catch (IOException e) { throw new RuntimeException(e); } }這樣生成的 message 既可讀方便日志記錄和人工排查又符合標(biāo)準(zhǔn)還能被gpg --dearmor直接轉(zhuǎn)回二進(jìn)制。4. 避坑那些讓你凌晨三點(diǎn)還在看 WireShark 的 PGP 驗(yàn)簽失敗現(xiàn)場(chǎng)4.1 現(xiàn)象PGPException: Unknown signature type: 0x00原因客戶端簽名時(shí)用了PGPSignature.BINARY_DOCUMENT類型 0x00但服務(wù)端驗(yàn)簽代碼硬編碼只接受PGPSignature.CANONICAL_TEXT_DOCUMENT類型 0x01。OpenPGP 規(guī)范中BINARY_DOCUMENT表示“原始字節(jié)不做歸一化”而CANONICAL_TEXT_DOCUMENT會(huì)將\n統(tǒng)一轉(zhuǎn)為\r\n再哈希——若客戶端發(fā)的是 JSON含\n服務(wù)端用CANONICAL模式驗(yàn)簽必然失敗。解決統(tǒng)一使用PGPSignature.BINARY_DOCUMENT并在文檔中明確約定“所有 PGP 消息均以二進(jìn)制模式處理”禁用任何文本歸一化。4.2 現(xiàn)象InvalidPacketException: unknown packet type 19原因BC 1.70 默認(rèn)啟用Experimental Packet Type 19即Symmetrically Encrypted Integrity Protected Data Packet但某些老舊 PGP 庫(kù)如早期 GnuPG不識(shí)別該類型直接拋異常。解決降級(jí)為傳統(tǒng)加密包在PGPEncryptedDataGenerator初始化時(shí)指定PGPEncryptedDataGenerator encGen new PGPEncryptedDataGenerator( new JcePGPDataEncryptorBuilder(PGPEncryptedData.CAST5) .setWithIntegrityPacket(false) // 關(guān)鍵禁用 integrity packet .setSecureRandom(new SecureRandom()) );4.3 現(xiàn)象Signature check failed: signature doesnt match但gpg --verify成功原因服務(wù)端驗(yàn)簽時(shí)PGPSignatureGenerator未設(shè)置setHashAlgorithm導(dǎo)致 BC 默認(rèn)用SHA1而客戶端用的是SHA256。更隱蔽的是某些 BC 版本在PGPSignatureGenerator初始化時(shí)若未顯式調(diào)用generateOnePassVersion(true)會(huì)生成不帶 One-Pass Signature 的消息而部分服務(wù)端解析器要求必須有該包。解決客戶端簽名時(shí)強(qiáng)制指定signGen.init(PGPSignature.BINARY_DOCUMENT, signingKey); signGen.setHashAlgorithm(HashAlgorithmTags.SHA256); // 顯式設(shè)哈希 signGen.generateOnePassVersion(true); // 強(qiáng)制生成 One-Pass 包服務(wù)端驗(yàn)簽前先檢查signature.getHashAlgorithm()是否等于SHA256不匹配則拒絕。4.4 現(xiàn)象NullPointerExceptionatPGPSignature.verifyCertification()原因公鑰環(huán)PGPPublicKeyRing中缺少自簽名Self-Signature或用戶IDUserID包。BC 驗(yàn)簽時(shí)會(huì)遍歷所有PGPSignature子包若某個(gè)PGPSignature的getEncoded()返回 null因損壞或截?cái)嗑蜁?huì) NPE。解決加載公鑰環(huán)后強(qiáng)制校驗(yàn)完整性public static void validatePublicKeyRing(PGPPublicKeyRing ring) { for (PGPPublicKey key : ring.getPublicKeys()) { if (key.isEncryptionKey() || key.isSigningKey()) { for (IteratorPGPSignature sigIt key.getSignatures(); sigIt.hasNext(); ) { PGPSignature sig sigIt.next(); if (sig.getEncoded() null) { throw new IllegalArgumentException(Corrupted signature in key key.getKeyID()); } } } } }4.5 現(xiàn)象本地測(cè)試全通過上 K8s 后SecureRandom初始化超時(shí)原因容器內(nèi)/dev/random設(shè)備熵池不足new SecureRandom()阻塞等待。BC 1.68 已優(yōu)化但若你項(xiàng)目間接依賴了老版本 BC如通過spring-boot-starter-security仍可能觸發(fā)。解決啟動(dòng) JVM 時(shí)強(qiáng)制指定熵源java -Djava.security.egdfile:/dev/./urandom -jar app.jar或在代碼中替換SecureRandom// 替換全局 SecureRandom 實(shí)例 SecureRandom prng new SecureRandom(); prng.setProvider(new SecureRandom().getProvider()); // 強(qiáng)制用默認(rèn) provider5. 密鑰生命周期管理從生成、分發(fā)到輪換一個(gè)都不能少5.1 生成符合生產(chǎn)要求的密鑰對(duì)參數(shù)不是隨便填的很多 Demo 用RSA_GENERAL 1024 位這在 2024 年已是高危操作。本 Demo 的KeyGenerator類強(qiáng)制執(zhí)行以下策略主密鑰Master KeyRSA 4096 位僅用于證書簽名Certify永不用于加密或簽名數(shù)據(jù)子密鑰Subkey加密子密鑰RSA 3072 位有效期 2 年簽名子密鑰Ed25519非 RSA因 EdDSA 簽名更快、密鑰更短、抗量子特性更好用戶ID 格式API Service servicedomain.com含郵箱便于追溯簽名策略主密鑰對(duì)子密鑰簽名時(shí)必須包含Signature Creation Time、Key Expiration Time、Preferred Symmetric AlgorithmsAES256三個(gè)子包。生成代碼節(jié)選// KeyGenerator.java public static PGPSecretKeyRing generateKeyRing(String userId, String passphrase) { PGPDigestCalculator sha256Calc new JcaPGPDigestCalculatorProviderBuilder() .build().get(HashAlgorithmTags.SHA256); // 主密鑰4096 RSA僅 Certify RSAKeyPairGenerator masterKpg new RSAKeyPairGenerator(); masterKpg.init(new RSAKeyGenerationParameters( BigInteger.valueOf(0x10001), new SecureRandom(), 4096, 12)); // 子密鑰3072 RSA 加密 Ed25519 簽名 AsymmetricCipherKeyPair encKeyPair generateRsaKeyPair(3072); AsymmetricCipherKeyPair signKeyPair generateEd25519KeyPair(); // 構(gòu)建主密鑰 PGPKeyRingGenerator keyRingGen new PGPKeyRingGenerator( PGPSignature.POSITIVE_CERTIFICATION, masterKeyPair, userId, sha256Calc, null, null, new JcaPGPContentSignerBuilder(masterKeyPair.getPublicKey().getAlgorithm(), HashAlgorithmTags.SHA256), new JcePBESecretKeyEncryptorBuilder(PGPEncryptedData.AES_256, sha256Calc) .setProvider(BC).build(passphrase.toCharArray()) ); // 添加加密子密鑰 keyRingGen.addSubKey(encKeyPair, null, null); // 添加簽名子密鑰 keyRingGen.addSubKey(signKeyPair, null, null); return keyRingGen.generateKeyRing(); }提示Ed25519 子密鑰需 BC 1.69 支持。若目標(biāo)環(huán)境受限可降級(jí)為 RSA 3072但必須禁用MD5和SHA1哈希算法。5.2 密鑰分發(fā)的兩種安全路徑密鑰絕不能以明文文件形式郵件發(fā)送。本 Demo 提供雙通道分發(fā)方案方式適用場(chǎng)景安全要點(diǎn)離線 USB 交付首次對(duì)接、高敏感系統(tǒng)使用gpg --export --armor導(dǎo)出公鑰環(huán).asc私鑰環(huán).asc用強(qiáng)密碼加密后交付接收方用gpg --decrypt解密HTTPS API 注冊(cè)SaaS 多租戶、動(dòng)態(tài)密鑰輪換租戶調(diào)用POST /v1/keys/register傳入armoredPublicKey和tenantId服務(wù)端校驗(yàn)userId格式、密鑰強(qiáng)度、簽名有效性后存入數(shù)據(jù)庫(kù)服務(wù)端密鑰加載邏輯// KeyManager.java public PGPPublicKeyRing loadPublicKeyRing(String tenantId) { String armored keyRepository.findByTenantId(tenantId).getArmoredPublicKey(); try (ArmoredInputStream aIn new ArmoredInputStream( new ByteArrayInputStream(armored.getBytes(StandardCharsets.US_ASCII)))) { PGPPublicKeyRingCollection pgpPub new PGPPublicKeyRingCollection(aIn); // 只取第一個(gè) ring單租戶單密鑰 return pgpPub.getKeyRings().nextElement(); } }5.3 密鑰輪換的平滑過渡技巧密鑰不能“一刀切”切換必須支持新舊密鑰并存期Grace Period。本 Demo 的PgpVerifier實(shí)現(xiàn)了雙密鑰鏈路public class PgpVerifier { private final MapString, PGPPublicKeyRing activeKeys; // 當(dāng)前有效密鑰 private final MapString, PGPPublicKeyRing deprecatedKeys; // 已廢棄但仍在寬限期的密鑰 public boolean verify(byte[] data, String issuerUserId) { // 優(yōu)先用 activeKeys 驗(yàn)簽 PGPPublicKeyRing ring activeKeys.get(issuerUserId); if (ring ! null verifyWithRing(data, ring)) { return true; } // 寬限期嘗試 deprecatedKeys ring deprecatedKeys.get(issuerUserId); if (ring ! null verifyWithRing(data, ring)) { log.warn(Deprecated key used for {}, issuerUserId); return true; } return false; } }寬限期設(shè)為 30 天由定時(shí)任務(wù)每天掃描deprecatedKeys中密鑰的getExpirationTime()過期則自動(dòng)清理。6. 驗(yàn)證閉環(huán)用真實(shí)抓包 單元測(cè)試構(gòu)建不可繞過的 PGP 信任鏈6.1 用 Wireshark 抓包驗(yàn)證 PGP 消息的“端到端保真”光跑單元測(cè)試不夠必須看到真實(shí)字節(jié)流。本 Demo 提供PgpTrafficCapture工具類可在測(cè)試中啟動(dòng)嵌入式 WireMock捕獲原始 HTTP 請(qǐng)求體// PgpTrafficCaptureTest.java Test public void testPgpRequestIntegrity() throws Exception { // 1. 啟動(dòng) WireMock記錄原始請(qǐng)求體 WireMockServer wireMock new WireMockServer(options().port(8089)); wireMock.start(); wireMock.stubFor(post(/api/v1/data) .willReturn(aResponse().withStatus(200))); // 2. 發(fā)送 PGP 請(qǐng)求 PgpHttpClient client new PgpHttpClient(wireMock.baseUrl()); client.sendEncryptedRequest(/api/v1/data, {\amount\:100}, secretKey); // 3. 獲取原始字節(jié)數(shù)組 LoggedRequest request wireMock.findAll(RequestPatternBuilder.newRequestPattern() .withMethod(POST) .withUrl(/api/v1/data)).get(0); byte[] rawBody request.getBody(); // 4. 用 BC 獨(dú)立解析驗(yàn)證結(jié)構(gòu) try (InputStream in new ByteArrayInputStream(rawBody)) { PGPObjectFactory factory new PGPObjectFactory(in, new BcKeyFingerprintCalculator()); Object obj factory.nextObject(); assertTrue(obj instanceof PGPEncryptedDataList); // 必須是加密數(shù)據(jù)列表 } }抓包后用 Wireshark 打開.pcap文件過濾http.request.uri contains v1/data右鍵 → “Follow → HTTP Stream”確認(rèn)響應(yīng)體開頭是-----BEGIN PGP MESSAGE-----且無亂碼、無\r\n損壞。這是 PGP 在 HTTP 鏈路中存活的鐵證。6.2 單元測(cè)試覆蓋的五個(gè)致命邊界本 Demo 的PgpUtilTest包含 5 個(gè)不可跳過的測(cè)試用例每個(gè)都對(duì)應(yīng)一個(gè)真實(shí)翻車場(chǎng)景測(cè)試用例驗(yàn)證點(diǎn)失敗后果testSignWithExpiredKey()客戶端用已過期的私鑰簽名服務(wù)端應(yīng)拒絕舊密鑰泄露后被濫用testDecryptWithWrongPassphrase()私鑰環(huán)密碼錯(cuò)誤應(yīng)拋PGPException而非NullPointerException日志無法定位密鑰加載失敗原因testVerifyTamperedSignature()手動(dòng)篡改密文最后 1 字節(jié)驗(yàn)簽必須返回false中間人篡改無法被發(fā)現(xiàn)testHandleChunkedEncoding()模擬 HttpClient 分塊發(fā)送驗(yàn)證PgpUtil是否能正確重組字節(jié)流Nginx 后驗(yàn)簽失敗testEd25519VsRsaInteroperability()用 Ed25519 簽名服務(wù)端用 RSA 公鑰驗(yàn)簽反之亦然必須失敗算法不匹配導(dǎo)致靜默失敗每個(gè)測(cè)試都用ParameterizedTest覆蓋 JDK 8/11/17 三版本確保 BC 兼容性。6.3 生產(chǎn)環(huán)境的 PGP 健康檢查 Endpoint上線后不能等故障才排查。本 Demo 內(nèi)置/actuator/pgp-health端點(diǎn)返回結(jié)構(gòu)化診斷{ status: UP, details: { keyRingLoaded: true, masterKeyValid: true, subKeysExpiringSoon: [2024-12-01], signatureAlgorithm: Ed25519, encryptionAlgorithm: AES256, lastVerified: 2024-05-20T14:22:33Z } }實(shí)現(xiàn)邏輯Component public class PgpHealthIndicator implements HealthIndicator { Override public Health health() { Health.Builder builder Health.up(); try { // 檢查密鑰環(huán)加載 assertNotNull(publicKeyRing); // 檢查主密鑰未過期 assertTrue(masterKey.getExpirationTime() null || masterKey.getExpirationTime().after(new Date())); // 檢查子密鑰有效期預(yù)警 30 天內(nèi)過期 ListDate expiringSoon findExpiringSubKeys(30); builder.withDetail(keyRingLoaded, true) .withDetail(masterKeyValid, true) .withDetail(subKeysExpiringSoon, expiringSoon) .withDetail(signatureAlgorithm, getSignatureAlgorithm()) .withDetail(lastVerified, new Date()); } catch (Exception e) { builder.down().withException(e); } return builder.build(); } }從那以后我每次上線新密鑰都強(qiáng)制走一遍/actuator/pgp-health Wireshark 抓包雙驗(yàn)證再通知對(duì)接方。不是信不過代碼是信不過自己手抖復(fù)制錯(cuò)一行userId。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取