summaryrefslogtreecommitdiffstats
path: root/crypto/evp/m_sha1.c
diff options
context:
space:
mode:
authorViktor Dukhovni <openssl-users@dukhovni.org>2018-02-13 22:43:15 -0500
committerViktor Dukhovni <openssl-users@dukhovni.org>2018-02-13 23:27:51 -0500
commitbabab8e7c9060cd4e8e423a783853503982a5d27 (patch)
treec693d31d5d3c1a308ffba96b02c89361b4b63457 /crypto/evp/m_sha1.c
parent72960279562e9af53264155a46b4a0b6a40f9590 (diff)
Avoid fragile aliasing of SHA224/384 update/final
This is purported to save a few cycles, but makes the code less obvious and more brittle, and in fact breaks on platforms where for ABI continuity reasons there is a SHA2 implementation in libc, and so EVP needs to call those to avoid conflicts. A sufficiently good optimizer could simply generate the same entry points for: foo(...) { ... } and bar(...) { return foo(...); } but, even without that, the different is negligible, with the "winner" varying from run to run (openssl speed -evp sha384): Old: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes sha384 28864.28k 117362.62k 266469.21k 483258.03k 635144.87k 649123.16k New: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes sha384 30055.18k 120725.98k 272057.26k 482847.40k 634585.09k 650308.27k Reviewed-by: Rich Salz <rsalz@openssl.org>
Diffstat (limited to 'crypto/evp/m_sha1.c')
-rw-r--r--crypto/evp/m_sha1.c33
1 files changed, 24 insertions, 9 deletions
diff --git a/crypto/evp/m_sha1.c b/crypto/evp/m_sha1.c
index d73e412b8d..ac52417855 100644
--- a/crypto/evp/m_sha1.c
+++ b/crypto/evp/m_sha1.c
@@ -116,16 +116,21 @@ static int init224(EVP_MD_CTX *ctx)
return SHA224_Init(EVP_MD_CTX_md_data(ctx));
}
+static int update224(EVP_MD_CTX *ctx, const void *data, size_t count)
+{
+ return SHA224_Update(EVP_MD_CTX_md_data(ctx), data, count);
+}
+
+static int final224(EVP_MD_CTX *ctx, unsigned char *md)
+{
+ return SHA224_Final(md, EVP_MD_CTX_md_data(ctx));
+}
+
static int init256(EVP_MD_CTX *ctx)
{
return SHA256_Init(EVP_MD_CTX_md_data(ctx));
}
-/*
- * Even though there're separate SHA224_[Update|Final], we call
- * SHA256 functions even in SHA224 context. This is what happens
- * there anyway, so we can spare few CPU cycles:-)
- */
static int update256(EVP_MD_CTX *ctx, const void *data, size_t count)
{
return SHA256_Update(EVP_MD_CTX_md_data(ctx), data, count);
@@ -142,8 +147,8 @@ static const EVP_MD sha224_md = {
SHA224_DIGEST_LENGTH,
EVP_MD_FLAG_DIGALGID_ABSENT,
init224,
- update256,
- final256,
+ update224,
+ final224,
NULL,
NULL,
SHA256_CBLOCK,
@@ -189,6 +194,16 @@ static int init384(EVP_MD_CTX *ctx)
return SHA384_Init(EVP_MD_CTX_md_data(ctx));
}
+static int update384(EVP_MD_CTX *ctx, const void *data, size_t count)
+{
+ return SHA384_Update(EVP_MD_CTX_md_data(ctx), data, count);
+}
+
+static int final384(EVP_MD_CTX *ctx, unsigned char *md)
+{
+ return SHA384_Final(md, EVP_MD_CTX_md_data(ctx));
+}
+
static int init512(EVP_MD_CTX *ctx)
{
return SHA512_Init(EVP_MD_CTX_md_data(ctx));
@@ -249,8 +264,8 @@ static const EVP_MD sha384_md = {
SHA384_DIGEST_LENGTH,
EVP_MD_FLAG_DIGALGID_ABSENT,
init384,
- update512,
- final512,
+ update384,
+ final384,
NULL,
NULL,
SHA512_CBLOCK,