Implement SHA-3 #479
Closed
Implement SHA-3 #479
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Hi! First, this is a pretty big contribution, so thanks both for the interest in mbed TLS and the support! To accept this contribution and any further contribution we will need a Contributor’s Licence Agreement (CLA) signed by yourself or by whoever has the authority to do so. You can find an agreement to sign here, which can be signed and returned to us, or you could create an mbed account and accept a slightly different agreement here with a click through if this is a personal contribution. Thanks in advance for your understanding. Because this is a large contribution, I have only given this a brief review to confirm we'd like to accept it (you've followed our style and conventions very well), and I'll follow up with a more detailed review to identify any issues once we've received a CLA and are ready to merge. Again, thanks for the support! |
A few initial tests are included, and are passing successfully.
SHA3-256 now slightly outperforms SHA-256. Benchmark output: SHA-256 : 116511 Kb/s, 16 cycles/byte SHA3-224 : 122361 Kb/s, 15 cycles/byte Tested on Ubuntu 14.04, Intel Core i7-2630QM (@2.6 GHz turbo boost). I think there's still room for further improvements. My Ada implementation of SHA3-256 is able to achieve 151000 Kb/s on the same system.
10 test vectors are implemented for each of the four SHA-3 variants from the ShortMsg test vectors from: http://csrc.nist.gov/groups/STM/cavp/secure-hashing.html#test-vectors
The self-tests were slightly adjusted to correct the verbose output format to match the format of other ciphers.
This change assigns the error codes for Keccak-f[1600], Keccak-Sponge, SHA-3, and SHAKE according to the policy defined in error.h A gap is left in the error code allocations for the ChaCha20/Poly1305 error codes added in the branch damaki:chacha20 in commit a2cb9fd to avoid clashes when these two pull requests are merged (assuming they are both accepted).
|
Hello again, I've just rebased my branch with the latest mbedTLS development branch to resolve the merge conflicts and to keep it more up-to-date. |
|
Any plans for this to accepted? |
Closed
simonbutcher
added
the
component-crypto
|
i will use this and test ! i am needing :) |
7 tasks
This was referenced May 20, 2022
Merged
iameli
pushed a commit
to livepeer/mbedtls
that referenced
this pull request
Dec 5, 2023
As reported in Mbed-TLS#479, testing for OPENSSL_cleanse() behavior within ./configure cannot happen when used in cross compilation environment. And autoconf -Wall reminds us about this issue: configure.ac:267: warning: AC_RUN_IFELSE called without default to allow cross compiling ../../lib/autoconf/general.m4:2759: AC_RUN_IFELSE is expanded from... configure.ac:267: the top level configure.ac:267: warning: AC_RUN_IFELSE called without default to allow cross compiling ../../lib/autoconf/general.m4:2759: AC_RUN_IFELSE is expanded from... configure.ac:267: the top level If cross-compiling, OPENSSL_cleanse() behavior cannot be validated, and should be considered broken.
iameli
pushed a commit
to livepeer/mbedtls
that referenced
this pull request
Dec 5, 2023
As reported in Mbed-TLS#479, testing for OPENSSL_cleanse() behavior within ./configure cannot happen when used in cross compilation environment. The initial issue addressed by this runtime test in ./configure was reported in Mbed-TLS#414 with OPENSSL_cleanse() and was said to be related to OpenSSL 1.0.2g on aarch64. Subsequent releases of OpenSSL address the issue, and should be considered fixed as of: - OpenSSL 1.0.2i, with commit 5bbdc26cadc01cab811040e861f1f98e0f3af348 ("crypto/mem_clr.c: switch to OPENSSL_cleanse implementation from master.") - OpenSSL 1.1.0 and up, with commit 104ce8a9f02d250dd43c255eb7b8747e81b29422 ("RT4116: Change cleanse to just memset") Then there's no reason for current OpenSSL versions to use the broken OPENSSL_cleanse() implementation, so the runtime test is almost useless and can be replaced by a version check. If older OpenSSL version is detected, runtime OPENSSL_cleanse() test will take place as before (provided libsrtp is not to be cross compiled). If newer OpenSSL version is detected, no runtime OPENSSL_cleanse() is needed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello!
Keccak won the SHA-3 competition in 2012 and was standardized by NIST in August 2015. This pull request adds the following SHA-3 hash functions and extendable output functions (XOF) to the cipher lib, as specified by NIST FIPS PUB 202:
* Hash: SHA3-224, SHA3-256, SHA3-384, and SHA3-512.
* XOF: SHAKE128 and SHAKE256.
The following modules have been added to the cipher lib:
* keccakf.c - Implements the Keccak-f[1600] permutation.
* keccak_sponge.c - Implements the Sponge cryptographic construction.
* sha3.c - Implements the SHA-3 hashing algorithms.
* shake.c - Implements the SHAKE XOFs.
I've also added the SHA-3 hash functions to the MD module.
Here's a list of references that were used:
* http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf
* http://keccak.noekeon.org/Keccak-reference-3.0.pdf
I've added tests for each of the SHA-3 and SHAKE algorithms, with test vectors used from:
* http://csrc.nist.gov/groups/STM/cavp/secure-hashing.html#test-vectors
* http://csrc.nist.gov/groups/ST/toolkit/examples.html#aHashing
* http://www.di-mgt.com.au/sha_testvectors.html
I've also added the SHA-3 hashing functions to the benchmark program. Here's the performance of SHA-3 compared to the other hash functions:
MD5 : 353939 Kb/s, 5 cycles/byte
RIPEMD160 : 205729 Kb/s, 9 cycles/byte
SHA-1 : 274623 Kb/s, 7 cycles/byte
SHA-256 : 116313 Kb/s, 17 cycles/byte
SHA-512 : 161491 Kb/s, 12 cycles/byte
SHA3-224 : 123865 Kb/s, 16 cycles/byte
SHA3-256 : 123939 Kb/s, 16 cycles/byte
SHA3-384 : 103150 Kb/s, 18 cycles/byte
SHA3-512 : 72815 Kb/s, 27 cycles/byte
This output was produced on a Ubuntu 14.04 system with an Intel Core i7-2630QM, built using GCC 4.9.3. I think there's still room for further improvement, though.