1ca55ac77d chacha20_poly1305: inline simd functions (Nick Johnson)
30920c4d84 chacha20_poly1305: drop mutable requirement (Nick Johnson)
415945cd2b chacha20_poly1305: avoid duplicate block work (Nick Johnson)
33dc1b95fa chacha20_poly1305: swap tuple for array (Nick Johnson)
dadd1d7224 chacha20_poly1305: remove alignment (Nick Johnson)
36d45bf360 chacha20_poly1305: remove mod operator (Nick Johnson)
Pull request description:
Inspired by JeremiahR's new benchmark on the chacha20 module, I dug in and found a few tweaks (and a larger refactor) which help a lot with performance.
The tweaks are broken down by commit. One of the relatively fruitful ones (5% increase) was refactoring the U32x4's rotation methods to use hardcoded matches instead of the mod operator. Others saw more modest performance gains.
The big change though was to *not* calculate two blocks for each keystream call (oops). I refactored the logic to handle the offset state (which is technically not required for BIP324, but as seen here, can be confusing to not have) and now we always calculate just the required amount of a keystream. This about doubles the performance.
For the curious, the SIMD performance isn't very impressive at this point, just a modest increase. But I have some hope that the experimental core library U32x4 will bring a nice bump (it is implemented with some unsafe hacking) and be an easy refactor.
ACKs for top commit:
apoelstra:
ACK 1ca55ac77db698f3816d8b7ed4051ddb5a579a29; successfully ran local tests
tcharding:
ACK 1ca55ac77d
Tree-SHA512: 8db1c6144d172775164859ffd0d97021f90d9123d06b5cccde21800aec4dcea75a5753d547933288ae233caf82e92849f894fb7019537d188baf10fbf7019684
There is a new lint error on nightly-2025-04-25 "variables can be used
directly in the `format!` string".
Exclude the lint to allow the existing syntax in `format!` strings.
* Inline all the block operations to give the compiler the best chance
to optimize the SIMD instruction usage. This squeezed out another
percent or two on the benchmarks when comparing target-cpu=native
builds to standard.
* The get_keystream method exposes the keystream for a block for
special case scenarios. Generally the cipher state should only be
updated with teh apply_keystream method.
* The keystream function is creating two state block on every call,
but just to handle a corner case. Break up the function
into separate methods so that the corner case is handled by itself,
avoiding unnecessary work most of the time.
* Handle offset state internally. While not strictly necessary due to
the cipher's use in BIP324, it makes the library much easier to work
with (the bug above would probably have been avoided) if the cipher
handles the offset state.
Recent clippy nightly update introduces warnings about precedence. While
ours are, IMO, clear the lint docs have some cases that are not so I
don't think we should ignore this lint. Specifically I could easily miss
this one
1 << 2 + 3 equals 32, while (1 << 2) + 3 equals 7
ref: https://rust-lang.github.io/rust-clippy/master/#/precede
Add parenthesis to explicitly show precedence. Refactor only no logic
changes.
There is a loose convention in Rust to not use `test_` prefix. The
reason being that `cargo test` outputs 'test <test name>' using the
prefix makes the output stutter.
This patch smells a bit like code-churn but having the prefix in some
places and not others is confusing to new contributors and is leading me
to explain this many times now. Lets just fix it.
Remove the prefix unless doing so breaks the code.
727c519efa Re-export amount from primitives (Tobin C. Harding)
84ede349b0 Run the formatter (Tobin C. Harding)
4865d60258 bitcoin: Improve the re-exports ... again (Tobin C. Harding)
Pull request description:
When we messed with the re-exports recently we failed to notice that the formatter would move the `pub use` blocks around because I only put `rustfmt::skip` on one block, I thought that had the effect of stopping all exports below that block being changed, turns out I was wrong.
Run the formatter then make some minor changes to the re-exports in `bitcoin`, including changing comments that do not make sense with the new layout.
ACKs for top commit:
apoelstra:
ACK 727c519efa771d3ec6a21350e4638b9f1536bfe1; successfully ran local tests
Tree-SHA512: fa9fbadf7efa0a76db6a0a2915fcabeda348c561e4047f9517ca7fba1a2008d5624072b7a9ce6069d71c229a794b4d27c3d96195768e87b3c2c412d611ecbfcf
2ae6a9abc1 Prep the chacha20-poly1305 crate for release (Nick Johnson)
Pull request description:
Bump the patch version to `v0.1.1` to include the no_std support.
Could see this requiring `v0.2.0`, but went with the patch bump.
ACKs for top commit:
apoelstra:
ACK 2ae6a9abc1cb6b0f3edb358ebe5e9a0781051abe; successfully ran local tests; let's do it
tcharding:
ACK 2ae6a9abc1
Tree-SHA512: 880e8390447c238bfd0e9493682622213b91f7f41c8c320fea6af763e00d73fb30bfc545f420b79614a8b33249abbd08bc9dcb7ace9522a68862194240b7258a
Making it clear in the chacha20-poly1305 documentation that this
implementation is maintained by bitcoin developers and targeted
specifically for bitcoin ecosystem use cases.
There is a range of different wordings used in the docs of constructor
type functions.
Change all to start with `Constructs a new` or `Constructs an empty`.
In functions that act like constructors there is a mixture of the usage
of `creates` and `constructs`.
Replace all occurrences of `creates` with `constructs` in the first line
of docs of constructor like functions.
26ed97877b Add no_std flag to the chacha20-poly1205 crate (Nick Johnson)
Pull request description:
I unfortunately forgot to copy over the `no_std` configuration when I promoted the chacha20_poly1305 from an internal module (where it inherited the setting) to the main module of the new crate.
This crate is using a slightly simpler no_std pattern than some other crates in the org. I like the simple approach, but can update it if consistency is valued in this case.
ACKs for top commit:
tcharding:
ACK 26ed97877b
apoelstra:
ACK 26ed97877bdbee0b9b67db52ff0d53b706361e08; successfully ran local tests
Tree-SHA512: ffa672b7593daa4148ef8584903939e976302138b0aae1f09de647885629e502bcb1380471b29d8cd28ae52a435e52bd22b231c6631528d17fe3090e7f56add7