Skip to content

secp256k1: Direct byte clears. - #3750

Open
davecgh wants to merge 1 commit into
decred:masterfrom
davecgh:secp256k1_direct_byte_clears
Open

secp256k1: Direct byte clears.#3750
davecgh wants to merge 1 commit into
decred:masterfrom
davecgh:secp256k1_direct_byte_clears

Conversation

@davecgh

@davecgh davecgh commented Jul 26, 2026

Copy link
Copy Markdown
Member

The current implementation either clears fixed-size buffers by copying a zeroed array over them, looping over each entry and setting it zero, or manually setting each entry to 0. All of these approaches work as intended, but a cleaner and more efficent approach is to simply set it equal to the zero value of an array of the appropriate size.

This package requires a minimum of Go 1.17 and so all supported versions of the Go compiler recognize this pattern and compile it to efficient memory-clearing instructions.

While Go does not guarantee constant time operations, inspection of the generated code for supported architectures shows this produces a fixed sequence of stores as desired.

Moreover, this approach avoids relying on runtime.memmove, which makes the generated code simpler and easier to reason about with respect to timing behavior.

@davecgh davecgh added this to the 2.2.0 milestone Jul 26, 2026

@jholdstock jholdstock left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you deliberately leave ModNScalar.Zero() as it was?

The current implementation either clears fixed-size buffers by copying a
zeroed array over them, looping over each entry and setting it zero, or
manually setting each entry to 0.  All of these approaches work as
intended, but a cleaner and more efficent approach is to simply set it
equal to the zero value of an array of the appropriate size.

This package requires a minimum of Go 1.17 and so all supported versions
of the Go compiler recognize this pattern and compile it to efficient
memory-clearing instructions.

While Go does not guarantee constant time operations, inspection of the
generated code for supported architectures shows this produces a fixed
sequence of stores as desired.

Moreover, this approach avoids relying on runtime.memmove, which makes
the generated code simpler and easier to reason about with respect to
timing behavior.
@davecgh
davecgh force-pushed the secp256k1_direct_byte_clears branch from 7c6e5fe to c361c8f Compare July 27, 2026 06:23
@davecgh

davecgh commented Jul 27, 2026

Copy link
Copy Markdown
Member Author

Did you deliberately leave ModNScalar.Zero() as it was?

Well, I actually missed that because I did the work already on top of #3731 and then ended up rebasing it for easier review, but I guess that's also why it doesn't really matter. It's entirely replaced by the 4x64 implementation there which uses the same technique.

Nevertheless, that's a good catch and I went ahead and updated it though for completeness in the mean time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants