Remove support for static buffers in HMAC/digests

HMAC() and the one-step digests used to support passing a NULL buffer and
would return the digest in a static buffer. This design is firmly from the
nineties, not thread safe and it saves callers a single line. The few ports
that used to rely this were fixed with patches sent to non-hostile (and
non-dead) upstreams. It's early enough in the release cycle that remaining
uses hidden from the compiler should be caught, at least the ones that
matter.

There won't be that many since BoringSSL removed this feature in 2017.
https://boringssl-review.googlesource.com/14528

Add non-null attributes to the headers and add a few missing bounded
attributes.

ok beck jsing

Hide symbols in sha

ok tb@

Demacro SHA-512.

Use static inline functions instead of macros to implement SHA-512. At
the same time, make two key changes - firstly, rather than trying to
outsmart the compiler and shuffle variables around, write the algorithm
the way it is documented and actually swap the variable contents. Secondly,
instead of interleaving the message schedule update and the round, do the
full message schedule update first, then process the round.

Overall, we get safer and more readable code. Additionally, the compiler
can generate smaller and faster code (with a gain of 5-10% across a range
of architectures).

ok beck@ tb@

Clean up alignment handling for SHA-512.

This recommits r1.37 of sha512.c, however uses uint8_t * instead of void *
for the crypto_load_* functions and primarily uses const uint8_t * to track
input, only casting to const SHA_LONG64 * once we know that it is suitably
aligned. This prevents the compiler from implying alignment based on type.

Tested by tb@ and deraadt@ on platforms with gcc and strict alignment.

ok tb@

backout alignment changes (breaking at least two architectures)

Clean up alignment handling for SHA-512.

All assembly implementations are required to perform their own alignment
handling. In the case of the C implementation, on strict alignment
platforms, unaligned data will be copied into an aligned buffer. However,
most platforms then perform byte-by-byte reads (via the PULL64 macros).

Instead, remove SHA512_BLOCK_CAN_MANAGE_UNALIGNED_DATA and alignment
handling to sha512_block_data_order() - if the data is aligned then simply
perform 64 bit loads and then do endian conversion via be64toh(). If the
data is unaligned then use memcpy() and be64toh() (in the form of
crypto_load_be64toh()). Overall this reduces complexity and can improve
performance (on aarch64 we get a ~10% performance gain with aligned input
and about ~1-2% gain on armv7), while the same movq/bswapq is generated
for amd64 and movl/bswapl for i386.

ok tb@

Clean up SHA-512 input handling and round macros.

Avoid reach around and initialisation outside of the macro, cleaning up
the call sites to remove the initialisation. Use a T2 variable to more
closely follow the documented algorithm and remove the gorgeous compound
statement X = Y += A + B + C.

There is no change to the clang generated assembly on aarch64.

ok tb@

Reduce the number of SHA-512 C implementations from three to one.

We currently have three C implementations for SHA-512 - a version that is
optimised for CPUs with minimal registers (specifically i386), a regular
implementation and a semi-unrolled implementation. Testing on a ~15 year
old i386 CPU, the fastest version is actually the semi-unrolled version
(not to mention that we still currently have an i586 assembly
implementation that is used on i386 instead...).

More decent architectures do not seem to care between the regular and
semi-unrolled version, presumably since they are effectively doing the
same thing in hardware during execution.

Remove all except the semi-unrolled version.

ok tb@

Add support for truncated SHA512 variants.

This adds support for SHA512/224 and SHA512/256, as specified in FIPS
FIPS 180-4. These are truncated versions of the SHA512 hash.

ok tb@

Use memset() and only initialise non-zero struct members.

ok tb@

Provide and use crypto_ro{l,r}_u{32,64}().

Various code in libcrypto needs bitwise rotation - rather than defining
different versions across the code base, provide a common set that can
be reused. Any sensible compiler optimises these to a single instruction
where the architecture supports it, which means we can ditch the inline
assembly.

On the chance that we need to provide a platform specific versions, this
follows the approach used in BN where a MD crypto_arch.h header could be
added in the future, which would then provide more specific versions of
these functions.

ok tb@

Provide and use crypto_store_htobe64().

It is common to need to store data in a specific endianness - rather than
handrolling and deduplicating code to do this, provide a
crypto_store_htobe64() function that converts from host endian to big
endian, before storing the data to a location with unknown alignment.

ok tb@

Recommit jsing's r1.27 - portable is ready

Use htobe64() instead of testing BYTE_ORDER and then handrolling htobe64().

Thanks to tobhe for providing most of the fix via openiked-portable

Back out r1.27 using htobe64() - apparently some OS don't have it.

ok jsing

Simplify handling of big vs little endian.

Rather than sprinkling BYTE_ORDER checks throughout the implementation,
always define PULL64 - on big endian platforms it just becomes a no-op.

ok tb@

Use htobe64() instead of testing BYTE_ORDER and then handrolling htobe64().

ok tb@

Omit sha512_block_data_order() prototype when assembly is not being used.

In the case that the pure C implementation of SHA512 is being used, the
prototype is unnecessary as the function is declared static and exists
in dependency order. Simply omit the prototype rather than using #ifndef
to toggle the static prefix.

ok tb@

Remove less than useful implementation notes.

ok tb@

Whitespace fixes.

Mechanically replace "a,b" with "a, b", followed with some manual
indentation clean up.

No change in generated assembly.

Use multiple statements instead of a statement with multiple expressions.

No change in generated assembly.

Reorder functions/code.

No intended functional change.

Tidy includes.

Add license to sha256.c/sha512.c.

Use multiple statements instead of comma separated expressions.

No change to generated assembly.

Add some blank lines for readability, along with some more style(9) tweaks.

Whack sha with a style(9) stick.

No change in generated assembly.

