-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Make SHA256 compression pluggable #1777
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -134,6 +134,12 @@ SECP_TRY_APPEND_DEFAULT_CFLAGS(SECP_CFLAGS) | |
| ### Define config arguments | ||
| ### | ||
|
|
||
| AC_ARG_WITH([external-sha256], | ||
| AS_HELP_STRING([--with-external-sha256=PATH], [use external SHA256 compression implementation]), | ||
| [external_sha256_path="$withval"], | ||
| [external_sha256_path=""] | ||
| ) | ||
|
Comment on lines
+137
to
+141
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Regarding the build stuff for the build-time override: We already have the possibility to have build-time overrides for the error callbacks, e.g., see When it comes to the implementation of how the new override is configured and performed, I think it's similar to the existing overrides for the callback. (Except that these don't allow configuring the header to be included, which makes them rather useless... #1461) So this will need a rework anyway [1]. This belongs to a different PR, of course, but I think the SHA override here is a good opportunity to think about a better design of a compile-time override, so we may want to iterate on this a bit more than expected. No matter how it's designed, I think we should, in the long run, have only one (non-deprecated) mechanism for a build-time override of a function. [1] I don't think what I did for the error callbacks great, and I guess it would be okay to change it (I doubt that many users rely on this). Or even better, we could deprecate it and simply provide ways to provide build-time overrides for standard library symbols like |
||
|
|
||
| # In dev mode, we enable all binaries and modules by default but individual options can still be overridden explicitly. | ||
| # Check for dev mode first because SECP_SET_DEFAULT needs enable_dev_mode set. | ||
| AC_ARG_ENABLE(dev_mode, [], [], | ||
|
|
@@ -397,6 +403,12 @@ SECP_CFLAGS="$SECP_CFLAGS $WERROR_CFLAGS" | |
|
|
||
| # Processing must be done in a reverse topological sorting of the dependency graph | ||
| # (dependent module first). | ||
|
|
||
| if test "x$external_sha256_path" != "x"; then | ||
| SECP_CONFIG_DEFINES="$SECP_CONFIG_DEFINES -DSECP256K1_EXTERNAL_SHA256=1" | ||
| SECP_CONFIG_DEFINES="$SECP_CONFIG_DEFINES -DSECP256K1_EXTERNAL_SHA256_HEADER='\"$external_sha256_path\"'" | ||
| fi | ||
|
|
||
| if test x"$enable_module_ellswift" = x"yes"; then | ||
| SECP_CONFIG_DEFINES="$SECP_CONFIG_DEFINES -DENABLE_MODULE_ELLSWIFT=1" | ||
| fi | ||
|
|
@@ -470,6 +482,7 @@ AM_CONDITIONAL([ENABLE_MODULE_EXTRAKEYS], [test x"$enable_module_extrakeys" = x" | |
| AM_CONDITIONAL([ENABLE_MODULE_SCHNORRSIG], [test x"$enable_module_schnorrsig" = x"yes"]) | ||
| AM_CONDITIONAL([ENABLE_MODULE_MUSIG], [test x"$enable_module_musig" = x"yes"]) | ||
| AM_CONDITIONAL([ENABLE_MODULE_ELLSWIFT], [test x"$enable_module_ellswift" = x"yes"]) | ||
| AM_CONDITIONAL([SECP256K1_EXTERNAL_SHA256], [test "x$SHA256_EXTERNAL_SRC" != "x"]) | ||
| AM_CONDITIONAL([USE_EXTERNAL_ASM], [test x"$enable_external_asm" = x"yes"]) | ||
| AM_CONDITIONAL([USE_ASM_ARM], [test x"$set_asm" = x"arm32"]) | ||
| AM_CONDITIONAL([BUILD_WINDOWS], [test "$build_windows" = "yes"]) | ||
|
|
@@ -494,6 +507,7 @@ echo " module extrakeys = $enable_module_extrakeys" | |
| echo " module schnorrsig = $enable_module_schnorrsig" | ||
| echo " module musig = $enable_module_musig" | ||
| echo " module ellswift = $enable_module_ellswift" | ||
| echo " external sha256 = ${external_sha256_path:-none}" | ||
| echo | ||
| echo " asm = $set_asm" | ||
| echo " ecmult window size = $set_ecmult_window" | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -6,6 +6,7 @@ extern "C" { | |
| #endif | ||
|
|
||
| #include <stddef.h> | ||
| #include <stdint.h> | ||
|
|
||
| /** Unless explicitly stated all pointer arguments must not be NULL. | ||
| * | ||
|
|
@@ -92,6 +93,7 @@ typedef struct secp256k1_ecdsa_signature { | |
| * the message, the algorithm, the key and the attempt. | ||
| */ | ||
| typedef int (*secp256k1_nonce_function)( | ||
| const secp256k1_context *ctx, | ||
|
Comment on lines
95
to
+96
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Argh, that's a breaking change. I didn't see that coming. But I think it can be avoided. If the user wants to pass a custom nonce function, they anyway have no way of calling our internal function (whether it uses a custom SHA256 transform or not). So we can keep the struct here and add the context arg only to our built-in nonce function. Our ECDSA signing function (and Schnorr signing, and ECDH, etc.) will need to special-case the built-in nonce function because it has a different function signature. Not elegant but it will do the job.
|
||
| unsigned char *nonce32, | ||
| const unsigned char *msg32, | ||
| const unsigned char *key32, | ||
|
|
@@ -403,6 +405,29 @@ SECP256K1_API void secp256k1_context_set_error_callback( | |
| const void *data | ||
| ) SECP256K1_ARG_NONNULL(1); | ||
|
|
||
| /** | ||
| * Set a callback function to override the internal SHA-256 transform. | ||
| * | ||
| * This installs a function to replace the built-in block-compression | ||
| * step used by the library's internal SHA-256 implementation. | ||
| * The provided callback must be functionally identical (bit-for-bit) | ||
| * to the default transform. Any deviation will cause incorrect results | ||
| * and undefined behaviour. | ||
| * | ||
| * This API exists to support environments that wish to route the | ||
| * SHA-256 compression step through a hardware-accelerated or otherwise | ||
| * specialized implementation. It is not meant for modifying the | ||
| * semantics of SHA-256. | ||
| * | ||
| * Args: ctx: pointer to a context object. | ||
| * In: callback: pointer to a function implementing the transform step. | ||
| * (passing NULL restores the default implementation) | ||
| */ | ||
| SECP256K1_API void secp256k1_context_set_sha256_transform_callback( | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Naming: I wonder whether it makes sense to avoid the word callback here. Sure, it's a callback, but whenever we said callback in the past 10 years of this library, it was about error handling. We even have type Maybe we can just call it "function " and "function pointer", like we do in the bring-your-own-nonce-function interfaces. |
||
| secp256k1_context *ctx, | ||
| void (*sha256_transform_callback)(uint32_t *state, const unsigned char *block, size_t rounds) | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I was wondering whether it makes sense to allow for a real return value here to make it possible for the callback to indicate some kind of failure (e.g., couldn't access external hardware, or malloc failed). We could then fall back to our implementation or simply call the error callback in order to crash. My current conclusion is no: I can't imagine this being useful in practice. (If you call external hardware, this will be super slow anyway. If you use malloc for SHA256, you're doing it wrong.) Even if there's some failure, the callback will still have the possibility to crash the process.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What's the motivation for the rounds arg? (Do you think we'll ever call this with any other value than 1?) |
||
| ) SECP256K1_ARG_NONNULL(1); | ||
|
|
||
| /** Parse a variable-length public key into the pubkey object. | ||
| * | ||
| * Returns: 1 if the public key was fully valid. | ||
|
|
||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What's the motivation for exposing the SHA256 compression? Unless I'm missing something, then if anything, I think we'd want to expose the high-level SHA256 function. I'm not sure how useful it is, and we tried to keep the library focused on ECC. On the other hand, we'll have it anyway in the code base, and it's required for Schnorr sigs (and we anyway expose a tagged hash for Schnorr sigs). So if you ask me, it's fine to expose SHA256 as long as we add a comment that says that users shouldn't expect a highly performant implementation. But perhaps it's better to debate the exposing in a separate PR. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,39 @@ | ||
| #ifndef SECP256K1_SHA_H | ||
| #define SECP256K1_SHA_H | ||
|
|
||
| #include "secp256k1.h" | ||
|
|
||
| #include <stdint.h> | ||
|
|
||
| #ifdef __cplusplus | ||
| extern "C" { | ||
| #endif | ||
|
|
||
| /** | ||
| * SHA-256 block compression function. | ||
| * | ||
| * Performs the SHA-256 transform step on a single 64-byte message block, | ||
| * updating the 8-word `state` in place. This is the raw block-level primitive: | ||
| * no padding, no message scheduling across blocks, and no length encoding. | ||
| * Only the compression function is applied. | ||
| * | ||
| * If `rounds` is greater than 1, the same 64-byte block is re-compressed | ||
| * repeatedly onto the updated state. | ||
| * | ||
| * The caller must supply a fully-formed, 64-byte, block-aligned message block. | ||
| * | ||
| * @param state Current hash state (8 x 32-bit words), updated in place. | ||
| * @param block Pointer to a 64-byte message block. | ||
| * @param rounds Number of times to apply the compression to this block. | ||
| */ | ||
| SECP256K1_API void secp256k1_sha256_transform( | ||
| uint32_t *state, | ||
| const unsigned char *block, | ||
| size_t rounds | ||
| ) SECP256K1_ARG_NONNULL(1) SECP256K1_ARG_NONNULL(2); | ||
|
|
||
| #ifdef __cplusplus | ||
| } | ||
| #endif | ||
|
|
||
| #endif /* SECP256K1_SHA_H */ |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -10,13 +10,20 @@ | |
| #include <stdlib.h> | ||
| #include <stdint.h> | ||
|
|
||
| typedef void (*sha256_transform_callback)(uint32_t *state, const unsigned char *block, size_t rounds); | ||
|
|
||
| /* Validate user-supplied SHA-256 transform by comparing its output against | ||
| * the library's linked implementation */ | ||
| static int secp256k1_sha256_check_transform(sha256_transform_callback fn_transform); | ||
|
Comment on lines
+15
to
+17
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we need this function given that there's already (The existing selftest is currently in edit: Okay, I see now. It's annoying than I thought. We expose So I believe it makes sense to check the SHA256 at two places:
This means we may perform two checks in the worst case, but that won't be the end of the world. You get the overhead only at library initialization time. But the question remains: How should the test look like? And I still think what I said above is true: It's okay to have a single |
||
|
|
||
| typedef struct { | ||
| uint32_t s[8]; | ||
| unsigned char buf[64]; | ||
| uint64_t bytes; | ||
| sha256_transform_callback fn_transform; | ||
| } secp256k1_sha256; | ||
|
|
||
| static void secp256k1_sha256_initialize(secp256k1_sha256 *hash); | ||
| static void secp256k1_sha256_initialize(secp256k1_sha256 *hash, sha256_transform_callback fn_transform); | ||
| static void secp256k1_sha256_write(secp256k1_sha256 *hash, const unsigned char *data, size_t size); | ||
| static void secp256k1_sha256_finalize(secp256k1_sha256 *hash, unsigned char *out32); | ||
|
Comment on lines
-19
to
28
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A potential problem with storing the callback in the
(I believe) this cannot happen in the current code because there's no pair of API functions that behaves in this way, but it's a potential footgun for the future. My suggestion is just passing the context object to every internal function that needs the SHA256 callback. (Another angle: State is annoying. We have state already in the context, so let's try to keep it there.) |
||
| static void secp256k1_sha256_clear(secp256k1_sha256 *hash); | ||
|
|
@@ -25,7 +32,7 @@ typedef struct { | |
| secp256k1_sha256 inner, outer; | ||
| } secp256k1_hmac_sha256; | ||
|
|
||
| static void secp256k1_hmac_sha256_initialize(secp256k1_hmac_sha256 *hash, const unsigned char *key, size_t size); | ||
| static void secp256k1_hmac_sha256_initialize(secp256k1_hmac_sha256 *hash, const unsigned char *key, size_t size, sha256_transform_callback fn_sha256_transform); | ||
| static void secp256k1_hmac_sha256_write(secp256k1_hmac_sha256 *hash, const unsigned char *data, size_t size); | ||
| static void secp256k1_hmac_sha256_finalize(secp256k1_hmac_sha256 *hash, unsigned char *out32); | ||
| static void secp256k1_hmac_sha256_clear(secp256k1_hmac_sha256 *hash); | ||
|
|
@@ -36,8 +43,8 @@ typedef struct { | |
| int retry; | ||
| } secp256k1_rfc6979_hmac_sha256; | ||
|
|
||
| static void secp256k1_rfc6979_hmac_sha256_initialize(secp256k1_rfc6979_hmac_sha256 *rng, const unsigned char *key, size_t keylen); | ||
| static void secp256k1_rfc6979_hmac_sha256_generate(secp256k1_rfc6979_hmac_sha256 *rng, unsigned char *out, size_t outlen); | ||
| static void secp256k1_rfc6979_hmac_sha256_initialize(secp256k1_rfc6979_hmac_sha256 *rng, const unsigned char *key, size_t keylen, sha256_transform_callback fn_sha256_transform); | ||
| static void secp256k1_rfc6979_hmac_sha256_generate(secp256k1_rfc6979_hmac_sha256 *rng, unsigned char *out, size_t outlen, sha256_transform_callback fn_sha256_transform); | ||
| static void secp256k1_rfc6979_hmac_sha256_finalize(secp256k1_rfc6979_hmac_sha256 *rng); | ||
| static void secp256k1_rfc6979_hmac_sha256_clear(secp256k1_rfc6979_hmac_sha256 *rng); | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I think this one should also be an
enable-style configure option instead of awith-style configure options;withis for compiling with external packages e.g.,with-libxyz. And what the user provides here is not a package.