kris/boringssl
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
387b07b78d
boringssl/crypto/fipsmodule/sha/sha256.c

344 lines
13 KiB
C
Raw Normal View History

Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
/* Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com)
* All rights reserved.
*
* This package is an SSL implementation written
* by Eric Young (eay@cryptsoft.com).
* The implementation was written so as to conform with Netscapes SSL.
*
* This library is free for commercial and non-commercial use as long as
* the following conditions are aheared to. The following conditions
* apply to all code found in this distribution, be it the RC4, RSA,
* lhash, DES, etc., code; not just the SSL code. The SSL documentation
* included with this distribution is covered by the same copyright terms
* except that the holder is Tim Hudson (tjh@cryptsoft.com).
*
* Copyright remains Eric Young's, and as such any Copyright notices in
* the code are not to be removed.
* If this package is used in a product, Eric Young should be given attribution
* as the author of the parts of the library used.
* This can be in the form of a textual message at program startup or
* in documentation (online or textual) provided with the package.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* "This product includes cryptographic software written by
* Eric Young (eay@cryptsoft.com)"
* The word 'cryptographic' can be left out if the rouines from the library
* being used are not cryptographic related :-).
* 4. If you include any Windows specific code (or a derivative thereof) from
* the apps directory (application code) you must include an acknowledgement:
* "This product includes software written by Tim Hudson (tjh@cryptsoft.com)"
*
* THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* The licence and distribution terms for any publically available version or
* derivative of this code cannot be changed. i.e. this code cannot simply be
* copied and put under another distribution licence
* [including the GNU Public Licence.] */
#include <openssl/sha.h>
#include <string.h>
#include <openssl/mem.h>
Add ABI tests for SHA*. Bug: 181 Change-Id: Ica9299613d7fd1b803533b7e489b9ba8fe816a24 Reviewed-on: https://boringssl-review.googlesource.com/c/33968 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2018-12-31 07:31:44 +00:00
#include "internal.h"
First part of the FIPS module. Change-Id: Ic3a91ccd2c8cdc364740f256fdb8a7ff66177947 Reviewed-on: https://boringssl-review.googlesource.com/14506 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
2017-04-04 22:21:43 +01:00
#include "../../internal.h"
Work around language and compiler bug in memcpy, etc. Most C standard library functions are undefined if passed NULL, even when the corresponding length is zero. This gives them (and, in turn, all functions which call them) surprising behavior on empty arrays. Some compilers will miscompile code due to this rule. See also https://www.imperialviolet.org/2016/06/26/nonnull.html Add OPENSSL_memcpy, etc., wrappers which avoid this problem. BUG=23 Change-Id: I95f42b23e92945af0e681264fffaf578e7f8465e Reviewed-on: https://boringssl-review.googlesource.com/12928 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2016-12-13 06:07:13 +00:00
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
int SHA224_Init(SHA256_CTX *sha) {
Work around language and compiler bug in memcpy, etc. Most C standard library functions are undefined if passed NULL, even when the corresponding length is zero. This gives them (and, in turn, all functions which call them) surprising behavior on empty arrays. Some compilers will miscompile code due to this rule. See also https://www.imperialviolet.org/2016/06/26/nonnull.html Add OPENSSL_memcpy, etc., wrappers which avoid this problem. BUG=23 Change-Id: I95f42b23e92945af0e681264fffaf578e7f8465e Reviewed-on: https://boringssl-review.googlesource.com/12928 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2016-12-13 06:07:13 +00:00
OPENSSL_memset(sha, 0, sizeof(SHA256_CTX));
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
sha->h[0] = 0xc1059ed8UL;
sha->h[1] = 0x367cd507UL;
sha->h[2] = 0x3070dd17UL;
sha->h[3] = 0xf70e5939UL;
sha->h[4] = 0xffc00b31UL;
sha->h[5] = 0x68581511UL;
sha->h[6] = 0x64f98fa7UL;
sha->h[7] = 0xbefa4fa4UL;
Revert md_len removal from SHA256_CTX and SHA512_CTX. This reverts commits: - 91586371422dae70481c39752e55f01f50e9a93a - a90aa643024459c1698dbec84f4c79a3238b3db8 - c0d8b83b4462a0eb1889f32dbd7f46e83f4dbc81 It turns out code outside of BoringSSL also mismatches Init and Update/Final functions. Since this is largely cosmetic, it's probably not worth the cost to do this. Change-Id: I14e7b299172939f69ced2114be45ccba1dbbb704 Reviewed-on: https://boringssl-review.googlesource.com/7793 Reviewed-by: Adam Langley <agl@google.com>
2016-04-27 19:59:12 +01:00
sha->md_len = SHA224_DIGEST_LENGTH;
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
return 1;
}
int SHA256_Init(SHA256_CTX *sha) {
Work around language and compiler bug in memcpy, etc. Most C standard library functions are undefined if passed NULL, even when the corresponding length is zero. This gives them (and, in turn, all functions which call them) surprising behavior on empty arrays. Some compilers will miscompile code due to this rule. See also https://www.imperialviolet.org/2016/06/26/nonnull.html Add OPENSSL_memcpy, etc., wrappers which avoid this problem. BUG=23 Change-Id: I95f42b23e92945af0e681264fffaf578e7f8465e Reviewed-on: https://boringssl-review.googlesource.com/12928 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2016-12-13 06:07:13 +00:00
OPENSSL_memset(sha, 0, sizeof(SHA256_CTX));
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
sha->h[0] = 0x6a09e667UL;
sha->h[1] = 0xbb67ae85UL;
sha->h[2] = 0x3c6ef372UL;
sha->h[3] = 0xa54ff53aUL;
sha->h[4] = 0x510e527fUL;
sha->h[5] = 0x9b05688cUL;
sha->h[6] = 0x1f83d9abUL;
sha->h[7] = 0x5be0cd19UL;
Revert md_len removal from SHA256_CTX and SHA512_CTX. This reverts commits: - 91586371422dae70481c39752e55f01f50e9a93a - a90aa643024459c1698dbec84f4c79a3238b3db8 - c0d8b83b4462a0eb1889f32dbd7f46e83f4dbc81 It turns out code outside of BoringSSL also mismatches Init and Update/Final functions. Since this is largely cosmetic, it's probably not worth the cost to do this. Change-Id: I14e7b299172939f69ced2114be45ccba1dbbb704 Reviewed-on: https://boringssl-review.googlesource.com/7793 Reviewed-by: Adam Langley <agl@google.com>
2016-04-27 19:59:12 +01:00
sha->md_len = SHA256_DIGEST_LENGTH;
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
return 1;
}
Rename 'md' output parameter to 'out' and add bounds. We usually name output parameters 'out'. (Someone made a C++ templating change in Chromium which messed up const-ness, saw the compile error, and thought it was in MD5_Final.) Also tag the parameters with the sizes. Sadly, there's a bit of goofiness around SHA224_Final/SHA256_Final and SHA384_Final/SHA512_Final, but they're just documentation anyway. (Though it does touch on the mess that is sha->md_len which would be nice to clear through somehow.) Change-Id: I1918b7eecfe13f13b217d01d4414ac2358802354 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35484 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2019-04-05 01:54:25 +01:00
uint8_t *SHA224(const uint8_t *data, size_t len,
uint8_t out[SHA224_DIGEST_LENGTH]) {
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
SHA256_CTX ctx;
SHA224_Init(&ctx);
Don't mismatch Init and Update/Final hash functions. Fixes the ASan bot. Change-Id: I29b9b98680b634c5e486a734afa38f9d4e458518 Reviewed-on: https://boringssl-review.googlesource.com/7792 Reviewed-by: Adam Langley <agl@google.com>
2016-04-27 19:51:17 +01:00
SHA224_Update(&ctx, data, len);
SHA224_Final(out, &ctx);
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
OPENSSL_cleanse(&ctx, sizeof(ctx));
return out;
}
Rename 'md' output parameter to 'out' and add bounds. We usually name output parameters 'out'. (Someone made a C++ templating change in Chromium which messed up const-ness, saw the compile error, and thought it was in MD5_Final.) Also tag the parameters with the sizes. Sadly, there's a bit of goofiness around SHA224_Final/SHA256_Final and SHA384_Final/SHA512_Final, but they're just documentation anyway. (Though it does touch on the mess that is sha->md_len which would be nice to clear through somehow.) Change-Id: I1918b7eecfe13f13b217d01d4414ac2358802354 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35484 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2019-04-05 01:54:25 +01:00
uint8_t *SHA256(const uint8_t *data, size_t len,
uint8_t out[SHA256_DIGEST_LENGTH]) {
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
SHA256_CTX ctx;
SHA256_Init(&ctx);
SHA256_Update(&ctx, data, len);
SHA256_Final(out, &ctx);
OPENSSL_cleanse(&ctx, sizeof(ctx));
return out;
}
int SHA224_Update(SHA256_CTX *ctx, const void *data, size_t len) {
return SHA256_Update(ctx, data, len);
}
Rename 'md' output parameter to 'out' and add bounds. We usually name output parameters 'out'. (Someone made a C++ templating change in Chromium which messed up const-ness, saw the compile error, and thought it was in MD5_Final.) Also tag the parameters with the sizes. Sadly, there's a bit of goofiness around SHA224_Final/SHA256_Final and SHA384_Final/SHA512_Final, but they're just documentation anyway. (Though it does touch on the mess that is sha->md_len which would be nice to clear through somehow.) Change-Id: I1918b7eecfe13f13b217d01d4414ac2358802354 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35484 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2019-04-05 01:54:25 +01:00
int SHA224_Final(uint8_t out[SHA224_DIGEST_LENGTH], SHA256_CTX *ctx) {
// SHA224_Init sets |ctx->md_len| to |SHA224_DIGEST_LENGTH|, so this has a
// smaller output.
return SHA256_Final(out, ctx);
Revert md_len removal from SHA256_CTX and SHA512_CTX. This reverts commits: - 91586371422dae70481c39752e55f01f50e9a93a - a90aa643024459c1698dbec84f4c79a3238b3db8 - c0d8b83b4462a0eb1889f32dbd7f46e83f4dbc81 It turns out code outside of BoringSSL also mismatches Init and Update/Final functions. Since this is largely cosmetic, it's probably not worth the cost to do this. Change-Id: I14e7b299172939f69ced2114be45ccba1dbbb704 Reviewed-on: https://boringssl-review.googlesource.com/7793 Reviewed-by: Adam Langley <agl@google.com>
2016-04-27 19:59:12 +01:00
}
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
#define DATA_ORDER_IS_BIG_ENDIAN
#define HASH_CTX SHA256_CTX
#define HASH_CBLOCK 64
Rename 'md' output parameter to 'out' and add bounds. We usually name output parameters 'out'. (Someone made a C++ templating change in Chromium which messed up const-ness, saw the compile error, and thought it was in MD5_Final.) Also tag the parameters with the sizes. Sadly, there's a bit of goofiness around SHA224_Final/SHA256_Final and SHA384_Final/SHA512_Final, but they're just documentation anyway. (Though it does touch on the mess that is sha->md_len which would be nice to clear through somehow.) Change-Id: I1918b7eecfe13f13b217d01d4414ac2358802354 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35484 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2019-04-05 01:54:25 +01:00
#define HASH_DIGEST_LENGTH 32
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
Run the comment converter on libcrypto. crypto/{asn1,x509,x509v3,pem} were skipped as they are still OpenSSL style. Change-Id: I3cd9a60e1cb483a981aca325041f3fbce294247c Reviewed-on: https://boringssl-review.googlesource.com/19504 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-08-18 19:06:02 +01:00
// Note that FIPS180-2 discusses "Truncation of the Hash Function Output."
// default: case below covers for it. It's not clear however if it's permitted
// to truncate to amount of bytes not divisible by 4. I bet not, but if it is,
// then default: case shall be extended. For reference. Idea behind separate
// cases for pre-defined lenghts is to let the compiler decide if it's
// appropriate to unroll small loops.
//
// TODO(davidben): The small |md_len| case is one of the few places a low-level
// hash 'final' function can fail. This should never happen.
Revert md_len removal from SHA256_CTX and SHA512_CTX. This reverts commits: - 91586371422dae70481c39752e55f01f50e9a93a - a90aa643024459c1698dbec84f4c79a3238b3db8 - c0d8b83b4462a0eb1889f32dbd7f46e83f4dbc81 It turns out code outside of BoringSSL also mismatches Init and Update/Final functions. Since this is largely cosmetic, it's probably not worth the cost to do this. Change-Id: I14e7b299172939f69ced2114be45ccba1dbbb704 Reviewed-on: https://boringssl-review.googlesource.com/7793 Reviewed-by: Adam Langley <agl@google.com>
2016-04-27 19:59:12 +01:00
#define HASH_MAKE_STRING(c, s) \
do { \
uint32_t ll; \
unsigned int nn; \
switch ((c)->md_len) { \
case SHA224_DIGEST_LENGTH: \
for (nn = 0; nn < SHA224_DIGEST_LENGTH / 4; nn++) { \
ll = (c)->h[nn]; \
HOST_l2c(ll, (s)); \
} \
break; \
case SHA256_DIGEST_LENGTH: \
for (nn = 0; nn < SHA256_DIGEST_LENGTH / 4; nn++) { \
ll = (c)->h[nn]; \
HOST_l2c(ll, (s)); \
} \
break; \
default: \
if ((c)->md_len > SHA256_DIGEST_LENGTH) { \
return 0; \
} \
for (nn = 0; nn < (c)->md_len / 4; nn++) { \
ll = (c)->h[nn]; \
HOST_l2c(ll, (s)); \
} \
break; \
} \
} while (0)
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
#define HASH_UPDATE SHA256_Update
#define HASH_TRANSFORM SHA256_Transform
Revert md_len removal from SHA256_CTX and SHA512_CTX. This reverts commits: - 91586371422dae70481c39752e55f01f50e9a93a - a90aa643024459c1698dbec84f4c79a3238b3db8 - c0d8b83b4462a0eb1889f32dbd7f46e83f4dbc81 It turns out code outside of BoringSSL also mismatches Init and Update/Final functions. Since this is largely cosmetic, it's probably not worth the cost to do this. Change-Id: I14e7b299172939f69ced2114be45ccba1dbbb704 Reviewed-on: https://boringssl-review.googlesource.com/7793 Reviewed-by: Adam Langley <agl@google.com>
2016-04-27 19:59:12 +01:00
#define HASH_FINAL SHA256_Final
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
#define HASH_BLOCK_DATA_ORDER sha256_block_data_order
#ifndef SHA256_ASM
Add ABI tests for SHA*. Bug: 181 Change-Id: Ica9299613d7fd1b803533b7e489b9ba8fe816a24 Reviewed-on: https://boringssl-review.googlesource.com/c/33968 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2018-12-31 07:31:44 +00:00
static void sha256_block_data_order(uint32_t *state, const uint8_t *in,
size_t num);
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
#endif
#include "../digest/md32_common.h"
#ifndef SHA256_ASM
Improve crypto/digest/md32_common.h mechanism. The documentation in md32_common.h is now (more) correct with respect to the most important details of the layout of |HASH_CTX|. The documentation explaining why sha512.c doesn't use md32_common.h is now more accurate as well. Before, the C implementations of HASH_BLOCK_DATA_ORDER took a pointer to the |HASH_CTX| and the assembly language implementations took a pointer to the hash state |h| member of |HASH_CTX|. (This worked because |h| is always the first member of |HASH_CTX|.) Now, the C implementations take a pointer directly to |h| too. The definitions of |MD4_CTX|, |MD5_CTX|, and |SHA1_CTX| were changed to be consistent with |SHA256_CTX| and |SHA512_CTX| in storing the hash state in an array. This will break source compatibility with any external code that accesses the hash state directly, but will not affect binary compatibility. The second parameter of |HASH_BLOCK_DATA_ORDER| is now of type |const uint8_t *|; previously it was |void *| and all implementations had a |uint8_t *data| variable to access it as an array of bytes. This change paves the way for future refactorings such as automatically generating the |*_Init| functions and/or sharing one I-U-F implementation across all digest algorithms. Change-Id: I6e9dd09ff057c67941021d324a4fa1d39f58b0db Reviewed-on: https://boringssl-review.googlesource.com/6405 Reviewed-by: Adam Langley <agl@google.com>
2015-11-01 20:13:24 +00:00
static const uint32_t K256[64] = {
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
0x428a2f98UL, 0x71374491UL, 0xb5c0fbcfUL, 0xe9b5dba5UL, 0x3956c25bUL,
0x59f111f1UL, 0x923f82a4UL, 0xab1c5ed5UL, 0xd807aa98UL, 0x12835b01UL,
0x243185beUL, 0x550c7dc3UL, 0x72be5d74UL, 0x80deb1feUL, 0x9bdc06a7UL,
0xc19bf174UL, 0xe49b69c1UL, 0xefbe4786UL, 0x0fc19dc6UL, 0x240ca1ccUL,
0x2de92c6fUL, 0x4a7484aaUL, 0x5cb0a9dcUL, 0x76f988daUL, 0x983e5152UL,
0xa831c66dUL, 0xb00327c8UL, 0xbf597fc7UL, 0xc6e00bf3UL, 0xd5a79147UL,
0x06ca6351UL, 0x14292967UL, 0x27b70a85UL, 0x2e1b2138UL, 0x4d2c6dfcUL,
0x53380d13UL, 0x650a7354UL, 0x766a0abbUL, 0x81c2c92eUL, 0x92722c85UL,
0xa2bfe8a1UL, 0xa81a664bUL, 0xc24b8b70UL, 0xc76c51a3UL, 0xd192e819UL,
0xd6990624UL, 0xf40e3585UL, 0x106aa070UL, 0x19a4c116UL, 0x1e376c08UL,
0x2748774cUL, 0x34b0bcb5UL, 0x391c0cb3UL, 0x4ed8aa4aUL, 0x5b9cca4fUL,
0x682e6ff3UL, 0x748f82eeUL, 0x78a5636fUL, 0x84c87814UL, 0x8cc70208UL,
0x90befffaUL, 0xa4506cebUL, 0xbef9a3f7UL, 0xc67178f2UL};
Use the straight-forward ROTATE macro. I would hope any sensible compiler would recognize the rotation. (If not, we should at least pull this into crypto/internal.h.) Confirmed that clang at least produces the exact same instructions for sha256_block_data_order for release + NO_ASM. This is also mostly moot as SHA-1 and SHA-256 both have assembly versions on x86 that sidestep most of this. For the digests, take it out of md32_common.h since it doesn't use the macro. md32_common.h isn't sure whether it's a multiply-included header or not. It should be, but it has an #include guard (doesn't quite do what you'd want) and will get HOST_c2l, etc., confused if one tries to include it twice. Change-Id: I1632801de6473ffd2c6557f3412521ec5d6b305c Reviewed-on: https://boringssl-review.googlesource.com/6650 Reviewed-by: Adam Langley <agl@google.com>
2015-12-07 03:09:33 +00:00
#define ROTATE(a, n) (((a) << (n)) | ((a) >> (32 - (n))))
Run the comment converter on libcrypto. crypto/{asn1,x509,x509v3,pem} were skipped as they are still OpenSSL style. Change-Id: I3cd9a60e1cb483a981aca325041f3fbce294247c Reviewed-on: https://boringssl-review.googlesource.com/19504 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-08-18 19:06:02 +01:00
// FIPS specification refers to right rotations, while our ROTATE macro
// is left one. This is why you might notice that rotation coefficients
// differ from those observed in FIPS document by 32-N...
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
#define Sigma0(x) (ROTATE((x), 30) ^ ROTATE((x), 19) ^ ROTATE((x), 10))
#define Sigma1(x) (ROTATE((x), 26) ^ ROTATE((x), 21) ^ ROTATE((x), 7))
#define sigma0(x) (ROTATE((x), 25) ^ ROTATE((x), 14) ^ ((x) >> 3))
#define sigma1(x) (ROTATE((x), 15) ^ ROTATE((x), 13) ^ ((x) >> 10))
#define Ch(x, y, z) (((x) & (y)) ^ ((~(x)) & (z)))
#define Maj(x, y, z) (((x) & (y)) ^ ((x) & (z)) ^ ((y) & (z)))
#define ROUND_00_15(i, a, b, c, d, e, f, g, h) \
do { \
T1 += h + Sigma1(e) + Ch(e, f, g) + K256[i]; \
h = Sigma0(a) + Maj(a, b, c); \
d += T1; \
h += T1; \
} while (0)
#define ROUND_16_63(i, a, b, c, d, e, f, g, h, X) \
do { \
s0 = X[(i + 1) & 0x0f]; \
s0 = sigma0(s0); \
s1 = X[(i + 14) & 0x0f]; \
s1 = sigma1(s1); \
T1 = X[(i) & 0x0f] += s0 + s1 + X[(i + 9) & 0x0f]; \
ROUND_00_15(i, a, b, c, d, e, f, g, h); \
} while (0)
Improve crypto/digest/md32_common.h mechanism. The documentation in md32_common.h is now (more) correct with respect to the most important details of the layout of |HASH_CTX|. The documentation explaining why sha512.c doesn't use md32_common.h is now more accurate as well. Before, the C implementations of HASH_BLOCK_DATA_ORDER took a pointer to the |HASH_CTX| and the assembly language implementations took a pointer to the hash state |h| member of |HASH_CTX|. (This worked because |h| is always the first member of |HASH_CTX|.) Now, the C implementations take a pointer directly to |h| too. The definitions of |MD4_CTX|, |MD5_CTX|, and |SHA1_CTX| were changed to be consistent with |SHA256_CTX| and |SHA512_CTX| in storing the hash state in an array. This will break source compatibility with any external code that accesses the hash state directly, but will not affect binary compatibility. The second parameter of |HASH_BLOCK_DATA_ORDER| is now of type |const uint8_t *|; previously it was |void *| and all implementations had a |uint8_t *data| variable to access it as an array of bytes. This change paves the way for future refactorings such as automatically generating the |*_Init| functions and/or sharing one I-U-F implementation across all digest algorithms. Change-Id: I6e9dd09ff057c67941021d324a4fa1d39f58b0db Reviewed-on: https://boringssl-review.googlesource.com/6405 Reviewed-by: Adam Langley <agl@google.com>
2015-11-01 20:13:24 +00:00
static void sha256_block_data_order(uint32_t *state, const uint8_t *data,
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
size_t num) {
Fix integer types in low-level hash functions. Use sized integer types rather than unsigned char/int/long. The latter two are especially a mess as they're both used in lieu of uint32_t. Sometimes the code just blindly uses unsigned long and sometimes it uses unsigned int when an LP64 architecture would notice. Change-Id: I4c5c6aaf82cfe9fe523435588d286726a7c43056 Reviewed-on: https://boringssl-review.googlesource.com/4952 Reviewed-by: Adam Langley <agl@google.com>
2015-05-27 06:00:07 +01:00
uint32_t a, b, c, d, e, f, g, h, s0, s1, T1;
Improve crypto/digest/md32_common.h mechanism. The documentation in md32_common.h is now (more) correct with respect to the most important details of the layout of |HASH_CTX|. The documentation explaining why sha512.c doesn't use md32_common.h is now more accurate as well. Before, the C implementations of HASH_BLOCK_DATA_ORDER took a pointer to the |HASH_CTX| and the assembly language implementations took a pointer to the hash state |h| member of |HASH_CTX|. (This worked because |h| is always the first member of |HASH_CTX|.) Now, the C implementations take a pointer directly to |h| too. The definitions of |MD4_CTX|, |MD5_CTX|, and |SHA1_CTX| were changed to be consistent with |SHA256_CTX| and |SHA512_CTX| in storing the hash state in an array. This will break source compatibility with any external code that accesses the hash state directly, but will not affect binary compatibility. The second parameter of |HASH_BLOCK_DATA_ORDER| is now of type |const uint8_t *|; previously it was |void *| and all implementations had a |uint8_t *data| variable to access it as an array of bytes. This change paves the way for future refactorings such as automatically generating the |*_Init| functions and/or sharing one I-U-F implementation across all digest algorithms. Change-Id: I6e9dd09ff057c67941021d324a4fa1d39f58b0db Reviewed-on: https://boringssl-review.googlesource.com/6405 Reviewed-by: Adam Langley <agl@google.com>
2015-11-01 20:13:24 +00:00
uint32_t X[16];
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
int i;
while (num--) {
Improve crypto/digest/md32_common.h mechanism. The documentation in md32_common.h is now (more) correct with respect to the most important details of the layout of |HASH_CTX|. The documentation explaining why sha512.c doesn't use md32_common.h is now more accurate as well. Before, the C implementations of HASH_BLOCK_DATA_ORDER took a pointer to the |HASH_CTX| and the assembly language implementations took a pointer to the hash state |h| member of |HASH_CTX|. (This worked because |h| is always the first member of |HASH_CTX|.) Now, the C implementations take a pointer directly to |h| too. The definitions of |MD4_CTX|, |MD5_CTX|, and |SHA1_CTX| were changed to be consistent with |SHA256_CTX| and |SHA512_CTX| in storing the hash state in an array. This will break source compatibility with any external code that accesses the hash state directly, but will not affect binary compatibility. The second parameter of |HASH_BLOCK_DATA_ORDER| is now of type |const uint8_t *|; previously it was |void *| and all implementations had a |uint8_t *data| variable to access it as an array of bytes. This change paves the way for future refactorings such as automatically generating the |*_Init| functions and/or sharing one I-U-F implementation across all digest algorithms. Change-Id: I6e9dd09ff057c67941021d324a4fa1d39f58b0db Reviewed-on: https://boringssl-review.googlesource.com/6405 Reviewed-by: Adam Langley <agl@google.com>
2015-11-01 20:13:24 +00:00
a = state[0];
b = state[1];
c = state[2];
d = state[3];
e = state[4];
f = state[5];
g = state[6];
h = state[7];
Remove untested, unnecessary big-endian SHA-1/SHA-256 optimizations. Change-Id: I3939923d297b901719cb3fb4cff20e770f780c7a Reviewed-on: https://boringssl-review.googlesource.com/6441 Reviewed-by: Adam Langley <agl@google.com>
2015-11-05 05:26:01 +00:00
uint32_t l;
HOST_c2l(data, l);
T1 = X[0] = l;
ROUND_00_15(0, a, b, c, d, e, f, g, h);
HOST_c2l(data, l);
T1 = X[1] = l;
ROUND_00_15(1, h, a, b, c, d, e, f, g);
HOST_c2l(data, l);
T1 = X[2] = l;
ROUND_00_15(2, g, h, a, b, c, d, e, f);
HOST_c2l(data, l);
T1 = X[3] = l;
ROUND_00_15(3, f, g, h, a, b, c, d, e);
HOST_c2l(data, l);
T1 = X[4] = l;
ROUND_00_15(4, e, f, g, h, a, b, c, d);
HOST_c2l(data, l);
T1 = X[5] = l;
ROUND_00_15(5, d, e, f, g, h, a, b, c);
HOST_c2l(data, l);
T1 = X[6] = l;
ROUND_00_15(6, c, d, e, f, g, h, a, b);
HOST_c2l(data, l);
T1 = X[7] = l;
ROUND_00_15(7, b, c, d, e, f, g, h, a);
HOST_c2l(data, l);
T1 = X[8] = l;
ROUND_00_15(8, a, b, c, d, e, f, g, h);
HOST_c2l(data, l);
T1 = X[9] = l;
ROUND_00_15(9, h, a, b, c, d, e, f, g);
HOST_c2l(data, l);
T1 = X[10] = l;
ROUND_00_15(10, g, h, a, b, c, d, e, f);
HOST_c2l(data, l);
T1 = X[11] = l;
ROUND_00_15(11, f, g, h, a, b, c, d, e);
HOST_c2l(data, l);
T1 = X[12] = l;
ROUND_00_15(12, e, f, g, h, a, b, c, d);
HOST_c2l(data, l);
T1 = X[13] = l;
ROUND_00_15(13, d, e, f, g, h, a, b, c);
HOST_c2l(data, l);
T1 = X[14] = l;
ROUND_00_15(14, c, d, e, f, g, h, a, b);
HOST_c2l(data, l);
T1 = X[15] = l;
ROUND_00_15(15, b, c, d, e, f, g, h, a);
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
for (i = 16; i < 64; i += 8) {
ROUND_16_63(i + 0, a, b, c, d, e, f, g, h, X);
ROUND_16_63(i + 1, h, a, b, c, d, e, f, g, X);
ROUND_16_63(i + 2, g, h, a, b, c, d, e, f, X);
ROUND_16_63(i + 3, f, g, h, a, b, c, d, e, X);
ROUND_16_63(i + 4, e, f, g, h, a, b, c, d, X);
ROUND_16_63(i + 5, d, e, f, g, h, a, b, c, X);
ROUND_16_63(i + 6, c, d, e, f, g, h, a, b, X);
ROUND_16_63(i + 7, b, c, d, e, f, g, h, a, X);
}
Improve crypto/digest/md32_common.h mechanism. The documentation in md32_common.h is now (more) correct with respect to the most important details of the layout of |HASH_CTX|. The documentation explaining why sha512.c doesn't use md32_common.h is now more accurate as well. Before, the C implementations of HASH_BLOCK_DATA_ORDER took a pointer to the |HASH_CTX| and the assembly language implementations took a pointer to the hash state |h| member of |HASH_CTX|. (This worked because |h| is always the first member of |HASH_CTX|.) Now, the C implementations take a pointer directly to |h| too. The definitions of |MD4_CTX|, |MD5_CTX|, and |SHA1_CTX| were changed to be consistent with |SHA256_CTX| and |SHA512_CTX| in storing the hash state in an array. This will break source compatibility with any external code that accesses the hash state directly, but will not affect binary compatibility. The second parameter of |HASH_BLOCK_DATA_ORDER| is now of type |const uint8_t *|; previously it was |void *| and all implementations had a |uint8_t *data| variable to access it as an array of bytes. This change paves the way for future refactorings such as automatically generating the |*_Init| functions and/or sharing one I-U-F implementation across all digest algorithms. Change-Id: I6e9dd09ff057c67941021d324a4fa1d39f58b0db Reviewed-on: https://boringssl-review.googlesource.com/6405 Reviewed-by: Adam Langley <agl@google.com>
2015-11-01 20:13:24 +00:00
state[0] += a;
state[1] += b;
state[2] += c;
state[3] += d;
state[4] += e;
state[5] += f;
state[6] += g;
state[7] += h;
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)
2014-06-20 20:00:00 +01:00
}
}
Run the comment converter on libcrypto. crypto/{asn1,x509,x509v3,pem} were skipped as they are still OpenSSL style. Change-Id: I3cd9a60e1cb483a981aca325041f3fbce294247c Reviewed-on: https://boringssl-review.googlesource.com/19504 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-08-18 19:06:02 +01:00
#endif // !SHA256_ASM
First part of the FIPS module. Change-Id: Ic3a91ccd2c8cdc364740f256fdb8a7ff66177947 Reviewed-on: https://boringssl-review.googlesource.com/14506 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
2017-04-04 22:21:43 +01:00
Add SHA256_TransformBlocks. Rather than expose a (potentially) assembly function directly, wrap it in a C function to make visibility control easier. Change-Id: I4a2dfeb8999ff021b2e10fbc54850eeadabbefff Reviewed-on: https://boringssl-review.googlesource.com/27724 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2018-04-25 18:30:02 +01:00
void SHA256_TransformBlocks(uint32_t state[8], const uint8_t *data,
size_t num_blocks) {
sha256_block_data_order(state, data, num_blocks);
}
First part of the FIPS module. Change-Id: Ic3a91ccd2c8cdc364740f256fdb8a7ff66177947 Reviewed-on: https://boringssl-review.googlesource.com/14506 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
2017-04-04 22:21:43 +01:00
#undef DATA_ORDER_IS_BIG_ENDIAN
#undef HASH_CTX
#undef HASH_CBLOCK
Rename 'md' output parameter to 'out' and add bounds. We usually name output parameters 'out'. (Someone made a C++ templating change in Chromium which messed up const-ness, saw the compile error, and thought it was in MD5_Final.) Also tag the parameters with the sizes. Sadly, there's a bit of goofiness around SHA224_Final/SHA256_Final and SHA384_Final/SHA512_Final, but they're just documentation anyway. (Though it does touch on the mess that is sha->md_len which would be nice to clear through somehow.) Change-Id: I1918b7eecfe13f13b217d01d4414ac2358802354 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35484 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2019-04-05 01:54:25 +01:00
#undef HASH_DIGEST_LENGTH
First part of the FIPS module. Change-Id: Ic3a91ccd2c8cdc364740f256fdb8a7ff66177947 Reviewed-on: https://boringssl-review.googlesource.com/14506 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
2017-04-04 22:21:43 +01:00
#undef HASH_MAKE_STRING
#undef HASH_UPDATE
#undef HASH_TRANSFORM
#undef HASH_FINAL
#undef HASH_BLOCK_DATA_ORDER
#undef ROTATE
#undef Sigma0
#undef Sigma1
#undef sigma0
#undef sigma1
#undef Ch
#undef Maj
#undef ROUND_00_15
#undef ROUND_16_63
#undef HOST_c2l
#undef HOST_l2c
Reference in New Issue Copy Permalink