Switch to <endian.h> from <machine/endian.h> for better portability.

ok tb@

Remove I386_ONLY define. It was only used to prefer a
faster-on-genuine-80386-but-slower-on-80486-onwards innstruction sequence in
the SHA512 code, and had not been enabled in years, if at all.

ok tom@ bcook@

Correct spelling of OPENSSL_cleanse.

ok miod@

Only import cryptlib.h in the four source files that actually need it.
Remove the openssl public includes from cryptlib.h and add a small number
of includes into the source files that actually need them. While here,
also sort/group/tidy the includes.

ok beck@ miod@

Explicitly include <openssl/opensslconf.h> in every file that references
an OPENSSL_NO_* define. This avoids relying on something else pulling it
in for us, plus it fixes several cases where the #ifndef OPENSSL_NO_XYZ is
never going to do anything, since OPENSSL_NO_XYZ will never defined, due
to the fact that opensslconf.h has not been included.

This also includes some miscellaneous sorting/tidying of headers.

Remove leading underscore from _BYTE_ORDER and _{LITTLE,BIG}_ENDIAN, to be
more friendly to systems where the underscore flavours may be defined as empty.
Found the hard way be bcook@; joint brainstrom with bcook beck and guenther

remove unused, private version strings except SSL_version_str

Also remove unused des_ver.h, which exports some of these strings, but is not installed.

ok miod@ tedu@

tags as requested by miod and tedu

Get __STRICT_ALIGNMENT from <machine/endian.h> and decide upon it, rather
than defining it for not (i386 and amd64 (and sometimes s390)) only.

Compile-time tests remain compile-time tests, and runtime-test remain
runtime-test instead of being converted to compile-time tests, per matthew@'s
explicit demand (rationale: this makes sure the compiler checks your code even
if you won't run it).

No functional change except on s390 (which we don't run on) and vax (which we
run on, but noone cares about)

ok matthew@

Remove fips_md_init() macro indirection for digest algorithms, used by the
OpenSSL FIPS module to prevent forbidden digests to be allowed.
No functional change but readability.

ok deraadt@

Unifdef -UPEDANTIC. ok beck@ tedu@

Do not ask the user to pass either -DB_ENDIAN or -DL_ENDIAN to the compiler,
but rather figure out the endianness from <machine/endian.h> automagically;
help from guenther@

ok jca@ guenther@ beck@ and the rest of the `Buena SSL rampage club'

Get rid of MS Visual C compiler and Intel C compiler specific defines.

Remove support for big-endian i386 and amd64.

Before someone suggests the OpenSSL people are junkies, here is what they
mention about this:
/* Most will argue that x86_64 is always little-endian. Well,
* yes, but then we have stratus.com who has modified gcc to
* "emulate" big-endian on x86. Is there evidence that they
* [or somebody else] won't do same for x86_64? Naturally no.
* And this line is waiting ready for that brave soul:-) */

So, yes, they are on drugs. But they are not alone, the stratus.com people are,
too.

Reliability fix for SHA384 SSL/TLS ciphers on strict alignment
architectures. ok miod@ djm@

Upstream patch:
commit cdd1acd788020d2c525331da1712ada778f1373c
Author: Andy Polyakov <appro@openssl.org>
Date: Wed Dec 18 21:27:35 2013 +0100

branches: 1.1.1;
Initial revision

Hide symbols in sha

ok tb@

Demacro SHA-512.

Use static inline functions instead of macros to implement SHA-512. At
the same time, make two key changes - firstly, rather than trying to
outsmart the compiler and shuffle variables around, write the algorithm
the way it is documented and actually swap the variable contents. Secondly,
instead of interleaving the message schedule update and the round, do the
full message schedule update first, then process the round.

Overall, we get safer and more readable code. Additionally, the compiler
can generate smaller and faster code (with a gain of 5-10% across a range
of architectures).

ok beck@ tb@

Clean up alignment handling for SHA-512.

This recommits r1.37 of sha512.c, however uses uint8_t * instead of void *
for the crypto_load_* functions and primarily uses const uint8_t * to track
input, only casting to const SHA_LONG64 * once we know that it is suitably
aligned. This prevents the compiler from implying alignment based on type.

Tested by tb@ and deraadt@ on platforms with gcc and strict alignment.

ok tb@

backout alignment changes (breaking at least two architectures)

Clean up alignment handling for SHA-512.

All assembly implementations are required to perform their own alignment
handling. In the case of the C implementation, on strict alignment
platforms, unaligned data will be copied into an aligned buffer. However,
most platforms then perform byte-by-byte reads (via the PULL64 macros).

Instead, remove SHA512_BLOCK_CAN_MANAGE_UNALIGNED_DATA and alignment
handling to sha512_block_data_order() - if the data is aligned then simply
perform 64 bit loads and then do endian conversion via be64toh(). If the
data is unaligned then use memcpy() and be64toh() (in the form of
crypto_load_be64toh()). Overall this reduces complexity and can improve
performance (on aarch64 we get a ~10% performance gain with aligned input
and about ~1-2% gain on armv7), while the same movq/bswapq is generated
for amd64 and movl/bswapl for i386.

ok tb@

Clean up SHA-512 input handling and round macros.

Avoid reach around and initialisation outside of the macro, cleaning up
the call sites to remove the initialisation. Use a T2 variable to more
closely follow the documented algorithm and remove the gorgeous compound
statement X = Y += A + B + C.

There is no change to the clang generated assembly on aarch64.

ok tb@

Reduce the number of SHA-512 C implementations from three to one.

We currently have three C implementations for SHA-512 - a version that is
optimised for CPUs with minimal registers (specifically i386), a regular
implementation and a semi-unrolled implementation. Testing on a ~15 year
old i386 CPU, the fastest version is actually the semi-unrolled version
(not to mention that we still currently have an i586 assembly
implementation that is used on i386 instead...).

More decent architectures do not seem to care between the regular and
semi-unrolled version, presumably since they are effectively doing the
same thing in hardware during execution.

Remove all except the semi-unrolled version.

ok tb@

Add support for truncated SHA512 variants.

This adds support for SHA512/224 and SHA512/256, as specified in FIPS
FIPS 180-4. These are truncated versions of the SHA512 hash.

ok tb@

Use memset() and only initialise non-zero struct members.

ok tb@

Provide and use crypto_ro{l,r}_u{32,64}().

Various code in libcrypto needs bitwise rotation - rather than defining
different versions across the code base, provide a common set that can
be reused. Any sensible compiler optimises these to a single instruction
where the architecture supports it, which means we can ditch the inline
assembly.

On the chance that we need to provide a platform specific versions, this
follows the approach used in BN where a MD crypto_arch.h header could be
added in the future, which would then provide more specific versions of
these functions.

ok tb@

Provide and use crypto_store_htobe64().

It is common to need to store data in a specific endianness - rather than
handrolling and deduplicating code to do this, provide a
crypto_store_htobe64() function that converts from host endian to big
endian, before storing the data to a location with unknown alignment.

ok tb@

Recommit jsing's r1.27 - portable is ready

Use htobe64() instead of testing BYTE_ORDER and then handrolling htobe64().

Thanks to tobhe for providing most of the fix via openiked-portable

Back out r1.27 using htobe64() - apparently some OS don't have it.

ok jsing

Simplify handling of big vs little endian.

Rather than sprinkling BYTE_ORDER checks throughout the implementation,
always define PULL64 - on big endian platforms it just becomes a no-op.

ok tb@

Use htobe64() instead of testing BYTE_ORDER and then handrolling htobe64().

ok tb@

Omit sha512_block_data_order() prototype when assembly is not being used.

In the case that the pure C implementation of SHA512 is being used, the
prototype is unnecessary as the function is declared static and exists
in dependency order. Simply omit the prototype rather than using #ifndef
to toggle the static prefix.

ok tb@

Remove less than useful implementation notes.

ok tb@

Whitespace fixes.

Mechanically replace "a,b" with "a, b", followed with some manual
indentation clean up.

No change in generated assembly.

Use multiple statements instead of a statement with multiple expressions.

No change in generated assembly.

Reorder functions/code.

No intended functional change.

Tidy includes.

Add license to sha256.c/sha512.c.

Use multiple statements instead of comma separated expressions.

No change to generated assembly.

Add some blank lines for readability, along with some more style(9) tweaks.

Whack sha with a style(9) stick.

No change in generated assembly.

Switch to <endian.h> from <machine/endian.h> for better portability.

ok tb@

Remove I386_ONLY define. It was only used to prefer a
faster-on-genuine-80386-but-slower-on-80486-onwards innstruction sequence in
the SHA512 code, and had not been enabled in years, if at all.

ok tom@ bcook@

Correct spelling of OPENSSL_cleanse.

ok miod@

Only import cryptlib.h in the four source files that actually need it.
Remove the openssl public includes from cryptlib.h and add a small number
of includes into the source files that actually need them. While here,
also sort/group/tidy the includes.

ok beck@ miod@

Explicitly include <openssl/opensslconf.h> in every file that references
an OPENSSL_NO_* define. This avoids relying on something else pulling it
in for us, plus it fixes several cases where the #ifndef OPENSSL_NO_XYZ is
never going to do anything, since OPENSSL_NO_XYZ will never defined, due
to the fact that opensslconf.h has not been included.

This also includes some miscellaneous sorting/tidying of headers.

Remove leading underscore from _BYTE_ORDER and _{LITTLE,BIG}_ENDIAN, to be
more friendly to systems where the underscore flavours may be defined as empty.
Found the hard way be bcook@; joint brainstrom with bcook beck and guenther

remove unused, private version strings except SSL_version_str

Also remove unused des_ver.h, which exports some of these strings, but is not installed.

ok miod@ tedu@

tags as requested by miod and tedu

Get __STRICT_ALIGNMENT from <machine/endian.h> and decide upon it, rather
than defining it for not (i386 and amd64 (and sometimes s390)) only.

Compile-time tests remain compile-time tests, and runtime-test remain
runtime-test instead of being converted to compile-time tests, per matthew@'s
explicit demand (rationale: this makes sure the compiler checks your code even
if you won't run it).

No functional change except on s390 (which we don't run on) and vax (which we
run on, but noone cares about)

ok matthew@

Remove fips_md_init() macro indirection for digest algorithms, used by the
OpenSSL FIPS module to prevent forbidden digests to be allowed.
No functional change but readability.

ok deraadt@

Unifdef -UPEDANTIC. ok beck@ tedu@

Do not ask the user to pass either -DB_ENDIAN or -DL_ENDIAN to the compiler,
but rather figure out the endianness from <machine/endian.h> automagically;
help from guenther@

ok jca@ guenther@ beck@ and the rest of the `Buena SSL rampage club'

Get rid of MS Visual C compiler and Intel C compiler specific defines.

Remove support for big-endian i386 and amd64.

Before someone suggests the OpenSSL people are junkies, here is what they
mention about this:
/* Most will argue that x86_64 is always little-endian. Well,
* yes, but then we have stratus.com who has modified gcc to
* "emulate" big-endian on x86. Is there evidence that they
* [or somebody else] won't do same for x86_64? Naturally no.
* And this line is waiting ready for that brave soul:-) */

So, yes, they are on drugs. But they are not alone, the stratus.com people are,
too.

Reliability fix for SHA384 SSL/TLS ciphers on strict alignment
architectures. ok miod@ djm@

Upstream patch:
commit cdd1acd788020d2c525331da1712ada778f1373c
Author: Andy Polyakov <appro@openssl.org>
Date: Wed Dec 18 21:27:35 2013 +0100

branches: 1.1.1;
Initial revision

Demacro SHA-512.

Use static inline functions instead of macros to implement SHA-512. At
the same time, make two key changes - firstly, rather than trying to
outsmart the compiler and shuffle variables around, write the algorithm
the way it is documented and actually swap the variable contents. Secondly,
instead of interleaving the message schedule update and the round, do the
full message schedule update first, then process the round.

Overall, we get safer and more readable code. Additionally, the compiler
can generate smaller and faster code (with a gain of 5-10% across a range
of architectures).

ok beck@ tb@

Clean up alignment handling for SHA-512.

This recommits r1.37 of sha512.c, however uses uint8_t * instead of void *
for the crypto_load_* functions and primarily uses const uint8_t * to track
input, only casting to const SHA_LONG64 * once we know that it is suitably
aligned. This prevents the compiler from implying alignment based on type.

Tested by tb@ and deraadt@ on platforms with gcc and strict alignment.

ok tb@

backout alignment changes (breaking at least two architectures)

Clean up alignment handling for SHA-512.

All assembly implementations are required to perform their own alignment
handling. In the case of the C implementation, on strict alignment
platforms, unaligned data will be copied into an aligned buffer. However,
most platforms then perform byte-by-byte reads (via the PULL64 macros).

Instead, remove SHA512_BLOCK_CAN_MANAGE_UNALIGNED_DATA and alignment
handling to sha512_block_data_order() - if the data is aligned then simply
perform 64 bit loads and then do endian conversion via be64toh(). If the
data is unaligned then use memcpy() and be64toh() (in the form of
crypto_load_be64toh()). Overall this reduces complexity and can improve
performance (on aarch64 we get a ~10% performance gain with aligned input
and about ~1-2% gain on armv7), while the same movq/bswapq is generated
for amd64 and movl/bswapl for i386.

ok tb@

Clean up SHA-512 input handling and round macros.

Avoid reach around and initialisation outside of the macro, cleaning up
the call sites to remove the initialisation. Use a T2 variable to more
closely follow the documented algorithm and remove the gorgeous compound
statement X = Y += A + B + C.

There is no change to the clang generated assembly on aarch64.

ok tb@

Reduce the number of SHA-512 C implementations from three to one.

We currently have three C implementations for SHA-512 - a version that is
optimised for CPUs with minimal registers (specifically i386), a regular
implementation and a semi-unrolled implementation. Testing on a ~15 year
old i386 CPU, the fastest version is actually the semi-unrolled version
(not to mention that we still currently have an i586 assembly
implementation that is used on i386 instead...).

More decent architectures do not seem to care between the regular and
semi-unrolled version, presumably since they are effectively doing the
same thing in hardware during execution.

Remove all except the semi-unrolled version.

ok tb@

Add support for truncated SHA512 variants.

This adds support for SHA512/224 and SHA512/256, as specified in FIPS
FIPS 180-4. These are truncated versions of the SHA512 hash.

ok tb@

Use memset() and only initialise non-zero struct members.

ok tb@

Provide and use crypto_ro{l,r}_u{32,64}().

Various code in libcrypto needs bitwise rotation - rather than defining
different versions across the code base, provide a common set that can
be reused. Any sensible compiler optimises these to a single instruction
where the architecture supports it, which means we can ditch the inline
assembly.

On the chance that we need to provide a platform specific versions, this
follows the approach used in BN where a MD crypto_arch.h header could be
added in the future, which would then provide more specific versions of
these functions.

ok tb@

Provide and use crypto_store_htobe64().

It is common to need to store data in a specific endianness - rather than
handrolling and deduplicating code to do this, provide a
crypto_store_htobe64() function that converts from host endian to big
endian, before storing the data to a location with unknown alignment.

ok tb@

Recommit jsing's r1.27 - portable is ready

Use htobe64() instead of testing BYTE_ORDER and then handrolling htobe64().

Thanks to tobhe for providing most of the fix via openiked-portable

Back out r1.27 using htobe64() - apparently some OS don't have it.

ok jsing

Simplify handling of big vs little endian.

Rather than sprinkling BYTE_ORDER checks throughout the implementation,
always define PULL64 - on big endian platforms it just becomes a no-op.

ok tb@

Use htobe64() instead of testing BYTE_ORDER and then handrolling htobe64().

ok tb@

Omit sha512_block_data_order() prototype when assembly is not being used.

In the case that the pure C implementation of SHA512 is being used, the
prototype is unnecessary as the function is declared static and exists
in dependency order. Simply omit the prototype rather than using #ifndef
to toggle the static prefix.

ok tb@

Remove less than useful implementation notes.

ok tb@

Whitespace fixes.

Mechanically replace "a,b" with "a, b", followed with some manual
indentation clean up.

No change in generated assembly.

Use multiple statements instead of a statement with multiple expressions.

No change in generated assembly.

Reorder functions/code.

No intended functional change.

Tidy includes.

Add license to sha256.c/sha512.c.

Use multiple statements instead of comma separated expressions.

No change to generated assembly.

Add some blank lines for readability, along with some more style(9) tweaks.

Whack sha with a style(9) stick.

No change in generated assembly.

Switch to <endian.h> from <machine/endian.h> for better portability.

ok tb@

Remove I386_ONLY define. It was only used to prefer a
faster-on-genuine-80386-but-slower-on-80486-onwards innstruction sequence in
the SHA512 code, and had not been enabled in years, if at all.

ok tom@ bcook@

Correct spelling of OPENSSL_cleanse.

ok miod@

Only import cryptlib.h in the four source files that actually need it.
Remove the openssl public includes from cryptlib.h and add a small number
of includes into the source files that actually need them. While here,
also sort/group/tidy the includes.

ok beck@ miod@

Explicitly include <openssl/opensslconf.h> in every file that references
an OPENSSL_NO_* define. This avoids relying on something else pulling it
in for us, plus it fixes several cases where the #ifndef OPENSSL_NO_XYZ is
never going to do anything, since OPENSSL_NO_XYZ will never defined, due
to the fact that opensslconf.h has not been included.

This also includes some miscellaneous sorting/tidying of headers.

Remove leading underscore from _BYTE_ORDER and _{LITTLE,BIG}_ENDIAN, to be
more friendly to systems where the underscore flavours may be defined as empty.
Found the hard way be bcook@; joint brainstrom with bcook beck and guenther

remove unused, private version strings except SSL_version_str

Also remove unused des_ver.h, which exports some of these strings, but is not installed.

ok miod@ tedu@

tags as requested by miod and tedu

Get __STRICT_ALIGNMENT from <machine/endian.h> and decide upon it, rather
than defining it for not (i386 and amd64 (and sometimes s390)) only.

Compile-time tests remain compile-time tests, and runtime-test remain
runtime-test instead of being converted to compile-time tests, per matthew@'s
explicit demand (rationale: this makes sure the compiler checks your code even
if you won't run it).

No functional change except on s390 (which we don't run on) and vax (which we
run on, but noone cares about)

ok matthew@

Remove fips_md_init() macro indirection for digest algorithms, used by the
OpenSSL FIPS module to prevent forbidden digests to be allowed.
No functional change but readability.

ok deraadt@

Unifdef -UPEDANTIC. ok beck@ tedu@

Do not ask the user to pass either -DB_ENDIAN or -DL_ENDIAN to the compiler,
but rather figure out the endianness from <machine/endian.h> automagically;
help from guenther@

ok jca@ guenther@ beck@ and the rest of the `Buena SSL rampage club'

Get rid of MS Visual C compiler and Intel C compiler specific defines.

Remove support for big-endian i386 and amd64.

Before someone suggests the OpenSSL people are junkies, here is what they
mention about this:
/* Most will argue that x86_64 is always little-endian. Well,
* yes, but then we have stratus.com who has modified gcc to
* "emulate" big-endian on x86. Is there evidence that they
* [or somebody else] won't do same for x86_64? Naturally no.
* And this line is waiting ready for that brave soul:-) */

So, yes, they are on drugs. But they are not alone, the stratus.com people are,
too.

Reliability fix for SHA384 SSL/TLS ciphers on strict alignment
architectures. ok miod@ djm@

Upstream patch:
commit cdd1acd788020d2c525331da1712ada778f1373c
Author: Andy Polyakov <appro@openssl.org>
Date: Wed Dec 18 21:27:35 2013 +0100

branches: 1.1.1;
Initial revision

Clean up alignment handling for SHA-512.

This recommits r1.37 of sha512.c, however uses uint8_t * instead of void *
for the crypto_load_* functions and primarily uses const uint8_t * to track
input, only casting to const SHA_LONG64 * once we know that it is suitably
aligned. This prevents the compiler from implying alignment based on type.

Tested by tb@ and deraadt@ on platforms with gcc and strict alignment.

ok tb@

backout alignment changes (breaking at least two architectures)

Clean up alignment handling for SHA-512.

All assembly implementations are required to perform their own alignment
handling. In the case of the C implementation, on strict alignment
platforms, unaligned data will be copied into an aligned buffer. However,
most platforms then perform byte-by-byte reads (via the PULL64 macros).

Instead, remove SHA512_BLOCK_CAN_MANAGE_UNALIGNED_DATA and alignment
handling to sha512_block_data_order() - if the data is aligned then simply
perform 64 bit loads and then do endian conversion via be64toh(). If the
data is unaligned then use memcpy() and be64toh() (in the form of
crypto_load_be64toh()). Overall this reduces complexity and can improve
performance (on aarch64 we get a ~10% performance gain with aligned input
and about ~1-2% gain on armv7), while the same movq/bswapq is generated
for amd64 and movl/bswapl for i386.

ok tb@

Clean up SHA-512 input handling and round macros.

Avoid reach around and initialisation outside of the macro, cleaning up
the call sites to remove the initialisation. Use a T2 variable to more
closely follow the documented algorithm and remove the gorgeous compound
statement X = Y += A + B + C.

There is no change to the clang generated assembly on aarch64.

ok tb@

Reduce the number of SHA-512 C implementations from three to one.

We currently have three C implementations for SHA-512 - a version that is
optimised for CPUs with minimal registers (specifically i386), a regular
implementation and a semi-unrolled implementation. Testing on a ~15 year
old i386 CPU, the fastest version is actually the semi-unrolled version
(not to mention that we still currently have an i586 assembly
implementation that is used on i386 instead...).

More decent architectures do not seem to care between the regular and
semi-unrolled version, presumably since they are effectively doing the
same thing in hardware during execution.

Remove all except the semi-unrolled version.

ok tb@

Add support for truncated SHA512 variants.

This adds support for SHA512/224 and SHA512/256, as specified in FIPS
FIPS 180-4. These are truncated versions of the SHA512 hash.

ok tb@

Use memset() and only initialise non-zero struct members.

ok tb@

Provide and use crypto_ro{l,r}_u{32,64}().

Various code in libcrypto needs bitwise rotation - rather than defining
different versions across the code base, provide a common set that can
be reused. Any sensible compiler optimises these to a single instruction
where the architecture supports it, which means we can ditch the inline
assembly.

On the chance that we need to provide a platform specific versions, this
follows the approach used in BN where a MD crypto_arch.h header could be
added in the future, which would then provide more specific versions of
these functions.

ok tb@

Provide and use crypto_store_htobe64().

It is common to need to store data in a specific endianness - rather than
handrolling and deduplicating code to do this, provide a
crypto_store_htobe64() function that converts from host endian to big
endian, before storing the data to a location with unknown alignment.

ok tb@

Recommit jsing's r1.27 - portable is ready

Use htobe64() instead of testing BYTE_ORDER and then handrolling htobe64().

Thanks to tobhe for providing most of the fix via openiked-portable

Back out r1.27 using htobe64() - apparently some OS don't have it.

ok jsing

Simplify handling of big vs little endian.

Rather than sprinkling BYTE_ORDER checks throughout the implementation,
always define PULL64 - on big endian platforms it just becomes a no-op.

ok tb@

Use htobe64() instead of testing BYTE_ORDER and then handrolling htobe64().

ok tb@

Omit sha512_block_data_order() prototype when assembly is not being used.

In the case that the pure C implementation of SHA512 is being used, the
prototype is unnecessary as the function is declared static and exists
in dependency order. Simply omit the prototype rather than using #ifndef
to toggle the static prefix.

ok tb@

Remove less than useful implementation notes.

ok tb@

Whitespace fixes.

Mechanically replace "a,b" with "a, b", followed with some manual
indentation clean up.

No change in generated assembly.

Use multiple statements instead of a statement with multiple expressions.

No change in generated assembly.

Reorder functions/code.

No intended functional change.

Tidy includes.

Add license to sha256.c/sha512.c.

Use multiple statements instead of comma separated expressions.

No change to generated assembly.

Add some blank lines for readability, along with some more style(9) tweaks.

Whack sha with a style(9) stick.

No change in generated assembly.

Switch to <endian.h> from <machine/endian.h> for better portability.

ok tb@

Remove I386_ONLY define. It was only used to prefer a
faster-on-genuine-80386-but-slower-on-80486-onwards innstruction sequence in
the SHA512 code, and had not been enabled in years, if at all.

ok tom@ bcook@

Correct spelling of OPENSSL_cleanse.

ok miod@

Only import cryptlib.h in the four source files that actually need it.
Remove the openssl public includes from cryptlib.h and add a small number
of includes into the source files that actually need them. While here,
also sort/group/tidy the includes.

ok beck@ miod@

Explicitly include <openssl/opensslconf.h> in every file that references
an OPENSSL_NO_* define. This avoids relying on something else pulling it
in for us, plus it fixes several cases where the #ifndef OPENSSL_NO_XYZ is
never going to do anything, since OPENSSL_NO_XYZ will never defined, due
to the fact that opensslconf.h has not been included.

This also includes some miscellaneous sorting/tidying of headers.

Remove leading underscore from _BYTE_ORDER and _{LITTLE,BIG}_ENDIAN, to be
more friendly to systems where the underscore flavours may be defined as empty.
Found the hard way be bcook@; joint brainstrom with bcook beck and guenther

remove unused, private version strings except SSL_version_str

Also remove unused des_ver.h, which exports some of these strings, but is not installed.

ok miod@ tedu@

tags as requested by miod and tedu

Get __STRICT_ALIGNMENT from <machine/endian.h> and decide upon it, rather
than defining it for not (i386 and amd64 (and sometimes s390)) only.

Compile-time tests remain compile-time tests, and runtime-test remain
runtime-test instead of being converted to compile-time tests, per matthew@'s
explicit demand (rationale: this makes sure the compiler checks your code even
if you won't run it).

No functional change except on s390 (which we don't run on) and vax (which we
run on, but noone cares about)

ok matthew@

Remove fips_md_init() macro indirection for digest algorithms, used by the
OpenSSL FIPS module to prevent forbidden digests to be allowed.
No functional change but readability.

ok deraadt@

Unifdef -UPEDANTIC. ok beck@ tedu@

Do not ask the user to pass either -DB_ENDIAN or -DL_ENDIAN to the compiler,
but rather figure out the endianness from <machine/endian.h> automagically;
help from guenther@

ok jca@ guenther@ beck@ and the rest of the `Buena SSL rampage club'

Get rid of MS Visual C compiler and Intel C compiler specific defines.

Remove support for big-endian i386 and amd64.

Before someone suggests the OpenSSL people are junkies, here is what they
mention about this:
/* Most will argue that x86_64 is always little-endian. Well,
* yes, but then we have stratus.com who has modified gcc to
* "emulate" big-endian on x86. Is there evidence that they
* [or somebody else] won't do same for x86_64? Naturally no.
* And this line is waiting ready for that brave soul:-) */

So, yes, they are on drugs. But they are not alone, the stratus.com people are,
too.

Reliability fix for SHA384 SSL/TLS ciphers on strict alignment
architectures. ok miod@ djm@

Upstream patch:
commit cdd1acd788020d2c525331da1712ada778f1373c
Author: Andy Polyakov <appro@openssl.org>
Date: Wed Dec 18 21:27:35 2013 +0100

branches: 1.1.1;
Initial revision

Add support for truncated SHA512 variants.

This adds support for SHA512/224 and SHA512/256, as specified in FIPS
FIPS 180-4. These are truncated versions of the SHA512 hash.

ok tb@

Use memset() and only initialise non-zero struct members.

ok tb@

Provide and use crypto_ro{l,r}_u{32,64}().

Various code in libcrypto needs bitwise rotation - rather than defining
different versions across the code base, provide a common set that can
be reused. Any sensible compiler optimises these to a single instruction
where the architecture supports it, which means we can ditch the inline
assembly.

On the chance that we need to provide a platform specific versions, this
follows the approach used in BN where a MD crypto_arch.h header could be
added in the future, which would then provide more specific versions of
these functions.

ok tb@

Provide and use crypto_store_htobe64().

It is common to need to store data in a specific endianness - rather than
handrolling and deduplicating code to do this, provide a
crypto_store_htobe64() function that converts from host endian to big
endian, before storing the data to a location with unknown alignment.

ok tb@

Recommit jsing's r1.27 - portable is ready

Use htobe64() instead of testing BYTE_ORDER and then handrolling htobe64().

Thanks to tobhe for providing most of the fix via openiked-portable

Back out r1.27 using htobe64() - apparently some OS don't have it.

ok jsing

Simplify handling of big vs little endian.

Rather than sprinkling BYTE_ORDER checks throughout the implementation,
always define PULL64 - on big endian platforms it just becomes a no-op.

ok tb@

Use htobe64() instead of testing BYTE_ORDER and then handrolling htobe64().

ok tb@

Omit sha512_block_data_order() prototype when assembly is not being used.

In the case that the pure C implementation of SHA512 is being used, the
prototype is unnecessary as the function is declared static and exists
in dependency order. Simply omit the prototype rather than using #ifndef
to toggle the static prefix.

ok tb@

Remove less than useful implementation notes.

ok tb@

Whitespace fixes.

Mechanically replace "a,b" with "a, b", followed with some manual
indentation clean up.

No change in generated assembly.

Use multiple statements instead of a statement with multiple expressions.

No change in generated assembly.

Reorder functions/code.

No intended functional change.

Tidy includes.

Add license to sha256.c/sha512.c.

Use multiple statements instead of comma separated expressions.

No change to generated assembly.

Add some blank lines for readability, along with some more style(9) tweaks.

Whack sha with a style(9) stick.

No change in generated assembly.

Switch to <endian.h> from <machine/endian.h> for better portability.

ok tb@

Remove I386_ONLY define. It was only used to prefer a
faster-on-genuine-80386-but-slower-on-80486-onwards innstruction sequence in
the SHA512 code, and had not been enabled in years, if at all.

ok tom@ bcook@

Correct spelling of OPENSSL_cleanse.

ok miod@

Only import cryptlib.h in the four source files that actually need it.
Remove the openssl public includes from cryptlib.h and add a small number
of includes into the source files that actually need them. While here,
also sort/group/tidy the includes.

ok beck@ miod@

Explicitly include <openssl/opensslconf.h> in every file that references
an OPENSSL_NO_* define. This avoids relying on something else pulling it
in for us, plus it fixes several cases where the #ifndef OPENSSL_NO_XYZ is
never going to do anything, since OPENSSL_NO_XYZ will never defined, due
to the fact that opensslconf.h has not been included.

This also includes some miscellaneous sorting/tidying of headers.

Remove leading underscore from _BYTE_ORDER and _{LITTLE,BIG}_ENDIAN, to be
more friendly to systems where the underscore flavours may be defined as empty.
Found the hard way be bcook@; joint brainstrom with bcook beck and guenther

remove unused, private version strings except SSL_version_str

Also remove unused des_ver.h, which exports some of these strings, but is not installed.

ok miod@ tedu@

tags as requested by miod and tedu

Get __STRICT_ALIGNMENT from <machine/endian.h> and decide upon it, rather
than defining it for not (i386 and amd64 (and sometimes s390)) only.

Compile-time tests remain compile-time tests, and runtime-test remain
runtime-test instead of being converted to compile-time tests, per matthew@'s
explicit demand (rationale: this makes sure the compiler checks your code even
if you won't run it).

No functional change except on s390 (which we don't run on) and vax (which we
run on, but noone cares about)

ok matthew@

Remove fips_md_init() macro indirection for digest algorithms, used by the
OpenSSL FIPS module to prevent forbidden digests to be allowed.
No functional change but readability.

ok deraadt@

Unifdef -UPEDANTIC. ok beck@ tedu@

Do not ask the user to pass either -DB_ENDIAN or -DL_ENDIAN to the compiler,
but rather figure out the endianness from <machine/endian.h> automagically;
help from guenther@

ok jca@ guenther@ beck@ and the rest of the `Buena SSL rampage club'

Get rid of MS Visual C compiler and Intel C compiler specific defines.

Remove support for big-endian i386 and amd64.

Before someone suggests the OpenSSL people are junkies, here is what they
mention about this:
/* Most will argue that x86_64 is always little-endian. Well,
* yes, but then we have stratus.com who has modified gcc to
* "emulate" big-endian on x86. Is there evidence that they
* [or somebody else] won't do same for x86_64? Naturally no.
* And this line is waiting ready for that brave soul:-) */

So, yes, they are on drugs. But they are not alone, the stratus.com people are,
too.

Reliability fix for SHA384 SSL/TLS ciphers on strict alignment
architectures. ok miod@ djm@

Upstream patch:
commit cdd1acd788020d2c525331da1712ada778f1373c
Author: Andy Polyakov <appro@openssl.org>
Date: Wed Dec 18 21:27:35 2013 +0100

branches: 1.1.1;
Initial revision

Switch to <endian.h> from <machine/endian.h> for better portability.

ok tb@

Remove I386_ONLY define. It was only used to prefer a
faster-on-genuine-80386-but-slower-on-80486-onwards innstruction sequence in
the SHA512 code, and had not been enabled in years, if at all.

ok tom@ bcook@

Correct spelling of OPENSSL_cleanse.

ok miod@

Only import cryptlib.h in the four source files that actually need it.
Remove the openssl public includes from cryptlib.h and add a small number
of includes into the source files that actually need them. While here,
also sort/group/tidy the includes.

ok beck@ miod@

Explicitly include <openssl/opensslconf.h> in every file that references
an OPENSSL_NO_* define. This avoids relying on something else pulling it
in for us, plus it fixes several cases where the #ifndef OPENSSL_NO_XYZ is
never going to do anything, since OPENSSL_NO_XYZ will never defined, due
to the fact that opensslconf.h has not been included.

This also includes some miscellaneous sorting/tidying of headers.

Remove leading underscore from _BYTE_ORDER and _{LITTLE,BIG}_ENDIAN, to be
more friendly to systems where the underscore flavours may be defined as empty.
Found the hard way be bcook@; joint brainstrom with bcook beck and guenther

remove unused, private version strings except SSL_version_str

Also remove unused des_ver.h, which exports some of these strings, but is not installed.

ok miod@ tedu@

tags as requested by miod and tedu

Get __STRICT_ALIGNMENT from <machine/endian.h> and decide upon it, rather
than defining it for not (i386 and amd64 (and sometimes s390)) only.

Compile-time tests remain compile-time tests, and runtime-test remain
runtime-test instead of being converted to compile-time tests, per matthew@'s
explicit demand (rationale: this makes sure the compiler checks your code even
if you won't run it).

No functional change except on s390 (which we don't run on) and vax (which we
run on, but noone cares about)

ok matthew@

Remove fips_md_init() macro indirection for digest algorithms, used by the
OpenSSL FIPS module to prevent forbidden digests to be allowed.
No functional change but readability.

ok deraadt@

Unifdef -UPEDANTIC. ok beck@ tedu@

Do not ask the user to pass either -DB_ENDIAN or -DL_ENDIAN to the compiler,
but rather figure out the endianness from <machine/endian.h> automagically;
help from guenther@

ok jca@ guenther@ beck@ and the rest of the `Buena SSL rampage club'

Get rid of MS Visual C compiler and Intel C compiler specific defines.

Remove support for big-endian i386 and amd64.

Before someone suggests the OpenSSL people are junkies, here is what they
mention about this:
/* Most will argue that x86_64 is always little-endian. Well,
* yes, but then we have stratus.com who has modified gcc to
* "emulate" big-endian on x86. Is there evidence that they
* [or somebody else] won't do same for x86_64? Naturally no.
* And this line is waiting ready for that brave soul:-) */

So, yes, they are on drugs. But they are not alone, the stratus.com people are,
too.

Reliability fix for SHA384 SSL/TLS ciphers on strict alignment
architectures. ok miod@ djm@

Upstream patch:
commit cdd1acd788020d2c525331da1712ada778f1373c
Author: Andy Polyakov <appro@openssl.org>
Date: Wed Dec 18 21:27:35 2013 +0100

branches: 1.1.1;
Initial revision

Remove I386_ONLY define. It was only used to prefer a
faster-on-genuine-80386-but-slower-on-80486-onwards innstruction sequence in
the SHA512 code, and had not been enabled in years, if at all.

ok tom@ bcook@

Correct spelling of OPENSSL_cleanse.

ok miod@

Only import cryptlib.h in the four source files that actually need it.
Remove the openssl public includes from cryptlib.h and add a small number
of includes into the source files that actually need them. While here,
also sort/group/tidy the includes.

ok beck@ miod@

Explicitly include <openssl/opensslconf.h> in every file that references
an OPENSSL_NO_* define. This avoids relying on something else pulling it
in for us, plus it fixes several cases where the #ifndef OPENSSL_NO_XYZ is
never going to do anything, since OPENSSL_NO_XYZ will never defined, due
to the fact that opensslconf.h has not been included.

This also includes some miscellaneous sorting/tidying of headers.

Remove leading underscore from _BYTE_ORDER and _{LITTLE,BIG}_ENDIAN, to be
more friendly to systems where the underscore flavours may be defined as empty.
Found the hard way be bcook@; joint brainstrom with bcook beck and guenther

remove unused, private version strings except SSL_version_str

Also remove unused des_ver.h, which exports some of these strings, but is not installed.

ok miod@ tedu@

tags as requested by miod and tedu

Get __STRICT_ALIGNMENT from <machine/endian.h> and decide upon it, rather
than defining it for not (i386 and amd64 (and sometimes s390)) only.

Compile-time tests remain compile-time tests, and runtime-test remain
runtime-test instead of being converted to compile-time tests, per matthew@'s
explicit demand (rationale: this makes sure the compiler checks your code even
if you won't run it).

No functional change except on s390 (which we don't run on) and vax (which we
run on, but noone cares about)

ok matthew@

Remove fips_md_init() macro indirection for digest algorithms, used by the
OpenSSL FIPS module to prevent forbidden digests to be allowed.
No functional change but readability.

ok deraadt@

Unifdef -UPEDANTIC. ok beck@ tedu@

Do not ask the user to pass either -DB_ENDIAN or -DL_ENDIAN to the compiler,
but rather figure out the endianness from <machine/endian.h> automagically;
help from guenther@

ok jca@ guenther@ beck@ and the rest of the `Buena SSL rampage club'

Get rid of MS Visual C compiler and Intel C compiler specific defines.

Remove support for big-endian i386 and amd64.

Before someone suggests the OpenSSL people are junkies, here is what they
mention about this:
/* Most will argue that x86_64 is always little-endian. Well,
* yes, but then we have stratus.com who has modified gcc to
* "emulate" big-endian on x86. Is there evidence that they
* [or somebody else] won't do same for x86_64? Naturally no.
* And this line is waiting ready for that brave soul:-) */

So, yes, they are on drugs. But they are not alone, the stratus.com people are,
too.

Reliability fix for SHA384 SSL/TLS ciphers on strict alignment
architectures. ok miod@ djm@

Upstream patch:
commit cdd1acd788020d2c525331da1712ada778f1373c
Author: Andy Polyakov <appro@openssl.org>
Date: Wed Dec 18 21:27:35 2013 +0100

branches: 1.1.1;
Initial revision