我正在使用java.security.SecureRandomangorithm"SHA1PRNG"來生成加密密鑰。這是用于加密次要數據的歷史代碼。然而，當我們從java8切換到java11時，我們的代碼停止工作。這是重現這種情況的測試用例：@Testvoid srEncryptionSeedTest() throws NoSuchAlgorithmException{ final long versionSalt = 1850498708034063014L; final long customSalt = -919666267416765972L; final SecureRandom sr = SecureRandom.getInstance("SHA1PRNG"); sr.setSeed(versionSalt); final long l1 = sr.nextLong(); final long l2 = sr.nextLong(); sr.setSeed(customSalt); final long k1 = sr.nextLong(); final long k2 = sr.nextLong(); // check l1 and l2 Assert.assertEquals(l1, 6338935000439666355L); Assert.assertEquals(l2, -7355545655857008441L); // Seeding // check k1 and k2 Assert.assertEquals(k1, -2226559466996804670L); // Assert.assertEquals(k2, -3123855249705841778L);}這在 java11 上工作正常，但在 java8 上我們有k1=-4273821888324981770and k2=3053251164341917236，所以測試失敗。如您所見，在生成相同數量的相同隨機數后設置完全相同的種子后測試開始失敗，所以我懷疑 RNG 的狀態不同，但調試對我沒有幫助（我不明白為什么這不一樣）。這可以很容易地在任何操作系統上重現。關于 Java8 JVM 的一些事實：java.vendor -> Oracle Corporation // same goes on OpenJDK buildsjava.version -> 1.8.0_202-ea // same goes on 1.8.0_181java.vm.info -> mixed modejava.specification.version -> 1.8java.runtime.name -> Java(TM) SE Runtime Environment關于 Java11 JVM 的一些事實：java.vendor -> AdoptOpenJDKjava.version -> 11.0.3java.vm.info -> mixed modejava.specification.version -> 11java.runtime.name -> OpenJDK Runtime Environment任何幫助將不勝感激。
1 回答
嗶嗶one
TA貢獻1854條經驗 獲得超8個贊
[免責聲明]：?不要這樣做（除非你想要向后兼容）。如果你想要可預測性，你應該基于可靠的 RNG 實施你的解決方案，我也是。但不幸的是我們必須支持舊文件版本的格式，而且這些文件不包含任何敏感或個人數據，但我們不希望用戶更改此數據，因為它以類似文本的格式存儲，因此很容易被更改。
我沒有實現自己的“SHA1PRNG”，因為它太難了（在評論中提到）。相反，我破解了較新的 PRNG 版本，使其與舊版本完全一樣。原因是因為 java9 OpenJDK 的創建者決定在每次調用setSeed()secureRandomSpi時使新版本重置整數字段的值，而舊版本則沒有。remCountSecureRandom.，然后通過反射獲取它的SPI并保存它的remCount字段值。然后您可以打電話setSeed()，然后將保存的值安裝回現場remCount。我不想在這里發布這段晦澀難懂的代碼，但你已經明白了。謝謝。
添加回答
舉報
0/150
提交
取消