On Mon, 24 May 2021 22:36:49 GMT, Anthony Scarpino <ascarp...@openjdk.org> wrote:
>> test/jdk/com/sun/crypto/provider/Cipher/AEAD/GCMShortBuffer.java line 34: >> >>> 32: /* >>> 33: * @test >>> 34: * @summary Call decrypt doFinal() with different output values to see >>> if the >> >> Missing bug id? > > Here is my logic > It's not a regression test to verify a specific bug id, it's just a general > functionality test. Therefore the bug id does not point to a previous > failure. Hmm, alright. >> test/jdk/com/sun/crypto/provider/Cipher/AES/TestAESCipher.java line 90: >> >>> 88: i++; >>> 89: } >>> 90: return b; >> >> The generated data seems too similar, all starts with 0 and increment. Maybe >> use i = len to start with? Or take some additional argument for starting >> value? > > I wanted consistent data because it's harder to solve crypto failures when > you cannot see consistent pattern in the data. For example, the GCM case > where the ciphertext is correct, but the tag is wrong. It is easier to know > that the problem is in GHASH and not GCTR. > I don't see any negatives to having similar data. Might as well just hardcode the data then. Saves time to re-generate the similar bytes over and over. Not seeing much benefit of this method. Not a big deal if you intentionally use similar data. ------------- PR: https://git.openjdk.java.net/jdk/pull/4072
