Exposed SHA3 through EVP API - #485
Conversation
Pull request was converted to draft
Pull request was converted to draft
WillChilds-Klein
left a comment
There was a problem hiding this comment.
Looking good so far!
| addService("MessageDigest", "SHA3-224", "SHA3224Spi"); | ||
| addService("MessageDigest", "SHA3-256", "SHA3256Spi"); | ||
| addService("MessageDigest", "SHA3-384", "SHA3384Spi"); | ||
| addService("MessageDigest", "SHA3-512", "SHA3512Spi"); |
There was a problem hiding this comment.
note to reviewers -- i confirmed that these 4 service names align with JCA-standard names for SHA3
https://docs.oracle.com/en/java/javase/11/docs/specs/security/standard-names.html
There was a problem hiding this comment.
While I don't think anyone here (or anywhere) uses Eclipse anymore, I don't think this PR is the place to remove it.
| #include "generated-headers.h" | ||
| #include "util.h" | ||
|
|
||
|
|
There was a problem hiding this comment.
Style nit: Here and elsewhere in this file there is superfluous whitespace. Try to stick to just 1 newline, there's really no benefit for using more than that.
| // Transform DIGEST_NAME from "sha3_224" format to "SHA3224" format for JNI class names | ||
| // This macro needs to be defined for each digest algorithm |
There was a problem hiding this comment.
This seems like an anti-pattern for what should be a template. You're basically requiring that we make a change to the template each time you need some new algorithm. This should be pulled up.
| #define DIGEST_NAME sha3_224 | ||
| #define DIGEST_LENGTH 28 | ||
| #define DIGEST_BLOCK_SIZE 144 | ||
| #define MD_CTX_SIZE 400 |
There was a problem hiding this comment.
It would be good to define these constants somewhere, like a comment in the template.
Where did you get the DIGEST_BLOCK_SIZE values from?
MD_CTX_SIZE seems like it would be the same for all the hashes right? Maybe pull this down into the template layer. Better yet, replace it with a sizeof call on the actual type to avoid any drift between LC and this template..
| raii_env env(pEnv); | ||
|
|
||
| SecureBuffer<CTX,1> ctx; | ||
| const size_t scratchSize = DIGEST_BLOCK_SIZE; // Size is arbitrarily chosen |
| MessageDigest digest = getDigest(); | ||
|
|
||
| assertArrayEquals( | ||
| Hex.decodeHex(getTestVector().toCharArray()), digest.digest("testing".getBytes())); |
There was a problem hiding this comment.
This is an odd way to lay things out. We should factor out the pre-image "testing" similar to the "TestVector" otherwise, implementers of this class need to implicitly know that their pre-image must always be the String "testing".
| public void cavpShortVectors() throws Throwable { | ||
| try (final InputStream is = new GZIPInputStream(TestUtil.getTestData(getCavpShortFile()))) { | ||
| new HashFunctionTester(getAlgorithm()).test(RspTestEntry.iterateOverResource(is)); | ||
| } | ||
| } | ||
|
|
||
| @Test | ||
| public void cavpLongVectors() throws Throwable { |
There was a problem hiding this comment.
These are both the same. You could further parameterize these to accept a list of input files that get fed into the same cavp test case.
| private static final String ALGORITHM = "SHA3-384"; | ||
| private static final String NULL_DIGEST = | ||
| "0c63a75b845e4f7d01107d852e4c2485c51a50aaaa94fc61995e71bbee983a2ac3713831264adb47fb6bd1e058d5f004"; | ||
| private static final String TEST_VECTOR = | ||
| "e15a44d4e12ac138db4b8d77e954d78d94de4391ec2d1d8b2b8ace1a2f4b3d2fb9efd0546d6fcafacbe5b1640639b005"; | ||
| private static final String CAVP_SHORT_FILE = "SHA3_384ShortMsg.rsp.gz"; | ||
| private static final String CAVP_LONG_FILE = "SHA3_384LongMsg.rsp.gz"; |
There was a problem hiding this comment.
Personally, I'd inline these. Don't like the additional layer of indirection here.
…Context, and updateContextByteArray with appropriate aws-lc functionality
…ng. created the cpp for each hash with the appropriate definitions
…ests for sha3 excluding the HashFunctionTester implementations which need the appropriate zip files of data.
…properly. Adjusted SPI names.
…use SHA3 is not exposed in SUN JDK 8 which is neede for TestAPI and TestRandomly
…e consolidating functionality.
…cleaning up files
- Fix md_data leak: use scoped EVP_MD_CTX (EVP_MD_CTX_auto) in initContext/updateContextByteArray/updateNativeByteBuffer so the EVP_DigestInit-allocated md_data is freed on every call. - Move the JNI class-name token (JAVA_CLASS_NAME) into each per-algorithm .cpp so the shared template is algorithm-agnostic. - Consolidate MD_CTX_SIZE into the template and document it and DIGEST_BLOCK_SIZE (no public API exposes the internal ctx size). - Explain java_buffer vs bounce_buffer usage; clean up whitespace and the fast-path scratch comment. - Restore the unrelated .project deletion. - Refactor BaseSHATest to take algorithm/pre-image/vectors/CAVP files via constructor; fold duplicate CAVP tests into one file-list test; inline the SHA*Test constants.
bb80dde to
cc81cdb
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #485 +/- ##
============================================
- Coverage 78.55% 78.54% -0.02%
+ Complexity 1217 1216 -1
============================================
Files 127 128 +1
Lines 7756 7843 +87
Branches 982 989 +7
============================================
+ Hits 6093 6160 +67
- Misses 1133 1145 +12
- Partials 530 538 +8 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Changes: Implemented hash_evp_template.cpp.template, which exposes the EVP_MD API. Exposed SHA3_224, SHA3_256, SHA3_384, and SHA3_512. Allows for the use of these algorithms in an isolated context at the moment.
Choices: Chose to use the specific constants described in the csrc files for each algorithm because they are not all exposed through EVP_MD. Manually copying the context from the Java state to EVP_MD_CTX and vice versa. Is there a better way of doing this?
Testing: All testing was done the same as the other hash functions. Individual classes for each algorithm that contain KATs and the use HashFunctionTester. Did CAVP testing with the files from https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/secure-hashing. Had to set a minimum Java version for HashFunctionTester because SUN JDK8 does not expose SHA3 so trying to compare the implementations throws a NoSuchAlgorithmException.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.